Add "antctl get bgproutes" agent command#6734
Conversation
63b5cb3 to
d2d575c
Compare
antoninbas
left a comment
There was a problem hiding this comment.
Not done reviewing it yet, but at a high-level I do not think we should be handling "received routes" at the moment. Unless I am mistaken, this is not a concept which is really relevant to the (current) Antrea BGP implementation.
| # Get the list of all received bgp routes | ||
| $ antctl get bgproutes --in |
There was a problem hiding this comment.
we do not handle "received routes" in the Antrea BGP implementation, so I think this may be misleading to users
cc @hongliangl
There was a problem hiding this comment.
we do not handle "received routes" in the Antrea BGP implementation
Exactly. At least right now, we don't care about the "received routes" from remote peers. In current implementation of BGPPolicy controller, we only advertise routes, for the "received routes", we do nothing.
There was a problem hiding this comment.
@hongliangl
To track, better to create a separate issue to support received routes for future use-case , as received routes can be important for scenarios involving multiple BGP peers, dynamic route management, or multi-cluster setups,
as of now for basic CNI and Kubernetes networking, the focus is primarily on what the cluster advertises !
| # Get the list of all received bgp routes | ||
| $ antctl get bgproutes --in |
There was a problem hiding this comment.
we do not handle "received routes" in the Antrea BGP implementation
Exactly. At least right now, we don't care about the "received routes" from remote peers. In current implementation of BGPPolicy controller, we only advertise routes, for the "received routes", we do nothing.
d2d575c to
6b5c93d
Compare
84cd772 to
345ee83
Compare
345ee83 to
15d64cb
Compare
f38c39d to
2aea77b
Compare
|
/test-all |
2aea77b to
671bba8
Compare
671bba8 to
2f06d8d
Compare
2f06d8d to
ccc048d
Compare
antoninbas
left a comment
There was a problem hiding this comment.
only a handful of nits, otherwise LGTM
996bfa1 to
633f3bf
Compare
633f3bf to
6f72e75
Compare
6f72e75 to
b289d98
Compare
b289d98 to
61be307
Compare
antoninbas
left a comment
There was a problem hiding this comment.
one last comment, otherwise lgtm
| var ipv4Routes, ipv6Routes = false, false | ||
| rawQuery := r.URL.RawQuery | ||
| switch rawQuery { | ||
| case "ipv4-only=": | ||
| ipv4Routes = true | ||
| case "ipv6-only=": | ||
| ipv6Routes = true | ||
| case "": | ||
| ipv4Routes = true | ||
| ipv6Routes = true | ||
| default: | ||
| http.Error(w, "invalid query", http.StatusBadRequest) | ||
| return | ||
| } |
There was a problem hiding this comment.
let's use this variation:
values := r.URL.Query()
var ipv4Only, ipv6Only bool
if values.Has("ipv4-only") {
if values.Get("ipv4-only") != "" {
// bad request
}
ipv4Only = true
}
if values.Has("ipv6-only") {
if values.Get("ipv6-only") != "" {
// bad request
}
ipv6Only = true
}
if ipv4Only && ipv6Only {
// bad request
}
// ...
bgpRoutes, err := bq.GetBGPRoutes(r.Context(), !ipv6Only, !ipv4Only)I feel like the current validation is a bit too restrictive / low-level. We should accept both ipv4-only= and ipv4-only for example.
61be307 to
9a0f84e
Compare
|
/test-all |
9a0f84e to
446a7e2
Compare
Add `antctl get bgproutes` agent command to print the advertised BGP routes. The command is implemented using a new HTTP endpoint (`/bgproutes`), which will return a `404 Not Found` error if no BGPPolicy has been applied on the Node. Signed-off-by: Kumar Atish <kumar.atish@broadcom.com>
446a7e2 to
93df0aa
Compare
|
/test-all |
|
/test-e2e |
|
/test-conformance |
|
/test-all-features-conformance |
Add
antctl get bgproutesagent command to print the advertised BGP routes on the local Node.The command is implemented using a new HTTP endpoint (
/bgproutes), which will return a404 Not Founderror if no BGPPolicy has been applied on the Node.For #6209