Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd. Any ideas what could be going on? FRR 7.3-dev: # tcpdump -nn ip6 and host 2620:8b:8000:0:7064:ee:ab4c:621 and icmp6 -i eth4.431 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth4.431, link-type EN10MB (Ethernet), capture size 262144 bytes 09:25:04.058721 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:804::200e: ICMP6, echo request, seq 52, length 64 09:25:04.073358 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.103068 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.132735 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.162433 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.192130 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:05.058671 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:804::200e: ICMP6, echo request, seq 53, length 64 09:25:05.073322 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.103023 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.132822 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.162499 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.192275 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:06.058736 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:804::200e: ICMP6, echo request, seq 54, length 64 09:25:06.073396 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.103114 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.132879 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.162550 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.192316 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 Quagga: tcpdump -nn ip6 and host 2620:8b:8000:0:7064:ee:ab4c:621 and icmp6 -i eth4.431 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth4.431, link-type EN10MB (Ethernet), capture size 262144 bytes 09:29:19.261904 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:805::200e: ICMP6, echo request, seq 12, length 64 09:29:19.276527 IP6 2607:f8b0:4020:805::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 12, length 64 09:29:20.262978 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:805::200e: ICMP6, echo request, seq 13, length 64 09:29:20.277640 IP6 2607:f8b0:4020:805::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 13, length 64 09:29:21.265010 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:805::200e: ICMP6, echo request, seq 14, length 64 09:29:21.279670 IP6 2607:f8b0:4020:805::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 14, length 64
On 08/01/2020 13:42, Patrick Boutilier wrote:
Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd.
Any ideas what could be going on?
Sanity check more /proc/sys/net/ipv6/conf/*/forwarding and check you have all 1s (TBH, working IPv6 is the main reason to use FRR over Quagga) Tim
On 1/8/20 9:49 AM, Tim Bray wrote:
On 08/01/2020 13:42, Patrick Boutilier wrote:
Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd.
Any ideas what could be going on?
Sanity check
more /proc/sys/net/ipv6/conf/*/forwarding
and check you have all 1s
(TBH, working IPv6 is the main reason to use FRR over Quagga)
Tim
All 1. Lots of vlan interfaces.... # cat /proc/sys/net/ipv6/conf/*/forwarding 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
On 1/8/20 8:07 PM, Patrick Boutilier wrote:
On 1/8/20 9:49 AM, Tim Bray wrote:
On 08/01/2020 13:42, Patrick Boutilier wrote:
Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd.
Any ideas what could be going on?
Sanity check
more /proc/sys/net/ipv6/conf/*/forwarding
and check you have all 1s
(TBH, working IPv6 is the main reason to use FRR over Quagga)
Tim
All 1. Lots of vlan interfaces....
# cat /proc/sys/net/ipv6/conf/*/forwarding 1
<snip> Turns out the issue was that the frr server couldn't route back to 2620:8b:8000:0:7064:ee:ab4c:621 without adding a static route. Static route was not needed with old Quagga so I will investigate why. All working now with the static route in place.
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
On 1/11/20 9:06 AM, Patrick Boutilier wrote:
On 1/8/20 8:07 PM, Patrick Boutilier wrote:
On 1/8/20 9:49 AM, Tim Bray wrote:
On 08/01/2020 13:42, Patrick Boutilier wrote:
Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd.
Any ideas what could be going on?
Sanity check
more /proc/sys/net/ipv6/conf/*/forwarding
and check you have all 1s
(TBH, working IPv6 is the main reason to use FRR over Quagga)
Tim
All 1. Lots of vlan interfaces....
# cat /proc/sys/net/ipv6/conf/*/forwarding 1
<snip> Turns out the issue was that the frr server couldn't route back to 2620:8b:8000:0:7064:ee:ab4c:621 without adding a static route. Static route was not needed with old Quagga so I will investigate why. All working now with the static route in place.
Short investigation. I forgot to add the "ipv6 route" statements from the old quagga zebra.conf file to the new frr staticd.conf file. Sorry for the noise.
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
Can we see the `show ipv6 route` output? donald On Sat, Jan 11, 2020 at 8:07 AM Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
On 1/8/20 8:07 PM, Patrick Boutilier wrote:
On 1/8/20 9:49 AM, Tim Bray wrote:
On 08/01/2020 13:42, Patrick Boutilier wrote:
Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd.
Any ideas what could be going on?
Sanity check
more /proc/sys/net/ipv6/conf/*/forwarding
and check you have all 1s
(TBH, working IPv6 is the main reason to use FRR over Quagga)
Tim
All 1. Lots of vlan interfaces....
# cat /proc/sys/net/ipv6/conf/*/forwarding 1
<snip> Turns out the issue was that the frr server couldn't route back to 2620:8b:8000:0:7064:ee:ab4c:621 without adding a static route. Static route was not needed with old Quagga so I will investigate why. All working now with the static route in place.
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
participants (3)
-
Donald Sharp -
Patrick Boutilier -
Tim Bray