-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Feat(eos_designs): Support for IPv4 p2p_links in an RFC5549 Fabric #4379
Comments
EDIT: After inspecting the code you need both, but that should solve it. Thank you for a thoroughly described issue. Snip from the docs: # Enables deviation of the routing protocol used on this link from the fabric underlay default.
# - ebgp: Enforce plain IPv4 BGP peering
routing_protocol: <str; "ebgp"> This is at the bottom of the doc which makes it easy to miss. |
I was actually already using the Here's some quick tests I ran just now, none of these are achieving the desired results, but all of them having different behavior.
I've only just glanced at the related code but the obstacle to my goal is that the underlay peers always get the same underlay peer group. So while I can get the interface to not be enabled for IPv6, and I can get bgp config generated, I still have to find a way to disable the ipv6 originate. avd/python-avd/pyavd/_eos_designs/structured_config/core_interfaces_and_l3_edge/router_bgp.py Lines 41 to 46 in 92ec3a8
|
We could change the current behavior so giving |
Added a PR based on your suggestion. We've temporarily worked around this issue in our deployment until AVD gets support for it. But we have settled on the desire to be able to control the peer group for a specific l3_edge connection. Specifically this would allow granular control over DCI connections in BGP. I wanted to go ahead and get the base PR in to cover the generic use case, but would like to continue to discuss the idea of adding a new structure.
After briefly glancing over the code I do understand that this is a more extensive feature request, but I plan to attempt to tackle it myself as long as there are no objections to the structure of it. Alternatively, I was unable to find a way to render structured configuration to the bgp neighborship itself or raw eos cli. Both these options would be less elegant. But if adding the peer group key is undesirable perhaps a way to get structured config into the neighborship would be sufficient. Or maybe there is a way that I was unable to find. |
Enhancement summary
Currently if
include_in_underlay_protocol
istrue
then the p2p_link is given the same peer group as the rest of the underlay. If the underlay fabric is an RFC5549 fabric using IPv6 but the p2p_link is IPv4, then due to the peer group it gets the attributeneighbor IPv4-UNDERLAY-PEERS next-hop address-family ipv6 originate
set under the IPv4 address family. This will prevent routes from being shared.Which component of AVD is impacted
eos_designs, eos_cli_config_gen
Use case example
Two DC fabrics that use RFC5549 as their individual underlays but with a desire to make all connections out of the fabric IPv4, including the DCI.
Describe the solution you would like
The quickest solution (from my naive perspective) is to add a key to allow overriding the peer-group used on the p2p_link. This would allow multiple benefits, not only could one control the
ipv6 originate
knob, but in the case of the DCI they could more easily tune other knobs independent of the rest of the underlay.Alternatively the existing
ipv6_enable
key controls the interface itself but has no impact on the neighborship AFAIK. This key could be used to automatically add theno ... next-hop address-family ipv6 originate
for the neighbor if the underlay is set to RFC5549, or to add logic to create an RFC5549 underlay peer-group as well as a non-rfc5549 peer group (ideally only if needed). This solution adds more nested logic and would have to be careful to make sure it's backwards compatible. Even though I'm not sure how it would be working, existing installations might be using rfc5549 with ipv6 set to false and this would be a change in behavior.Describe alternatives you have considered
next-hop address-family ipv6 originate
for the specific p2p neighbors. Feels confusing and not clear to have it defined in the peer group and then override it.Additional context
I'm willing to work on a PR that implements this. Just looking for guidance on the best way to approach this issue before I start working.
Contributing Guide
The text was updated successfully, but these errors were encountered: