Hello, Does anyone know how FRR treats "fd80" prefixes? My configuration uses "fd80" prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these "fd80" addresses to "fe80". Thanks, Katherine
Katherine, On Tue, 14 Apr 2020 at 19:43, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Does anyone know how FRR treats “fd80” prefixes? My configuration uses “fd80” prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these “fd80” addresses to “fe80”.
A (sanitized?) configuration snippet/example from your set-up will help you get relevant answers ;) Cheers, Chriztoffer
On Wed, 15 Apr 2020 at 00:25, Chriztoffer wrote:
On Tue, 14 Apr 2020 at 19:43, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Does anyone know how FRR treats “fd80” prefixes? My configuration uses “fd80” prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these “fd80” addresses to “fe80”.
A (sanitized?) configuration snippet/example from your set-up will help you get relevant answers ;)
For a side note, I can mention DN42 (1) uses fc00::/7 space (0), with different participants using a mix of whatever you can find (FRR, Bird1/2, XORP, Quagga, EdgeRouter, Mikrotik, OpenBGPd, IOS, IOS-XR, JUNOS, etc.) [0]: fc00:0000:0000:0000:0000:0000:0000:0000 - fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff [1]: https://dn42.us Cheers, Chriztoffer
In frr.conf, bgp neighbors are set to fd80::X:X. But, the next hop is shown to be fe80::X:X when the command "show bgp" is issued. Please see below for more details. Note: Some MTUs are set to 1400. The original configuration was run in Quagga and worked. -------------------------------------------------------------------------------------------- FRR vtysh terminal -------------------------------------------------------------------------------------------- AERO-Relay# show bgp BGP table version is 10896, local router ID is 10.0.4.2, vrf id 0 Default local pref 100, local AS 1 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 2001:db8:1:1::/64 fe80::1:2 1024 0 2 ? *> 2001:db8:1:2::/64 fe80::2:2 1024 0 3 ? *> 2001:db8:1:3::/64 fe80::1:2 1024 0 2 ? *> 2001:db8:1:4::/64 fe80::2:2 1024 0 3 ? *> fd80::1:0/112 fe80::1:2 0 0 2 ? *> fd80::1:2/128 fe80::1:2 1024 0 2 ? *> fd80::2:0/112 fe80::2:2 0 0 3 ? *> fd80::2:2/128 fe80::2:2 1024 0 3 ? Displayed 8 routes and 8 total paths -------------------------------------------------------------------------------------------- frr.conf -------------------------------------------------------------------------------------------- log file /var/log/frr/frr.log debugging interface eth0 ip address 10.0.4.2/24 interface eth1 ipv6 address 2001::1/64 interface aero2 ipv6 address fd80::1:1/112 interface aero3 ipv6 address fd80::2:1/112 ! Static routes ip route 0.0.0.0/0 10.0.4.1 ! BGP configuration ! ! You should configure the AS number below, ! along with this router's peers. ! router bgp 1 bgp router-id 10.0.4.2 no bgp default ipv4-unicast neighbor fd80::1:2 remote-as 2 neighbor fd80::1:2 interface aero2 neighbor fd80::2:2 remote-as 3 neighbor fd80::2:2 interface aero3 address-family ipv6 neighbor fd80::1:2 activate neighbor fd80::1:2 next-hop-self neighbor fd80::1:2 default-originate neighbor fd80::1:2 distribute-list blackhole out neighbor fd80::2:2 activate neighbor fd80::2:2 next-hop-self neighbor fd80::2:2 default-originate neighbor fd80::2:2 distribute-list blackhole out exit-address-family ipv6 access-list blackhole deny any Thank you, Katherine -----Original Message----- From: Chriztoffer Hansen [mailto:ch@ntrv.dk] Sent: Tuesday, April 14, 2020 3:26 PM To: Tran (US), Katherine K <katherine.k.tran@boeing.com> Cc: frog@lists.frrouting.org Subject: Re: [FROG] fd80 prefix allocation Katherine, On Tue, 14 Apr 2020 at 19:43, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Does anyone know how FRR treats “fd80” prefixes? My configuration uses “fd80” prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these “fd80” addresses to “fe80”.
A (sanitized?) configuration snippet/example from your set-up will help you get relevant answers ;) Cheers, Chriztoffer
This is correct behaviour , IPv6 BGP update message will have both next hop (global and link-local) and by default route will get installed with link-local nexthop. You can apply route-map to change nexthop as global. Thanks Vijay -----Original Message----- From: frog <frog-bounces@lists.frrouting.org> On Behalf Of Tran (US), Katherine K Sent: 15 April 2020 21:48 To: ch@ntrv.dk; frog@lists.frrouting.org Subject: Re: [FROG] fd80 prefix allocation In frr.conf, bgp neighbors are set to fd80::X:X. But, the next hop is shown to be fe80::X:X when the command "show bgp" is issued. Please see below for more details. Note: Some MTUs are set to 1400. The original configuration was run in Quagga and worked. -------------------------------------------------------------------------------------------- FRR vtysh terminal -------------------------------------------------------------------------------------------- AERO-Relay# show bgp BGP table version is 10896, local router ID is 10.0.4.2, vrf id 0 Default local pref 100, local AS 1 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 2001:db8:1:1::/64 fe80::1:2 1024 0 2 ? *> 2001:db8:1:2::/64 fe80::2:2 1024 0 3 ? *> 2001:db8:1:3::/64 fe80::1:2 1024 0 2 ? *> 2001:db8:1:4::/64 fe80::2:2 1024 0 3 ? *> fd80::1:0/112 fe80::1:2 0 0 2 ? *> fd80::1:2/128 fe80::1:2 1024 0 2 ? *> fd80::2:0/112 fe80::2:2 0 0 3 ? *> fd80::2:2/128 fe80::2:2 1024 0 3 ? Displayed 8 routes and 8 total paths -------------------------------------------------------------------------------------------- frr.conf -------------------------------------------------------------------------------------------- log file /var/log/frr/frr.log debugging interface eth0 ip address 10.0.4.2/24 interface eth1 ipv6 address 2001::1/64 interface aero2 ipv6 address fd80::1:1/112 interface aero3 ipv6 address fd80::2:1/112 ! Static routes ip route 0.0.0.0/0 10.0.4.1 ! BGP configuration ! ! You should configure the AS number below, ! along with this router's peers. ! router bgp 1 bgp router-id 10.0.4.2 no bgp default ipv4-unicast neighbor fd80::1:2 remote-as 2 neighbor fd80::1:2 interface aero2 neighbor fd80::2:2 remote-as 3 neighbor fd80::2:2 interface aero3 address-family ipv6 neighbor fd80::1:2 activate neighbor fd80::1:2 next-hop-self neighbor fd80::1:2 default-originate neighbor fd80::1:2 distribute-list blackhole out neighbor fd80::2:2 activate neighbor fd80::2:2 next-hop-self neighbor fd80::2:2 default-originate neighbor fd80::2:2 distribute-list blackhole out exit-address-family ipv6 access-list blackhole deny any Thank you, Katherine -----Original Message----- From: Chriztoffer Hansen [mailto:ch@ntrv.dk] Sent: Tuesday, April 14, 2020 3:26 PM To: Tran (US), Katherine K <katherine.k.tran@boeing.com> Cc: frog@lists.frrouting.org Subject: Re: [FROG] fd80 prefix allocation Katherine, On Tue, 14 Apr 2020 at 19:43, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Does anyone know how FRR treats “fd80” prefixes? My configuration uses “fd80” prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these “fd80” addresses to “fe80”.
A (sanitized?) configuration snippet/example from your set-up will help you get relevant answers ;) Cheers, Chriztoffer _______________________________________________ frog mailing list frog@lists.frrouting.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frrouting.org%2Flistinfo%2Ffrog&data=02%7C01%7Cvijayg%40vmware.com%7C6ba3fe7e1b2243f0608608d7e158c291%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637225643687012154&sdata=D4UcJZys%2F0%2BNriTN12OczSA9DBBYD7zfhN7jaxHVEpc%3D&reserved=0
Was this new behavior added in FRR? My links keep getting dropped and re-added in FRR compared to Quagga. I was wondering if the defaulted link-local nexthops would be the cause for why the routes are unstable in FRR. Also, would the route-map change increase the route stability? Thank you, Katherine -----Original Message----- From: Vijay Kumar Gupta [mailto:vijayg@vmware.com] Sent: Wednesday, April 15, 2020 9:31 AM To: Tran (US), Katherine K <katherine.k.tran@boeing.com>; ch@ntrv.dk; frog@lists.frrouting.org Subject: RE: [FROG] fd80 prefix allocation This is correct behaviour , IPv6 BGP update message will have both next hop (global and link-local) and by default route will get installed with link-local nexthop. You can apply route-map to change nexthop as global. Thanks Vijay -----Original Message----- From: frog <frog-bounces@lists.frrouting.org> On Behalf Of Tran (US), Katherine K Sent: 15 April 2020 21:48 To: ch@ntrv.dk; frog@lists.frrouting.org Subject: Re: [FROG] fd80 prefix allocation In frr.conf, bgp neighbors are set to fd80::X:X. But, the next hop is shown to be fe80::X:X when the command "show bgp" is issued. Please see below for more details. Note: Some MTUs are set to 1400. The original configuration was run in Quagga and worked. -------------------------------------------------------------------------------------------- FRR vtysh terminal -------------------------------------------------------------------------------------------- AERO-Relay# show bgp BGP table version is 10896, local router ID is 10.0.4.2, vrf id 0 Default local pref 100, local AS 1 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 2001:db8:1:1::/64 fe80::1:2 1024 0 2 ? *> 2001:db8:1:2::/64 fe80::2:2 1024 0 3 ? *> 2001:db8:1:3::/64 fe80::1:2 1024 0 2 ? *> 2001:db8:1:4::/64 fe80::2:2 1024 0 3 ? *> fd80::1:0/112 fe80::1:2 0 0 2 ? *> fd80::1:2/128 fe80::1:2 1024 0 2 ? *> fd80::2:0/112 fe80::2:2 0 0 3 ? *> fd80::2:2/128 fe80::2:2 1024 0 3 ? Displayed 8 routes and 8 total paths -------------------------------------------------------------------------------------------- frr.conf -------------------------------------------------------------------------------------------- log file /var/log/frr/frr.log debugging interface eth0 ip address 10.0.4.2/24 interface eth1 ipv6 address 2001::1/64 interface aero2 ipv6 address fd80::1:1/112 interface aero3 ipv6 address fd80::2:1/112 ! Static routes ip route 0.0.0.0/0 10.0.4.1 ! BGP configuration ! ! You should configure the AS number below, ! along with this router's peers. ! router bgp 1 bgp router-id 10.0.4.2 no bgp default ipv4-unicast neighbor fd80::1:2 remote-as 2 neighbor fd80::1:2 interface aero2 neighbor fd80::2:2 remote-as 3 neighbor fd80::2:2 interface aero3 address-family ipv6 neighbor fd80::1:2 activate neighbor fd80::1:2 next-hop-self neighbor fd80::1:2 default-originate neighbor fd80::1:2 distribute-list blackhole out neighbor fd80::2:2 activate neighbor fd80::2:2 next-hop-self neighbor fd80::2:2 default-originate neighbor fd80::2:2 distribute-list blackhole out exit-address-family ipv6 access-list blackhole deny any Thank you, Katherine -----Original Message----- From: Chriztoffer Hansen [mailto:ch@ntrv.dk] Sent: Tuesday, April 14, 2020 3:26 PM To: Tran (US), Katherine K <katherine.k.tran@boeing.com> Cc: frog@lists.frrouting.org Subject: Re: [FROG] fd80 prefix allocation Katherine, On Tue, 14 Apr 2020 at 19:43, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Does anyone know how FRR treats “fd80” prefixes? My configuration uses “fd80” prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these “fd80” addresses to “fe80”.
A (sanitized?) configuration snippet/example from your set-up will help you get relevant answers ;) Cheers, Chriztoffer _______________________________________________ frog mailing list frog@lists.frrouting.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frrouting.org%2Flistinfo%2Ffrog&data=02%7C01%7Cvijayg%40vmware.com%7C6ba3fe7e1b2243f0608608d7e158c291%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637225643687012154&sdata=D4UcJZys%2F0%2BNriTN12OczSA9DBBYD7zfhN7jaxHVEpc%3D&reserved=0
On Wed, 15 Apr 2020 at 18:47, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Was this new behaviour added in FRRouting? My links keep getting dropped and re-added in FRRouting compared to Quagga. I was wondering if the defaulted link-local next-hops would be the cause for why the routes are unstable in FRRouting. Also, would the route-map change increase the route stability?
If you increase the log-level for FRRouting. What log messages gets written out regarding what your consider as oscillating routes? Cheers, Chriztoffer
I have the log file as debugging. I am running the configuration with frr.conf. The log output does not generate much. I am referring to the routes added by BGP. I can see the routes oscillating of being added and removed by running the command "ip -6 ro sh" in the linux terminal or "show ipv6 route" through vtysh several times. Either case, the ipv6 routes are being added and removed continuously. Vtysh terminal output of the Relay ----------------------------------------- Relay# show ipv6 route Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route B>* 2001:db8:1:1::/64 [20/1024] via fe80::1:2, eth2, 00:00:00 B>* 2001:db8:1:2::/64 [20/1024] via fe80::2:2, eth3, 00:00:00 B>* 2001:db8:1:3::/64 [20/1024] via fe80::1:2, eth2, 00:00:00 B>* 2001:db8:1:4::/64 [20/1024] via fe80::2:2, eth3, 00:00:00 B fd80::1:0/112 [20/0] via fe80::1:2, eth2, 00:00:00 C>* fd80::1:0/112 is directly connected, eth2, 00:00:21 B>* fd80::1:2/128 [20/1024] via fe80::1:2, eth2, 00:00:00 B fd80::2:0/112 [20/0] via fe80::2:2, eth3, 00:00:00 C>* fd80::2:0/112 is directly connected, eth3, 00:00:21 B>* fd80::2:2/128 [20/1024] via fe80::2:2, eth3, 00:00:00 C * fe80::/10 is directly connected, eth3, 00:00:20 C * fe80::/10 is directly connected, eth2, 00:00:20 C * fe80::/10 is directly connected, eth3, 00:00:21 C>* fe80::/10 is directly connected, eth2, 00:00:21 C * fe80::/64 is directly connected, eth1, 00:00:17 C>* fe80::/64 is directly connected, eth0, 00:00:17 Relay# show ipv6 route Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route C>* fd80::1:0/112 is directly connected, eth2, 00:02:13 C>* fd80::2:0/112 is directly connected, eth3, 00:02:13 C * fe80::/10 is directly connected, eth3, 00:02:12 C * fe80::/10 is directly connected, eth2, 00:02:12 C * fe80::/10 is directly connected, eth3, 00:02:13 C>* fe80::/10 is directly connected, eth2, 00:02:13 C * fe80::/64 is directly connected, eth1, 00:02:09 C>* fe80::/64 is directly connected, eth0, 00:02:09 Thanks, Katherine -----Original Message----- From: Chriztoffer Hansen [mailto:ch@ntrv.dk] Sent: Wednesday, April 15, 2020 3:14 PM To: Tran (US), Katherine K <katherine.k.tran@boeing.com> Cc: Vijay Kumar Gupta <vijayg@vmware.com>; frog@lists.frrouting.org Subject: Re: [FROG] fd80 prefix allocation On Wed, 15 Apr 2020 at 18:47, Tran (US), Katherine K <katherine.k.tran@boeing.com> wrote:
Was this new behaviour added in FRRouting? My links keep getting dropped and re-added in FRRouting compared to Quagga. I was wondering if the defaulted link-local next-hops would be the cause for why the routes are unstable in FRRouting. Also, would the route-map change increase the route stability?
If you increase the log-level for FRRouting. What log messages gets written out regarding what your consider as oscillating routes? Cheers, Chriztoffer
participants (3)
-
Chriztoffer Hansen -
Tran (US), Katherine K -
Vijay Kumar Gupta