-
Notifications
You must be signed in to change notification settings - Fork 440
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
Bug to announce flow with redirect in IPv6 #1183
Comments
I upgraded to 4.2.21 Oct 9 15:33:28 wanguard exabgp[357828]: 15:33:28 | 357828 | api | command could not parse flow in : announce flow route { match { source 0:0:0:0:0:0:0:0/0; destination fd01:0:0:0:0:0:0:0/128; } then { community 65000:660; redirect [ 2001::1 ]; } } |
I have write a little workaround : src/exabgp/configuration/flow line 299 Before :
After :
|
Thank you for pointing me to the right place to look. |
I rewrote the parsing as it has issues. Can you please let me know if the new |
Previous versions (eg. 4.1.2) accepted the IPv6 nexthop redirect flowspec format: > redirect <IPv6>; The introduction of the "[IPv6]:NN" route-target format broke down the ability to specify an IPv6 nexthop redirection. Thanks to the f320ac9 ("work on Exa-Networks#1183") commit, the feature has been restored but the command format has changed to "redirect [<IPv6>];" Enclosing an IPv6 in square brackets helps in distinguishing the ':' separator from the ':' characters from the IPv6 itself. However, the "redirect <IPv6>;" format could be parsed correctly. Indeed, if the parsed string has several ':' characters and no brackets, we know it is not a route-target (ie. not "IPv4:NN", "[IPv6]:NN" nor "ASN:NN"). Restore the "redirect <IPv6>;" format in addition to "redirect [<IPv6>]". Fixes: f320ac9 ("work on Exa-Networks#1183") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Previous versions (eg. 4.1.2) accepted the IPv6 nexthop redirect flowspec format: > redirect <IPv6>; The introduction of the "[IPv6]:NN" route-target format broke down the ability to specify an IPv6 nexthop redirection. Thanks to the f320ac9 ("work on Exa-Networks#1183") commit, the feature has been restored but the command format has changed to "redirect [<IPv6>];" Enclosing an IPv6 in square brackets helps in distinguishing the ':' separator from the ':' characters from the IPv6 itself. However, the "redirect <IPv6>;" format could be parsed correctly. Indeed, if the parsed string has several ':' characters and no brackets, we know it is not a route-target (ie. not "IPv4:NN", "[IPv6]:NN" nor "ASN:NN"). Restore the "redirect <IPv6>;" format in addition to "redirect [<IPv6>]". Fixes: f320ac9 ("work on Exa-Networks#1183") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Hey,
I have a problem with ExaBGP to send annouce flow with redirect in IPv6.
Oct 9 14:56:02 bgp exabgp[336824]: 14:56:02 | 336824 | version | 4.2.8
Oct 9 14:56:02 bgp exabgp[336824]: 14:56:02 | 336824 | interpreter | 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110]
In IPv4 :
echo "announce flow route { match { source 0.0.0.0/0; destination 10.0.0.1/24; } then { community 65000:660; redirect 10.1.1.122; } }" > /run/exabgp/exabgp.in
Oct 9 15:21:50 bgp exabgp[336824]: 15:21:50 | 336824 | configuration | the route family is not configured on neighbor
Oct 9 15:21:50 bgp exabgp[336824]: 15:21:50 | 336824 | api | flow added to neighbor x.x.x.1 local-ip x.x.x.152 local-as 65101 peer-as 209097 router-id x.x.x.152 family-allowed in-open, neighbor xxxx:xxxx::1 local-ip xxxx:xxxx:1::152 local-as 65101 peer-as 209097 router-id x.x.x.152 family-allowed in-open : flow destination-ipv4 10.0.0.1/24 source-ipv4 0.0.0.0/0 next-hop 10.10.1.1 community 65000:660 extended-community redirect-to-nexthop
and correctly interpreted by Cisco Router.
In IPv6 :
echo "announce flow route { match { source 0:0:0:0:0:0:0:0/0; destination fd01:0:0:0:0:0:0:0/128; } then { community 65000:660; redirect xxxx:xxxx::122; } }" >> /run/exabgp/exabgp.in
Oct 9 15:22:01 bgp exabgp[336824]: 15:22:01 | 336824 | reactor | async | api-internal-cli-339c4a50 | problem with function
Oct 9 15:22:01 bgp exabgp[336824]: 15:22:01 | 336824 | reactor | async | api-internal-cli-339c4a50 | illegal IP address string passed to inet_pton
The text was updated successfully, but these errors were encountered: