Fix: Mark phantom links used to create multihop EBGP sessions#2502
Fix: Mark phantom links used to create multihop EBGP sessions#2502
Conversation
|
|
||
| node_found = False | ||
| for intf in node.interfaces: | ||
| if intf.get('_phantom_link',False): |
There was a problem hiding this comment.
Why not simply check for _bgp_session here? It implies "phantom_link"
There was a problem hiding this comment.
... because I'd like to have a generic mechanism we might need in the future (one of these days we'll tackle TE, and the TE tunnels might be another case of phantom links).
jbemmel
left a comment
jbemmel
left a comment
There was a problem hiding this comment.
I can see you like the phantom thing, but the flag is somewhat superfluous
You are correct that the two flags serve exactly the same purpose, so I'll remove the "_bgp_session" one (as it's only used in the cleanup phase). Also, I will add a generic IGP phantom-avoidance code; the current implementation was obviously written before we had anything but OSPF in the VRFs. |
The ebgp.multihop plugin creates bogus ('phantom' sounds so much better)
links to persuade the BGP module to establish BGP sessions between
endpoints of multihop EBGP sessions.
Unfortunately, other modules (in particular 'routing.static') find
those links and want to use them.
With this change, ebgp.multihop plugin marks the interfaces attached to
those links with the '_phantom_link' flag, and the nexthop resolution
for static routes avoids those interfaces.
At the moment, the bogus static route next hops seem to be the only
undesired side effect of those phantom links, but of course something
else is bound to pop up eventually :(
Fixes #2414
And I was wrong. It turns out I need (A) a flag that the interface is used for MH EBGP session (to do stuff like adding config request) and (B) a flag that the link/interface is not real. I could probably do (A) by scanning the BGP neighbor list, but this approach is simpler (and I don't have to scan all the VRFs). So, we're staying with the two flags; modified code coming in a few minutes. |
2 participants
The ebgp.multihop plugin creates bogus ('phantom' sounds so much better) links to persuade the BGP module to establish BGP sessions between endpoints of multihop EBGP sessions.
Unfortunately, other modules (in particular 'routing.static') find those links and want to use them.
With this change, ebgp.multihop plugin marks the interfaces attached to those links with the '_phantom_link' flag, and the nexthop resolution for static routes avoids those interfaces.
At the moment, the bogus static route next hops seem to be the only undesired side effect of those phantom links, but of course something else is bound to pop up eventually :(
Fixes #2414