-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bgpd: fix prefix same as nexthop in label per nexthop #16990
Conversation
tests/topotests/bgp_vpnv6_per_nexthop_label/test_bgp_vpnv6_per_nexthop_label.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good ... waiting on the topo test corrections
b503e3b
to
d554310
Compare
ci:rerun |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
it looks like the lint errors need to be fixed up before we can push |
@lsang6WIND could you fix lint issues? |
When a prefix is imported using the "network" command under a vrf, which is a connected prefix, and in the context of label allocation per nexthop: .. >router bgp 1 vrf vrf1 > address-family ipv4 unicast > redistribute static > network 172.16.0.1/32 <--- connected network > network 192.168.106.0/29 > label vpn export auto > label vpn export allocation-mode per-nexthop .. We encounter an MPLS entry where the nexthop is the prefix itself: > 18 BGP 172.16.0.1 - Actually, when using the "network" command, a bnc context is used, but it is filled by using the prefix itself instead of the nexthop for other BGP updates. Consequently, when picking up the original nexthop for label allocation, the function behaves incorrectly. Instead ensure that the nexthop type of bnc->nexthop is not a nexthop_ifindex; otherwise fallback to the per vrf label. Update topotests. Signed-off-by: Loïc Sang <loic.sang@6wind.com>
WARNING: topo: Waiting time is too small (count=10, wait=0.5), using default values (count=20, wait=3) Supress warning by inscreasing wait time. Signed-off-by: Loïc Sang <loic.sang@6wind.com>
f83fd05
to
3c2949e
Compare
When a prefix is imported using the "network" command under a vrf, which
is a connected prefix, and in the context of label allocation per
nexthop:
..
We encounter an MPLS entry where the nexthop is the prefix itself:
Actually, when using the "network" command, a bnc context is used, but
it is filled by using the prefix itself instead of the nexthop for other
BGP updates. Consequently, when picking up the original nexthop for
label allocation, the function behaves incorrectly. Instead ensure that
the nexthop type of bnc->nexthop is not a nexthop_ifindex; otherwise
fallback to the per vrf label.
Update topotests.