cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
251
Views
0
Helpful
1
Replies
Highlighted

Segment Routing and BGP-LU Questions

Hi there,

 

I have couple of questions about some Segment Routing and BGP-LU.

 

bgp-lu.png

 

Above is my network topology. So here are the details and I will omit some details just to keep things simple.

* orange area is ISIS AGG1. Yellow is ISIS BB. Grey is AGG2

* no redistribution between ISIS instance. ABRs belong to both BB and AGGx

* black lines are BGP labeled-unicast sessions. 

* XR8 is central route-reflector

* ABRs are route-reflectors too with next-hop-self. This is to propagate the loopbacks from AGGx to BB and vice versa.

* All routers belong to BGP AS#1234

* All routers are running segment-routing.

* Loopback addresses are 192.168.255.x/32 where X is the router number.

 

Here's my configuration for PE routers and it applies to all. I am using index 1 for xr1, 2 for xr2, and so on. Using default SRGB.

 

prefix-set LOOPBACK
  0.0.0.0/0 eq 32
end-set

!

route-policy LOOP($SID)
  if destination in LOOPBACK then
    set label-index $SID
  endif
end-policy

!

router bgp 1234
 ibgp policy out enforce-modifications
 address-family ipv4 unicast
  redistribute connected route-policy LOOP(1)

!

router isis AGG1
 interface Loopback0
  address-family ipv4 unicast
   tag 100
   prefix-sid index 1 explicit-null

 

My question is about this command, "ibgp policy out enforce-modifications".

 

The lab is working fine and I can ping from ios1 to ios3. I have another VPNv4 peering using XR7 as the sRR so that's a different story.

 

So now, I am just wondering how this ibgp policy out command works. When I turned off ibgp policy out (I'll keep the command short) on XR3 and XR4, XR8 see these routes.

 

RP/0/0/CPU0:xr8#show bgp ipv4 labeled-unicast labels | b Origin

Mon Oct 19 04:30:16.846 UTC

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network            Next Hop        Rcvd Label      Local Label

*>i192.168.37.0/24    192.168.255.7   3               16007          

*>i192.168.57.0/24    192.168.255.7   3               16007          

* i192.168.255.1/32   192.168.255.3   3               16001          

*>i                   192.168.255.4   3               16001          

* i192.168.255.2/32   192.168.255.3   3               16002          

*>i                   192.168.255.4   3               16002          

*>i192.168.255.7/32   192.168.255.7   3               16007          

* i192.168.255.9/32   192.168.255.5   16009           16009          

*>i                   192.168.255.6   16009           16009          

* i192.168.255.10/32  192.168.255.5   16010           16010          

*>i                   192.168.255.6   16010           16010          

 

 

I don’t know why it says here Rcvd Label 3 (implicit-null) but the next-hop is correct which is 192.168.255.4 because XR4 is advertising the route to XR8 with next-hop-self. (I'm just getting it from XR4 for now because XR3 is getting the routes from RR too. Will deal with that later)

 

XR4’s BGP table is the same.

 

RP/0/0/CPU0:xr4#show bgp ipv4 labeled-unicast labels | b Origin

Sat Oct 10 12:57:48.667 UTC

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network           Next Hop       Rcvd Label     Local Label

*>i192.168.255.1/32   192.168.255.1   3               16001          

*>i192.168.255.2/32   192.168.255.2   3               16002          

*>i192.168.255.7/32   192.168.255.7   3               16007          

*>i192.168.255.9/32   192.168.255.6   16009           16009          

*>i192.168.255.10/32 192.168.255.6   16010           16010          

 

It says Rcvd Label is 3 (implicit-null)

 

Why is the local label correct for the corresponding loopbacks, i.e. 16001 for XR1 and 16002 for XR2. I enabled the ibgp policy out on XR5 and XR6 so the Rcvd Labels are correct for XR9 and XR10, 16009 and 16010 respectively.

 

For XR1, I am advertising the loopback route with SID1 (which I suspect should be SRGB+index value) but the output in both XR3 and XR4 says the received label is 3. I also do not know how it was able to assign a correct "local label" of 16001 and 16002.

 

If I turn on ibgp out policy command on XR3 and XR4, the table changes to this.

 

XR4 remains to have Rcvd Label 3 but XR8 is now correct with 16001 and 16002.

 

RP/0/0/CPU0:xr4#show bgp ipv4 labeled-unicast labels | b Origin

Sat Oct 10 13:06:39.601 UTC

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network           Next Hop       Rcvd Label     Local Label

*>i192.168.255.1/32   192.168.255.1   3               16001          

*>i192.168.255.2/32   192.168.255.2   3               16002          

*>i192.168.255.7/32   192.168.255.7   3               16007          

*>i192.168.255.9/32   192.168.255.6   16009           16009          

*>i192.168.255.10/32 192.168.255.6   16010           16010          

 

RP/0/0/CPU0:xr8#show bgp ipv4 labeled-unicast labels | b Origin

Sat Oct 10 13:07:30.479 UTC

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network           Next Hop       Rcvd Label     Local Label

* i192.168.255.1/32   192.168.255.3   16001          16001          

*>i                   192.168.255.4   16001           16001          

* i192.168.255.2/32   192.168.255.3   16002           16002          

*>i                   192.168.255.4   16002           16002          

*>i192.168.255.7/32   192.168.255.7   3               16007          

* i192.168.255.9/32   192.168.255.5   16009           16009          

*>i                   192.168.255.6   16009           16009          

* i192.168.255.10/32 192.168.255.5   16010           16010          

*>i                   192.168.255.6   16010           16010

 

Can someone help me understand how the labels are being assigned here and advertised? If I do not enable ibgp policy out command, the end to end VPN doesn't work.

1 REPLY 1
Highlighted
Cisco Employee

 

 

Hello.

 

Because the command next-hop-self was designed to change NH information for those NLRI received originally from eBGP peer rather than from iBGP one.
As you're clearly working on a seamless MPLS SR architecture the setup chosen does not accomplish your goal without the use of the command "ibgp policy out enforce-modifications". AS value is the same across entire domain, so BGP does not advertise allocated label if we set nexhop within the route-policy construct if iBGP is used. Implicit null is received when you get to tunnel end so PHP is performed. This is why you see label 3 coming from ABRs/ ASBRs, because LSP is broken.

I guess even without SR, LDP labels would not have passed through the AS peers. You can test it though.
If you check IOS/IOS XE you should find a command which looks like the following one below:

 

R1(config-router-af)#neighbor 192.168.0.98 next-hop-self ?
all Enable next-hop-self for both eBGP and iBGP received paths
Keyword "all" accomplish more or less what policy enforce modifications does under XR.

 

 

Regards

 

Content for Community-Ad

This widget could not be displayed.