I have a scenario with a CCR 2216 running BGP full routing with 3 upstreams (let’s imagine upstream A, B, and C). I’m using ROS version 7.18 (firmware also updated).
Everything is working as it should, and I don’t have any major issues. However, there’s something very strange in a specific case. A public route (subnet /12) received from all 3 peers does not follow the routing table.
I manipulate these incoming routes with BGP filters, adjusting local-pref, distance, etc. This specific /12 prefix shows up with the letter “A” for Active when I use the command /routing/route/print detail where dst-address=x.x.x.x/16, according to the filters I applied, indicating that the best route is the one I chose with the filters—let’s say through provider B.
However, when testing, the router forwards the traffic through provider C, disregarding the active route (some data masked):
/routing/route> print detail where dst-address="X.X.0.0/12"
Flags: X - disabled, F - filtered, U - unreachable, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, i - isis, d - dhcp, v - vpn, m - modem, a - ldp-address, l - ldp-mapping, g - slaac, y - bgp-mpls-vpn;
H - hw-offloaded; + - ecmp, B - blackhole
b afi=ip4 contribution=candidate dst-address=X.X.0.0/12 routing-table=main gateway=X.X.22.101 immediate-gw=X.X.22.101 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-X.X.22.101"
bgp.peer-cache-id=*280000C .as-path="AAAA,BBBB" ..local-pref=95 .atomic-aggregate=yes .origin=igp
debug.fwp-ptr=0x203C37E0
AbH afi=ip4 contribution=active dst-address=X.X.0.0/12 routing-table=main gateway=X.X.101.6 immediate-gw=X.X.101.6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-X.X.101.6"
bgp.peer-cache-id=*280000A .as-path="CCCC,GGGG,BBBB" . .local-pref=105 .atomic-aggregate=yes .origin=igp
debug.fwp-ptr=0x203E9420
b afi=ip4 contribution=candidate dst-address=X.X.0.0/12 routing-table=main gateway=X.X.100.234 immediate-gw=X.X.100.234 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-X.X.100.234"
bgp.peer-cache-id=*2800039 .as-path="FFFF,BBBB" . .local-pref=100 .atomic-aggregate=yes .origin=igp
debug.fwp-ptr=0x203E4F00
I’ve tried several combinations of distance and local-pref, and in all cases, it sends the traffic through the last peer (which would be C, instead o B, the active one).
This behavior occurs across all 7.x versions I’ve tested. This issue might happen with other prefixes, but I’ve never encountered it except with this /12. Apart from this case, all other prefixes respect the routes marked with status “A”—only this one doesn’t.
It seems like a bug related to the prefix size, being a /12, and possibly tied to L3HW.
If I set this route statically, it sends the traffic through the path that was set.
Does anyone have any suggestions or have you encountered this scenario before? Workaround?
Thank you.