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
Solved! Go to Solution.
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
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
06-11-2014 02:41 PM
Thanks Xander.
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 ?
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
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: