Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2301
Views
0
Helpful
4
Replies

MPLS-free BGP vpnv4 route reflector

Go to solution
amonge123
Level 1
Level 1

‎06-06-2014 12:08 PM

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

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
xthuijs
Cisco Employee
Cisco Employee

‎06-07-2014 01:10 PM

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

View solution in original post

0 Helpful
4 Replies 4

Go to solution
xthuijs
Cisco Employee
Cisco Employee

‎06-07-2014 01:10 PM

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

0 Helpful

Go to solution
amonge123
Level 1
Level 1

‎06-11-2014 02:41 PM

Thanks Xander.

0 Helpful

Go to solution
kszarkowicz
Level 1
Level 1

‎06-26-2014 03:15 AM

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     ?

0 Helpful

Go to solution
xthuijs
Cisco Employee
Cisco Employee
In response to kszarkowicz

‎06-26-2014 09:25 AM

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

0 Helpful
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:

Customers Also Viewed These Support Documents