cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1151
Views
5
Helpful
1
Replies

Segment Routing and BGP-LU Questions

jpl861
Level 4
Level 4

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

pigallo
Cisco Employee
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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: