IBGP local-as and route reflectors

[ipspace]

The modified IBGP local-as test exposed three problems we ignored so far:

1. Next hop has to be changed on EBGP route sent over IBGP local-as session (template error)
2. Real IBGP routes won't be sent over IBGP local-as sessions unless the router having that session is a route reflector
3. As we're not running an IGP with the remote end of the IBGP local-as session, the remote end might not have a route to the next hop of a reflected IBGP route.

We have to decide what to do now:

• (1) has to be fixed
• I would expect the user to set bgp.rr to cover (2) (and document that)
• We advertise loopbacks in IBGP, so (3) should not be a big deal... unless a device cannot cope with IBGP and IGP route to the same prefix (example: FRR). I would NOT change next hop on the reflected routes (which would be another workaround)

Any thoughts @jbemmel @ssasso?

[jbemmel]

For (3), if we set the next hop to the transport address for the IBGP local-as session, the remote would have a route (by definition - else the IBGP session wouldn't exist)

Which is what e.g. EOS already does anyway:

netlab/netsim/ansible/templates/bgp/eos.j2

Line 16 in 751cc1f

set ip next-hop peer-address

[ipspace]

What you quoted is only for external routes (added a clarification to the original post).

I think the next-hop-self would do the trick (https://blog.ipspace.net/2022/04/eos-route-reflector-next-hop-self/), but it's ugly to force a modification of a next hop of a reflected route.

After all, people should learn good practices from working with netlab, not how to thread your way through a CCIE lab 😜 That's why I said no to the "oh, but I can make VLAN 1 work on Dell OS10" idea.

[jbemmel]

That's why I said no to the "oh, but I can make VLAN 1 work on Dell OS10" idea.

It's also why I keep raising these rabbit holes - to clarify what "good practices" look like

[ipspace]

The test results are online: https://tests.netlab.tools/_html/coverage.bgp

If the results page claims a device passed IBGP local-as test, I did not run the test for that device. I only ran one test per a group of similar devices (IOS, Junos)

[ipspace]

Thinking a bit more about the "we need route reflection on the IBGP local-as session", it would probably be easiest to set the rr_client status on both neighbors automatically¹. Adding the bgp.rr attribute to the topology would make the router part of the RR full mesh.

Footnotes

1. Doing that on the router with local-as will be trivial. Figuring that out for the other end will be a bit more interesting ;) ↩

[jbemmel]

Perhaps as a suggestion to the user? In light of "teaching best practices", rather than do it behind the scenes encourage the user to think about it for themselves

[ipspace]

The problem is that there is no "this neighbor is a RR client" flag, so it's not trivial to add the required functionality.

[ipspace]

Update: this is a total mess.

The existing templates are all over the place. IOS has the "we need a RR client" functionality, but the logical condition is wrong (because it was never tested) and EOS has the "we need to set the NH on ingress" part but not the "set NH on egress" one.

I will document what needs to be done to make this work, extend the integration test to cover all possible scenarios, and fix the existing templates to the best of my abilities (skipping the Junos one 😜)