cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4895
Views
0
Helpful
5
Replies

BGP Next-hop conflict with MPLS Label.

maritpra
Beginner
Beginner

Hi, Experts

Equipment: Cisco ASR9922, IOS-XR 4.3.2

Issue: I have problem that my RR do the next-hop-self by using route-policy for client routers, the next-hop is changed as intended but the MPLS label doesn’t changed to reflect the new next-hop.

What I would like to achieve: I would like RR to set next-hop-self only for selected prefixes(172.168.0.0/24, 0.0.0.0/0) but maintain original next-hop for the rest, I do this by using route-policy.

Detail:

I have routers running MPLS infrastructure with ASR9922 as an RR. RN router is in neighbor-group RN and CPE-xx routers are in neighbor-group AN.

  • •-       Every routers are in same BGP AS64549.
  • •-       RN sends prefixes 0.0.0.0/0 and 172.168.0.0/24 to RR.
  • •-       CPE-25 sends prefix 192.168.25.1/32 to RR.

Neighbor-group AN has the route-policy AN-OUT2 to set next-hop of prefix 172.168.0.0/24 and 0.0.0.0/0 to RR#loopback1 before send out update to CPE routers. Below is BGP and RPL configuration at RR.

router bgp 64549

nsr

bgp graceful-restart

ibgp policy out enforce-modifications

address-family vpnv4 unicast

  additional-paths receive

  additional-paths send

  additional-paths selection route-policy ADD-PATH-iBGP

  retain route-target all

!

neighbor-group AN

  remote-as 64549

  cluster-id 172.16.1.11

  update-source Loopback1

  address-family vpnv4 unicast

   route-reflector-client

   route-policy AN-OUT2 out

   soft-reconfiguration inbound

  !

!

route-policy AN-OUT2

  if destination in DEFAULT or destination in RNC then

    set next-hop 192.168.10.11

  else

    pass

  endif

end-policy

This is what RR advertises to CPE-24

RP/0/RP0/CPU0:RR#show bgp vpnv4 unicast neighbors 192.168.10.24 advertised-routes

Fri Dec 20 15:23:14.931 BKK

Network            Next Hop        From            AS Path

Route Distinguisher: 64549:3339

0.0.0.0/0          192.168.10.11   172.16.1.1      ?

                                   172.16.1.2      ?

172.168.0.0/24     192.168.10.11   172.16.1.1      ?

                                   172.16.1.2      ?

192.168.0.1/32     192.168.10.11   192.168.10.24   i

192.168.0.26/32    192.168.10.26   192.168.10.26   i

192.168.25.1/32    192.168.10.25   192.168.10.25   i

192.168.211.8/30   192.168.10.22   192.168.10.22   i

The IP part works as intended but MPLS Label doesn’t work as intended. Please take a look at RN who is originates 172.168.0.0/24, label 16025 is locally assigned.

RP/0/RP0/CPU0:RN1#show bgp vpnv4 unicast labels

Status codes: s suppressed, d damped, h history, * valid, > best

              i - internal, r RIB-failure, S stale, N Nexthop-discard

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

   Network            Next Hop        Rcvd Label      Local Label

Route Distinguisher: 64549:3339 (default for vrf VLAN3339)

*> 0.0.0.0/0          0.0.0.0         nolabel         16025          

* i                   172.16.1.11     16068           16025          

* i                   172.16.1.13     16033           16025          

*> 172.168.0.0/24     0.0.0.0         nolabel         16025          

* i                   172.16.1.11     16059           16025          

* i                   172.16.1.13     16024           16025          

172.168.0.0/24 at RR, label 16059 is locally assigned, label 16025 is receive from RN router. It should send 172.168.0.0/24 with label 16059 to CPE-24 to reflect next-hop changed.

RP/0/RSP0/CPU0:RR#show bgp vpnv4 unicast labels

Status codes: s suppressed, d damped, h history, * valid, > best

              i - internal, r RIB-failure, S stale, N Nexthop-discard

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

   Network            Next Hop        Rcvd Label      Local Label

Route Distinguisher: 64549:3339

*>i0.0.0.0/0          172.16.1.1      16025           16068          

* i                   172.16.1.2      16007           16068          

*>i172.168.0.0/24     172.16.1.1      16025           16059          

* i                   172.16.1.2      16007           16059          

*>i192.168.0.1/32     192.168.10.24   131070          16060          

*>i192.168.25.1/32    192.168.10.25   131070          16062          

*>i192.168.211.8/30   192.168.10.22   131070          16065          

What I found at CPE-24 which is Alcatel router is that, RR send prefix 172.168.0.0/24, nh 192.168.10.11 with label 16025 which is incorrect.

A:CPE-24# show router bgp routes vpn-ipv4 172.168.0.0/24

===============================================================================

BGP Router ID:192.168.10.24    AS:64549       Local AS:64549     

===============================================================================

Legend -

Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid

Origin codes  : i - IGP, e - EGP, ? - incomplete, > - best, b - backup

===============================================================================

BGP VPN-IPv4 Routes

===============================================================================

Flag  Network                                            LocalPref   MED

      Nexthop                                            Path-Id     VPNLabel

      As-Path                                                       

-------------------------------------------------------------------------------

u*>?  64549:3339:172.168.0.0/24                          100         0

      192.168.10.11                                      None        16025

      No As-Path                                                     

-------------------------------------------------------------------------------

Routes : 1

===============================================================================

On RR If I just remove the policy and do the next-hop-self under vpv4 address family, CPE-24 will get corrent nh with correct label(16059) but that won’t achieve our requirement to change nh only on selected prefixes. Is this software problem? Or is there any solution to work around?

Regard,

Marit