-
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: add resolved_prefix visibility on nht #15636
Conversation
48def30
to
e152654
Compare
The nexthop tracking never displays the prefix that has been used in ZEBRA to resolve its nexthop. This information will be useful if some decision has to be taken regarding any loops, that is to say if for instance a BGP prefix is resolved over a prefix in ZEBRA that is exactly the same. Store the value in bgp nexthop context, and display it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
e20faa9
to
98d0339
Compare
98d0339
to
e20faa9
Compare
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, but can we see the output of the new attribute?
} else { | ||
vty_out(vty, " %s valid [IGP metric %d], #paths %d", | ||
buf, bnc->metric, bnc->path_count); | ||
if (peer) | ||
vty_out(vty, ", peer %s", peer->host); | ||
if (bnc->is_evpn_gwip_nexthop) | ||
vty_out(vty, " EVPN Gateway IP"); | ||
vty_out(vty, "\n Resolved prefix %pFX", |
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.
Will this align with the existing CLI output? I see 2 spaces here. Or is this intentional?
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.
#show bgp nexthop
192.168.3.3 valid [IGP metric 0], #paths 1
Resolved prefix 192.168.3.0/24
gate 192.168.5.10, if r1-eth2
Last update: Mon Apr 1 21:55:16 2024
@mobash-rasool , this is intentional.
The nexthop tracking never displays the prefix that has been used in ZEBRA to resolve its nexthop. This information will be useful if some decision has to be taken regarding any loops, that is to say if for instance a BGP prefix is resolved over a prefix in ZEBRA that is exactly the same.
Store the value in bgp nexthop context, and display it.