mpls, vpnv4 and /32 addresses

Hi, I'm trying to understand the reason why you should use /32 addresses when peering mp-bgp peers for vpnp4 address exchange.

I've seen that the whole reason of this requirement is that you're supposed to use multihop bgp with ospf as the igp, thus leading to the ospf issue of advertising a loopback in /32 regardless of the actual subnet mask used.

Therefore I've made a test and the solution is either using a native /32 in the loopback or changing ospf network type of loopback to point-to-point, which makes everything match.

However I still not understand what exactly goes wrong when you don't use one of the fixes above, I think that the problem lies between the last "p" router and the "pe" because the "pe" has an e.g. /24 loopback while the "p" is fooled by ospf into thinking that it's a /32.

The questions is: and so? even if there's a mismatch the last "p" router is supposed to strip off the top label, so the packet arrives to the "pe" only with the inner label, for which he has a proper lib, fib, lfib etc.

Sorry for the long question, and explanation is deeply appreciated.

Thanks

M

Comments

  • Hi, I'm trying to understand the reason why you should use /32 addresses when peering mp-bgp peers for vpnp4 address exchange.

    I've seen that the whole reason of this requirement is that you're supposed to use multihop bgp with ospf as the igp, thus leading to the ospf issue of advertising a loopback in /32 regardless of the actual subnet mask used.

    Thanks

    M

    Hi Marco,

    If you have used OSPF as an IGP in MPLS backbone & the loopback is configured with /24 mask, the PE router will advertise the label binding for that loopback interface with its original prefix mask i.e. /24. The routes advertised by OSPF will have /32 because it assumes the loopback network as the host route. The LSRs create the label binding on the basis of the OSPF route advertisements, i.e./32 which results LSP failure. So, in order to prevent such a design issue with OSPF, we need to have /32 mask in the loopback.

    Hope this helps!

  • Hi Marco,

    If you have used OSPF as an IGP in MPLS backbone & the loopback is configured with /24 mask, the PE router will advertise the label binding for that loopback interface with its original prefix mask i.e. /24. The routes advertised by OSPF will have /32 because it assumes the loopback network as the host route. The LSRs create the label binding on the basis of the OSPF route advertisements, i.e./32 which results LSP failure. So, in order to prevent such a design issue with OSPF, we need to have /32 mask in the loopback.

    Hope this helps!

    Hi, ok but regardless of the igp announcements, the "pe" is supposed to announce a null label for its own prefix (due to php) so the "p" removes the label and sends an unlabeled packet (with only the inner tag, which can be read by the "pe").

    M

  • Two different problems can happen:

    1) The problem occurs with the last P router popping ALL labels, not just performing PHP.

    2) also a P router that is deeper into the network (not just the last P router before a PE) performing PHP...this would mean that the last P router would receive a inner VPN label and not know what to do with it (PHP too soon). 

    The OSPF problem that you are describing would result in the 1st scenario I described. The last P router would not have a label for teh loopback of the PE (it would show up as unlabeled") and would remove ALL tags, causing the data-plane to fail end to end. The PE is advertising a label for a /24, NOT for a /32, however, the P router is using a /32 for forwarding (but it never received a label for a /32 from the PE). 

    If you use a connected route (non loopback), for example, the link connecting a P router to a PE router, this would result in the second scenario. The PHP process would occur one router too soon, meaning that the last P router would receive the VPN label and not know what to do with it. 

     

  • Hi, ok but regardless of the igp announcements, the "pe" is supposed to announce a null label for its own prefix (due to php) so the "p" removes the label and sends an unlabeled packet (with only the inner tag, which can be read by the "pe").

    Hi,

    For additional clarification, please look into the example as shown below:

    R5---[R1--R2---R3---R4]----R6

     

    R6#traceroute 5.5.5.5 source l0

    Type escape sequence to abort.

    Tracing the route to 5.5.5.5

      1 10.1.46.4 16 msec 88 msec 48 msec

      2  *  *  *

      3  *  *  *

    R3#sh mpls forwarding-table


    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

    tag    tag or VC   or Tunnel Id      switched   interface

    18     Untagged    4.4.4.4/32        562        Et1/0      10.1.34.4




    R2#sh mpls forwarding-table 1.1.1.1

    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

    tag    tag or VC   or Tunnel Id      switched   interface

    16     Untagged    1.1.1.1/32        876        Et1/0      10.1.12.1



    Instead of POP, it's untagged. So, it doesn't go ahead without specific route of the CE which doesn't exist on the P routers at all. It's a kind of balckhole :) . Since R1 & R4 has /24 prefix and it tells the respective P routers to pop for 1.1.1.0/24 & 4.4.4.0/24 NOT 1.1.1.1/32 & 4.4.4.4/32. 


    So, R2 & R3 doesn't strip off the label & drop the packet because of not having outgoing label. 


    Once we add "ip ospf network point-to-point" command under the loopback 0 of R1 & R4, everything works fine because OSPF advertises the loopbacks with its actual prefix-length rather than /32 host route.



    R3#sh mpls forwarding-table 4.4.4.4

    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

    tag    tag or VC   or Tunnel Id      switched   interface

    20     Pop tag     4.4.4.0/24        0          Et1/0      10.1.34.4





    R2#sh mpls forwarding-table 1.1.1.1

    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

    tag    tag or VC   or Tunnel Id      switched   interface

    19     Pop taog     1.1.1.0/24        146        Et1/0      10.1.12.1




    R6#traceroute 5.5.5.5 source l0


    Type escape sequence to abort.

    Tracing the route to 5.5.5.5


      1 10.1.46.4 24 msec 4 msec 68 msec

      2 10.1.34.3 [MPLS: Labels 19/19 Exp 0] 184 msec 164 msec 140 msec

      3 10.1.23.2 [MPLS: Labels 19/19 Exp 0] 220 msec 132 msec 164 msec

      4 10.1.15.1 [MPLS: Label 19 Exp 0] 168 msec 164 msec 132 msec

      5 10.1.15.5 204 msec 216 msec 148 msec



    Good luck!

  • Ok that's clear, now I spotted the pop/untagged many many thanks for all your replies; the thing that still puzzles me is that when there's the mismatch the last "p" lib actually shows a label for the /24 network, not only from the "pe" but also from his fellow downstream "p" neighbor. I guess that might relate to the unsolicited label distribution mode?

  • The IGP protocol will propagate the IP routes accross all routers that are running the IGP and in this instance the IGP is OSPF, nothing unusual here this is how routes get propagated and we achieve end to end connectivity.  LDP will send labels to its LDP neighbors for its connected interfaces AND any route it has learnt via IGP.  So yes you will find downstream neighbors advertising labels to you for IP routes that have essentially come from the opposite direction.  Will we use them i.e. will they get put in the MPLS forwarding table (LFIB) no?  Why? Because we didn't install the matching IP route, and also in this instance the label advertisment does not match the IP route i.e. the mask is different.  So LDP doesn't do the split horizon type behaviour that we are used to with IGP's but we won't use the label anyway.

     

    Nick

  • I guess that might relate to the unsolicited label distribution mode?

    Correct, that is the unsolicited DOWNSTREAM mode at its best. All split horizon behavior goes out the door with LDP [:)]

     

Sign In or Register to comment.