Routing

last person joined: 3 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Redistributing LDP FECs into BGP inet labeled-unicast

    Posted 07-10-2013 10:59

    I can across this while following the JNCIS-SP fasttrack Carrier of Carriers VPN customer example but I think the question is a more generalized one.

     

    Consider one of the customers site as follows -

     

    C-PE-1-------------------------C-P-1-------------------------C-CE-1
    192.168.12.3               192.168.12.100                  192.168.12.1

     

    LDP has been activated everywhere with no changes to default policy (thus lables are distributed for each Router's loopback IP). The IGP is OSPF and all connected routes are advertised in OSPF.

     

    Now, the C-CE-1 interfaces with P-PE-1 and they exchange BGP inet labeled-unicast NLRIs.

     

    On C-CE-1, OSPF is redistributed into BGP via routing policy. This is where the problem starts. C-CE-1 advertises a label for 192.168.12.3 with a label, say 300592.

     

    nbhasin@CE-1# ...show route advertising-protocol bgp 10.0.20.1 extensive    
    
    <SNIP>
    
    * 192.168.12.3/32 (1 entry, 1 announced)
     BGP group P-PEs type External
         Route Label: 300592
         Nexthop: Self
         Flags: Nexthop Change
         MED: 2
         AS path: [10] I

     

    In the mpls.0 table, C-CE-1 installs L1 and the forwarding state for that label is as follows:

     

    nbhasin@CE-1# run show route table mpls.0 label 300592 
    
    mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    300592             *[VPN/170] 00:09:05
                        > to 10.0.151.2 via em1.221, Pop      
    300592(S=0)        *[VPN/170] 00:09:05
                        > to 10.0.151.2 via em1.221, Pop 

    Now this creates a problem. For a packet across CoC with a top label of 300592 and say a VPN label of 16, the C-CE-1 will pop the top label and forward the MPLS packet to C-P-1 with a label of 16. Since the IBGP inet labeled-unicast session is only between C-CE and C-PE, P1 does not know about 16 and drops the packet.

     

    So I decided to redistribute LDP instead of OSPF into BGP and see how that would work. I used the following very basic policy to do this :

     

    policy-statement LDP->BGP {
        from protocol ldp;
        then accept;
    }

     This did not work as no LDP routes are advertised in BGP. I realized that since LDP only installs routes in inet.3 by default, that maybe the issue. So I modified the policy as follows:

     

    policy-statement LDP->BGP {
        from {
            protocol ldp;
            rib inet.3;
        }
        then accept;
    }

     No luck still. Finally, I enabled the MPLS protocol to copy all the MPLS routes into inet.0 using :

     

    set protocols mpls traffic-engineering bgp-igp-both-ribs

     I also removed the rib inet.3 from the policy and things started working.

     

    nbhasin@CE-1# ...show route advertising-protocol bgp 10.0.20.1 extensive    
    
    inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden)
    * 192.168.12.3/32 (2 entries, 2 announced)
     BGP group P-PEs type External
         Route Label: 300608
         Nexthop: Self
         Flags: Nexthop Change
         MED: 1
         AS path: [10] I
    
    -----------------------------------
    
    [edit]
    nbhasin@CE-1# run show route table mpls.0 label 300608 
    
    mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    300608             *[VPN/170] 00:00:35
                        > to 10.0.151.2 via em1.221, Swap 299824

     So, my basic question is, what am I doing wrong in my routing policy in the first examples? I really do not want to copy all the MPLS routes into inet.0 to enable redistribution.

     

    Is there a way to configure redistribution between LDP and BGP where the routes would not have to be moved into inet.0?

     

    Thanks in adavance,

     

    Nic


    #JNCIE
    #MPLS
    #BGP
    #ldp


  • 2.  RE: Redistributing LDP FECs into BGP inet labeled-unicast
    Best Answer

    Posted 07-10-2013 12:50

    Hello,

     


    @Newagequanta wrote:

     

    Is there a way to configure redistribution between LDP and BGP where the routes would not have to be moved into inet.0?

     

    Thanks in adavance,

     

    Nic


    Yes there is at least 2:

    1/ use "protocols mpls traffic-engineering mpls-forwarding" and redistribute /32 from OSPF into BGP-LU, not LDP.

    This will have following effect:

    - OSPF routes will be announced via BGP-LU with labels

    - The ASBR will install "Swap" operation between LDP labels and BGP-LU labels

    2/ use "protocols bgp group <> family inet labeled-unicast rib inet.3", and redistribute LDP into BGP-LU.

    The downside of this approach is that if You are doing Option C and peeAS's Route Reflector IP also comes via BGP-LU, the session to peerAS RR won't come up if RR IP address is in inet.3, you will need 2 BGP sessions between ASBRs (one for inet unicast, 2nd for inet labeled-unicast)

    HTH

    Thanks
    Alex



  • 3.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

     
    Posted 07-11-2013 04:52

    Hello,


    @aarseniev wrote:

     

    2/ use "protocols bgp group <> family inet labeled-unicast rib inet.3", and redistribute LDP into BGP-LU.The downside of this approach is that if You are doing Option C and peeAS's Route Reflector IP also comes via BGP-LU, the session to peerAS RR won't come up if RR IP address is in inet.3, you will need 2 BGP sessions between ASBRs (one for inet unicast, 2nd for inet labeled-unicast)

    Actually the ASBRs bgp session is only one with the both families (inet and labeled-unicast). You just need to redistribute ospf /32 from inet.0 and  ldp /32 from inet.3 

    Another solution for stiching lsp is to extend customer ldp to P-PE vrf http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/vpn-multiple-instances-ldp-and-carrier-of-carriers.html

     

    Krasi



  • 4.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

    Posted 07-11-2013 06:20

    Hello,

     


    @Krasi wrote:

    Hello,


    Actually the ASBRs bgp session is only one with the both families (inet and labeled-unicast). You just need to redistribute ospf /32 from inet.0 and  ldp /32 from inet.3 

    Another solution for stiching lsp is to extend customer ldp to P-PE vrf http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/vpn-multiple-instances-ldp-and-carrier-of-carriers.html

     

    Krasi


    Yes, 1 TCP session with 2 families, thanks for correcting me.

    This does not change the end result though - if this is Option C and a route to peerAS' RR IP address comes as BGP-LU NLRI, it gets installed in inet.3 only and TCP session would not come up. One needs peer-'s address in inet.0 to establish the

    TCP session for BGP.

    HTH

    Thanks

    Alex

     



  • 5.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

     
    Posted 07-12-2013 05:11

    Hi,

     

    That is why I said: 

    "....redistribute ospf /32 from inet.0 and  ldp /32 from inet.3"

     

    Krasi



  • 6.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

    Posted 07-15-2013 04:38

    Sorry to force the issue here but if someone could direct me to the right resource for the answer of the following question, I would really appreciate that. Thanks in advance.


    Why does the behavior of the label installed in mpls.0 change from pop to the more proper behavior of swap as soon as you enter the mpls-forwarding command? I can see it happening as you said it would but do not see any documentation on it. Perhaps a logic issue that I am not following?

    Thanks in advance,

    This question has really pestered me and a good resource on this would be invaluable.

     

    Nic



  • 7.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

    Posted 07-11-2013 09:20

    Thanks Alex,

     

    Both the solutions work splendidly. I will have to go look up the details of both the family inet labeled-unicast rib inet.3 and the mpls-forwarding command.

     

    My understanding of mpls-forwarding was that the inet.3 routes are still copied into inet.0 but are used only for forwarding and not for policy decisions. This scenario would make it seem that is not the case. Do you have any documentation of why this actually works the way it works in this case? Would be much appreciated.

     

    As for Option C, I will keep your caveat in mind when I come across it.

     

    Thanks again,

     

    Nic



  • 8.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

    Posted 07-11-2013 10:32

    Hello,

     

    http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-mpls-applications/mpls-configuring-traffic-engineering-for-lsps.html#id-78895

     

    These copied routes are always depreferred despite having lower pref by default:

     

    inet.0: 26 destinations, 36 routes (26 active, 5 holddown, 1 hidden)
    @ = Routing Use Only, # = Forwarding Use Only
    + = Active Route, - = Last Active, * = Both
    
    198.18.0.3/32      @[OSPF/10] 1w0d 05:46:40, metric 1000
                        > to 198.18.10.10 via ge-1/1/7.11
                       #[RSVP/7/1] 1w0d 05:46:35, metric 1000
                        > to 198.18.22.3 via ge-1/1/7.2122, label-switched-path MX1_to_GLOBAL
                          to 198.18.12.10 via ge-1/1/7.12, label-switched-path MX1_to_GLOBAL
                        [LDP/9] 00:00:46, metric 1000
                        > to 198.18.10.10 via ge-1/1/7.11

     HTH

    Thanks
    Alex

     

     



  • 9.  RE: Redistributing LDP FECs into BGP inet labeled-unicast

    Posted 07-11-2013 12:42
    Thanks Alex,

    I understand the depreference of the routes copied into inet.0. My query has more to do with the following question :

    Why does the behavior of the label installed in mpls.0 change from pop to the more proper behavior of swap as soon as you enter the mpls-forwarding command? I can see it happening as you said it would but do not see any documentation on it. Perhaps a logic issue that I am not following?

    Thanks in advance,

    Nic