MPLS-free BGP vpnv4 route reflector

Answered Question
Jun 6th, 2014
User Badges:

Hello,

In Junos, a BGP Route Reflector can reflect vpnv4 routes successfully even if it doesn't have MPLS reachability to the PEs. Simply with this command:

set routing-options rib inet.3 routing-options static route 0/0 discard

This installs a default route in the BGP next-hop resolution auxiliary RIB and it does the trick.

I am looking for a way to do the same in IOS-XR. Can a vpnv4 RR reflect routes even if it doesn't have MPLS reachability to the PEs?

Thanks!

Ato

Correct Answer by xthuijs about 3 years 2 months ago

hey Ato,

An RR just reflects the route but does do next hop verification, it just reflects those routes.

The next hop doesnt need to be reachable on the RR technically, but due to the next hop validation rule, the nexthop needs to have a route.

The BGP routes don't necessarily need to be in the RIB (or routing table), as long as the BGP paths are "valid" in teh bgp table, they will be reflected to the clients. As long as it is not inline of coruse (that is in the forwarding path of the PE to PE etc).

Also, just an fyi, if you want to use RPL to modify the paths, then you need a special CLI to enforce ibgp policy modifications. This because generally speaking an RR is not supposed to modify routes in iBGP obviously.

cheers

xander

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
xthuijs Sat, 06/07/2014 - 13:10
User Badges:
  • Cisco Employee,

hey Ato,

An RR just reflects the route but does do next hop verification, it just reflects those routes.

The next hop doesnt need to be reachable on the RR technically, but due to the next hop validation rule, the nexthop needs to have a route.

The BGP routes don't necessarily need to be in the RIB (or routing table), as long as the BGP paths are "valid" in teh bgp table, they will be reflected to the clients. As long as it is not inline of coruse (that is in the forwarding path of the PE to PE etc).

Also, just an fyi, if you want to use RPL to modify the paths, then you need a special CLI to enforce ibgp policy modifications. This because generally speaking an RR is not supposed to modify routes in iBGP obviously.

cheers

xander

kszarkowicz Thu, 06/26/2014 - 03:15
User Badges:

Well, I am observing different behavior.

I have simple BGP RR config:


router bgp 65002
 address-family vpnv4 unicast
 !
 neighbor-group IBGP-CLIENTS
  remote-as 65002
  cluster-id 172.16.20.2
  update-source Loopback0
  session-open-mode passive-only
  address-family vpnv4 unicast
   route-reflector-client
   soft-reconfiguration inbound always
  !
 !
 neighbor-group IBGP-RR-MESH
  remote-as 65002
  update-source Loopback0
  address-family vpnv4 unicast
   soft-reconfiguration inbound always
  !
 !
 neighbor 172.16.20.1
  use neighbor-group IBGP-RR-MESH
 !
 neighbor 172.16.20.3
  use neighbor-group IBGP-CLIENTS
 !
 neighbor 172.16.20.4
  use neighbor-group IBGP-CLIENTS
 !
 neighbor 172.16.20.5
  use neighbor-group IBGP-RR-MESH
 !
 neighbor 172.16.20.6
  use neighbor-group IBGP-RR-MESH
 !
!

 

Now, I receive some VPN prefixes from RR-MESH:

 

RP/0/0/CPU0:01-P2#show bgp vpnv4 unicast neighbors 172.16.20.6 detail received routes 
Thu Jun 26 02:32:23.871 UTC
BGP router identifier 172.16.20.2, local AS number 65002
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0x0   RD version: 0
BGP main routing table version 8
BGP scan interval 60 secs

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            Metric LocPrf Weight Path
Route Distinguisher: 172.16.20.3:101
* i10.10.10.13/32     172.16.21.3                   100      0 i
Route Distinguisher: 172.16.21.4:101
* i10.10.10.14/32     172.16.21.4              0    100      0 ?

Processed 2 prefixes, 2 paths


The next-hops of those VPN prefixes is unreachable:


RP/0/0/CPU0:01-P2#show route 172.16.21.3                                              
Thu Jun 26 02:34:53.891 UTC

% Network not in table

RP/0/0/CPU0:01-P2#show route 172.16.21.4 
Thu Jun 26 02:34:58.451 UTC

% Network not in table

RP/0/0/CPU0:01-P2#


And consequently, the VPN prefixes are not advertised to clients (note 10.10.10.13/32 and 10.10.10.14/32 is NOT advertised):


RP/0/0/CPU0:01-P2#show bgp vpnv4 unicast neighbors 172.16.20.4 advertised-routes 
Thu Jun 26 02:35:46.697 UTC
Network            Next Hop        From            AS Path
Route Distinguisher: 172.16.20.1:101
10.10.10.11/32     172.16.20.3     172.16.20.3     i
Route Distinguisher: 172.16.20.4:101
10.10.10.12/32     172.16.20.2     172.16.20.4     ?

 

Now, if I change my design to have the next-hops reachable on RR:


RP/0/0/CPU0:01-P2#show route 172.16.21.3                                         
Thu Jun 26 02:37:08.432 UTC

Routing entry for 172.16.21.3/32
  Known via "isis core", distance 115, metric 4000, type level-2
  Installed Jun 26 02:37:01.022 for 00:00:07
  Routing Descriptor Blocks
    10.2.0.10, from 172.16.20.5, via GigabitEthernet0/0/0/1
      Route metric is 4000
    10.2.0.7, from 172.16.20.5, via GigabitEthernet0/0/0/3
      Route metric is 4000
  No advertising protos. 
RP/0/0/CPU0:01-P2#show route 172.16.21.4 
Thu Jun 26 02:37:11.512 UTC

Routing entry for 172.16.21.4/32
  Known via "isis core", distance 115, metric 4000, type level-2
  Installed Jun 26 02:37:01.022 for 00:00:10
  Routing Descriptor Blocks
    10.2.0.10, from 172.16.20.5, via GigabitEthernet0/0/0/1
      Route metric is 4000
    10.2.0.7, from 172.16.20.5, via GigabitEthernet0/0/0/3
      Route metric is 4000
  No advertising protos. 

  
  
The VPN prefixes are advertised to RR clients (note 10.10.10.13/32 and 10.10.10.14/32 is now advertised):

RP/0/0/CPU0:01-P2#show bgp vpnv4 unicast neighbors 172.16.20.4 advertised-routes 
Thu Jun 26 02:37:36.930 UTC
Network            Next Hop        From            AS Path
Route Distinguisher: 172.16.20.1:101
10.10.10.11/32     172.16.20.3     172.16.20.3     i
Route Distinguisher: 172.16.20.3:101
10.10.10.13/32     172.16.21.3     172.16.20.5     i
Route Distinguisher: 172.16.20.4:101
10.10.10.12/32     172.16.20.2     172.16.20.4     ?
Route Distinguisher: 172.16.21.4:101
10.10.10.14/32     172.16.21.4     172.16.20.5     ?

xthuijs Thu, 06/26/2014 - 09:25
User Badges:
  • Cisco Employee,

You are 100% correct! I mixed up 2 things, apologies! (and updated the answer to reflect it).

For the Route Reflector, it does do the regular BGP selection algorithm, which includes rule 1 that the next hop needs to be accessible. This means that the next hop needs to be in the IGP.

Now the case is however that if the RR is not in the forwarding path, the BGP paths do not need to be in the RIB/routing table. (you can control that with the table-policy under the router bgp/address-family context.

However to satisfy the bgp path validation, the nexthop needs to be in the RIB. This can either be fed by a static (null) route or an IGP table.

Thanks for chiming in kszarkowicz! and enhancing this discussion

Checking in to see if there was a knob to override that (as I seem to recall something to that extent) and will update the discussion when I have it!

regards

xander

Actions

This Discussion