Hello,
trying to set up an IPv6 BGP reflector with ROS 7.17rc3.
Clients get the routes, but next-hop is always set to the reflector itself. Have found posts from 2022 detailing similar issues, but setting next-hop in a filter, as they suggest, is not an option. Is this still unfixed, then?
setting
nexthop-choice=force-self
for bgp session works for me
Shouldn’t it be exactly the opposite? An RR (by definition) should propagate learned routes to clients and keep the original next-hop, not replace it with self, which is what is doing here.
for sure, but it works
Thanks for the suggestion. I tried. It doesn’t.
Have you set this parameter to the bgp session on the RR or client?
I’ll recheck my config, but I’m sure that my RR with this option sends prefixes with correct gateway to the clients.
I can’t control the next hop of every announce that’s coming from rr-clients, but some do have nexthop self. Despite that every single reflected route on the clients has the reflector loopback address as next-hop.
Appreciate trying to help, but I stand that a reflector should never, ever change the next-hop to itself. Happened to us with v4, on an early ROS7.x, after an update for some reason a reflector started next-hopping itself and it caused us a massive outage. It’s nasty.
IPv6 reflector works as expected, it does not change nexthop to itself.
I guess that there are link local gateways in which case changing nexthop is expected behavior.
These are the routes IN the reflector:
These are the announces out of the reflector. 2a01:2d8::b1 is the reflector’s IPv6.
0 peer=v6-uni-abg-cri-bb-ar1-1 dst=2a01:2d8:aca0::/48 afi=ipv6 local-pref=100 med=100 nexthop=2a01:2d8::b1 origin=0 as-path=sequence 65525 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-agr-rom-cr2-1 dst=2a01:2d8:aca0::/48 afi=ipv6 local-pref=100 med=100 nexthop=2a01:2d8::b1 origin=0 as-path=sequence 65525 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-agr-rom-cr1-1 dst=2a01:2d8:aca0::/48 afi=ipv6 local-pref=100 med=100 nexthop=2a01:2d8::b1 origin=0 as-path=sequence 65525 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-agr-rom-cr2-1 dst=2a01:2d8:200:40::/60 afi=ipv6 local-pref=100 nexthop=2a01:2d8::b1 origin=2 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-agr-rom-cr1-1 dst=2a01:2d8:200:40::/60 afi=ipv6 local-pref=100 nexthop=2a01:2d8::b1 origin=2 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-abg-cri-bb-ar1-1 dst=2a01:2d8:200:40::/60 afi=ipv6 local-pref=100 nexthop=2a01:2d8::b1 origin=2 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-agr-rom-cr2-1 dst=2a01:2d8:200:70::/60 afi=ipv6 local-pref=100 nexthop=2a01:2d8::b1 origin=2 originator-id=195.72.193.8 cluster-list=8.2.2.4
0 peer=v6-uni-agr-rom-cr1-1 dst=2a01:2d8:200:70::/60 afi=ipv6 local-pref=100 nexthop=2a01:2d8::b1 origin=2 originator-id=195.72.193.8 cluster-list=8.2.2.4
Coming back with some more information:
Can’t really think of a reason every advertisement (/routing/bgp/advertisements/print) has the rr loopback as next-hop. Open to suggestions.
show your bgp connections configuration.
/routing bgp template
add address-families=ipv6 as=8224 cluster-id=8.2.2.4 disabled=no input.filter=ibgp_v6_rr_restricted_in name=reflector-v6 nexthop-choice=propagate \
output.filter-chain=ibgp_v6_rr_restricted_out router-id=195.72.193.8 routing-table=reflect
/routing bgp connection
add address-families=ipv6 as=8224 cisco-vpls-nlri-len-fmt=auto-bits cluster-id=8.2.2.4 connect=yes disabled=no input.filter=ibgp_v6_rr_restricted_in listen=yes \
local.address=2a01:2d8::b1 .role=ibgp-rr name=v6-uni-vpr-cr2 nexthop-choice=propagate output.filter-chain=ibgp_v6_rr_restricted_out remote.address=\
2a01:2d8::1:d/128 .as=8224 .port=179 router-id=195.72.193.8 routing-table=reflect templates=reflector-v6
filters, like said, are only accept/discard type.
It is not a reflector if it has only one BGP peer, where do routes that supposedly should be reflected come from?
It has 209 of them. Thought you could extrapolate from one example, since they’re all the same but for the name and address. Obviously I was wrong.
(also, the snippet above with the outgoing announces shows several peers)
Back on this. It’s the table, breaks rr even on v4.
/routing bgp template
add address-families=ip as=65531 cluster-id=10.50.50.1 disabled=no name="test -v4" router-id=10.50.50.1 routing-table=main
/routing bgp connection
add address-families=ip as=65531 connect=yes disabled=no listen=yes local.address=10.50.50.1 .role=ibgp-rr name=router-1 nexthop-choice=propagate remote.address=10.30.30.1/32 \
.as=65531 router-id=10.50.50.1 templates="test -v4"
add address-families=ip as=65531 connect=yes disabled=no listen=yes local.address=10.50.50.1 .role=ibgp-rr name=router-2 nexthop-choice=propagate remote.address=10.20.20.1/32 \
.as=65531 router-id=10.50.50.1 templates="test -v4"
[admin@router1] > /ip/route/print where dst-address=10.42.42.0/24
Flags: D - DYNAMIC; A - ACTIVE; b - BGP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAb 10.42.42.0/24 10.20.20.1 200
/routing bgp template
add address-families=ip as=65531 cluster-id=10.50.50.1 disabled=no name="test -v4" router-id=10.50.50.1 routing-table=reflect
/routing bgp connection
add address-families=ip as=65531 connect=yes disabled=no listen=yes local.address=10.50.50.1 .role=ibgp-rr name=router-1 nexthop-choice=propagate remote.address=10.30.30.1/32 \
.as=65531 router-id=10.50.50.1 templates="test -v4"
add address-families=ip as=65531 connect=yes disabled=no listen=yes local.address=10.50.50.1 .role=ibgp-rr name=router-2 nexthop-choice=propagate remote.address=10.20.20.1/32 \
.as=65531 router-id=10.50.50.1 templates="test -v4"
[admin@router1] > /ip/route/print where dst-address=10.42.42.0/24
Flags: D - DYNAMIC; A - ACTIVE; b - BGP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAb 10.42.42.0/24 10.50.50.1 200
My fault, I guess. I did not even consider running a reflector from the FIB. Tested on 7.17.2.