BIRD / BGP-ORR experiences?
deepak at ai.net
Wed Apr 15 15:59:48 UTC 2020
> Do we even like BGP ORR?
I like it, I think ADD-PATH and ORR are mandatory features in modern RR infra. However proper interaction between them may not exist in every implementation. Basically you want
a) send all ECMPable paths
b) send one backup path
This will lead to superior to full-mesh by every reasonable metric:
- smaller rib (no routes that you don't need, but all the routes you care about)
- redundancy (one iBGP down, is not customer outage)
- less state changes, less code stress
ORR is not an RFC and there are some open questions. What to reflect, when next-hop is not in IGP? Do we hope that receiver would recurse to the same IGP next-hop? Juniper makes this assumption, which to me is decidedly the common case. Cisco makes no assumption and doesn't reflect if next-hop is not in IGP, but as I understand they will fix to the same assumption as Juniper.
Thanks for your input. How do you handle next-hops? Tunnels between all eBGP speakers as if they were fully meshed as their potential next-hops?
More information about the NANOG