Routing
Highlighted
Routing

Redistributing LDP FECs into BGP inet labeled-unicast

‎07-10-2013 10:59 AM

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

8 REPLIES 8
Routing
Solution
Accepted by topic author Newagequanta
‎08-26-2015 01:27 AM

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-10-2013 12:50 PM

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

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-11-2013 04:51 AM

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-carrie...

 

Krasi

Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-11-2013 06:20 AM

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-carrie...

 

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

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-11-2013 09:19 AM

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

Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-11-2013 10:31 AM

Hello,

 

http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-m...

 

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

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-11-2013 12:41 PM
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
Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-12-2013 05:11 AM

Hi,

 

That is why I said: 

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

 

Krasi

Routing

Re: Redistributing LDP FECs into BGP inet labeled-unicast

‎07-15-2013 04:37 AM

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