SR Linux: Simplify the IBGP export policy with the new 'next-hop: self' action #1307
Conversation
Deploying netlab-release with
|
| Latest commit: |
9b9344b
|
| Status: | 🚫 Build failed. |
| - name: ebgp-next-hop-self | ||
| match: | ||
| protocol: bgp | ||
| action: | ||
| policy-result: next-policy | ||
| bgp: | ||
| next-hop: | ||
| set: "{{ nh }}" | ||
| set: self |
There was a problem hiding this comment.
@ipspace I am curious, what is the use case here where the nhs is needed on the ebgp session? I believe 4271 rules should be applied by default on eBGP sessions.
Or is it some redistribution use case?
There was a problem hiding this comment.
It's not on an EBGP session. The policy is used on IBGP sessions, and we cannot use the per-neighbor/AF setting because that would also impact the reflected IBGP routes.
The statement is called "ebgp-next-hop-self" because we have to implement the next hop change on EBGP routes. Any better ideas to rename the statement?
There was a problem hiding this comment.
purely up to you, maybe I'd name it bgp-next-hop-self, as the policy is universally matching on the bgp protocol
There was a problem hiding this comment.
I seem to recall having tested this on iBGP EVPN sessions, and I believe I saw that next hop self wasn't being applied even if the policy asked for it (in R-R scenario). Could be different in recent releases, but we may want to test for that
There was a problem hiding this comment.
If you're saying "I don't know whether the action.bgp.next-hop.set: self would work", it does (I'm so glad I wasted so much time writing integration tests), or were you thinking about applying next-hop-self to the peer group? That doesn't work either, the next hop is still changed on reflected routes.
SR Linux needs an export to set next-hop to "self" on EBGP routes but not on reflected IBGP routes.
The original template created two per-AF export policies and set the BGP next hop to the IP address
of the loopback interface.
With the new "action.bgp.next-hop: self" option, we can simplify that into a single route map that does
not depend on IP addresses or address families.
Last but not least, we're removing the internal BGP communities used to mark IBGP routes.