- frog - lists.frrouting.org

(no subject)
by conneyh＠fnetlink.com 15 Jan '20

15 Jan '20

Dear frr 请问你们支持ipsec vpn吗？黄刚 Conney 技术工程师/ Technical Engineer Mobile: +86-13141707468 E-mail: conneyh(a)fnetlink.com 座机：0769-23158369-8672 - - - - - - - - - - - - - - - - - - - - 如果您在使用中遇到任何技术上问题，可拔打以下电话，我们将竭诚为您服务：全国服务热线：400-622-8986 香港服务热线：(+852) 2180 7378 台湾服务热线：(+886) 2 7728 7450 地址：东莞市旗峰路190号城市花园商贸中心13楼1302室 Add: Rm 1302, 13/F, Dongguan City Garden Business Center，No.190 Qifeng Road, Dongguan, Guangdong 深圳｜北京｜上海｜广州｜东莞｜香港｜澳门｜台湾

1 0

VTYSH and BGP options
by Simon Attwell 15 Jan '20

15 Jan '20

Hi All, New install of FRR on a Debian box, doing BGP on a couple of interfaces in a VRF (netns based). All is good except most of the bgp neighbour options are missing in VTYSH (neighbor <peer> <option>). In particular the options for weight or as-prepent or as-path filtering are missing. Is there something obvious I'm missing? * Simon

3 4

IPv6 bgp not working properly
by Patrick Boutilier 11 Jan '20

11 Jan '20

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

3 5

Fwd: [PDB Announce] Call for volunteers for PeeringDB
by Chriztoffer Hansen 07 Jan '20

07 Jan '20

Fwd to FROG list, because I thought mayhaps (individual_count >= 1) might be interested... Best Regards, Chriztoffer ---------- Forwarded message --------- From: Stephen McManus <smcmanus(a)peeringdb.com> Date: Mon, 6 Jan 2020 at 22:10 Subject: [PDB Announce] Call for volunteers for PeeringDB To: <pdb-announce(a)lists.peeringdb.com> Hi all, We are looking for volunteers to serve on the PeeringDB Admin and Product Committees. The ideal volunteers are industry professionals who are passionate about improving PeeringDB, and ensuring it meets the needs of the community it supports. We are most interested in people who have significant free time to dedicate to these efforts (as much as 4 or more hours a week). Please don’t volunteer if you can’t commit the time! Admin Committee: • Review requests from community members • Authorize users to organizations and networks • Generally keep PeeringDB’s data trustworthy and correct Product Committee: • Review and prioritize requests for improvements to PeeringDB • Work with developers and community members to specify how to solve problems and implement improvements • Set vision for how PeeringDB can help the community in the future If you are interested in either of these roles, and have time you can commit, please let us know at stefan(a)peeringdb.com for the Admin Committee or smcmanus(a)peeringdb.com for the Product Committee. Please include a sentence or two about yourself, why you want to volunteer and how you think you can help. Thanks! -Steve _______________________________________________ Pdb-announce mailing list Pdb-announce(a)lists.peeringdb.com https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce

1 0

Re: [FROG] loopback interfaces
by Sébastien 65 03 Jan '20

03 Jan '20

I use local interfaces in the file /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # Dummy's auto dummy0 iface dummy0 inet manual iface dummy0 inet6 manual pre-up ip link add dummy0 type dummy auto dummy1 iface dummy1 inet manual iface dummy1 inet6 manual pre-up ip link add dummy1 type dummy On FRR I configure the inferface dummy0 like this : ! interface dummy0 description *** loopback0 *** ip address W.X.Y.Z/32 ipv6 nd suppress-ra ! The loopback (here the dummy) interfaces are used to mount my internal BGP sessions and access to the router from the WAN (public ip).

1 0

loopback interfaces
by Sébastien 65 03 Jan '20

03 Jan '20

Hello, With CISCO I use several interfaces called loopback. On FRR (DEBIAN) what do you recommend to use to reproduce CISCO loopback? We must remember to load the dummy module and modify the number of dummy (options dummy numdummies=4). Lo or dummy interface ?

2 1

Ping using specific interface in vtysh
by Sébastien 65 03 Jan '20

03 Jan '20

Hi, Is it possible to activate source ping on FRR without leaving vtysh ? Start the command with "ping X.X.X.X source lo" Under Linux it is possible to "ping -I lo X.X.X.X", an alias is possible with vtysh ? Thank you

2 2

BGP over GRE interfaces
by Daniel Corbe 01 Jan '20

01 Jan '20

Hello All, My apologies for the incoming wall of text. I'm having an issue with bgpd over a GRE interface. BGP keeps flapping and I suspect it's because the GRE tunnel actually goes down once BGP comes up. Realizing this may be an issue with what's actually being announced, I added host routes to the kernel table for the tunnel endpoints; however that didn't make much of a difference. My setup right now kind of relies on Linux doing the right thing and preferring the longest prefix match to route traffic but I don't think that's what's happening in my case so I'm looking for suggestions on how to proceed. My other, sort of related question, is why does FRR's BGP advertise routes it learns back to the peer it learned them from? Is there a way to stop that behavior? My local endpoint (hostname alpine) is configured like this: auto gre1 iface gre1 inet manual pre-up ip tunnel add gre1 mode gre remote 193.160.88.2 local 73.57.99.182 ttl 255 pre-up ip route add 193.160.88.2/32 via $(ip -4 route list default | awk '{print $3}') pre-up ip addr add 10.64.14.2/24 dev gre1 pre-up ip link set gre1 up post-down ip route del 193.160.88.2/32 post-down ip tunnel del gre1 alpine# show run Building configuration... Current configuration: ! frr version 7.2 frr defaults traditional hostname alpine ! router bgp 65001 neighbor core peer-group neighbor core remote-as 57335 neighbor core bfd neighbor 10.64.14.1 peer-group core ! address-family ipv4 unicast redistribute connected exit-address-family ! line vty ! bfd peer 10.64.14.1 no shutdown ! ! end The remote side (hostname melbidedi1-vrf) is configured like this: auto gre1 iface gre1 inet manual pre-up ip tunnel add gre1 mode gre local 193.160.88.2 remote 73.57.99.182 ttl 255 pre-up ip route add 73.57.99.182/32 via $(ip -4 route list default | awk '{print $3}') pre-up ip addr add 10.64.14.1/24 dev gre1 pre-up ip link set gre1 up post-down ip route del 73.57.99.182/32 post-down ip tunnel del gre1 melbidedi1-vrf# show run Building configuration... Current configuration: ! frr version 7.2 frr defaults traditional hostname melbidedi1 hostname melbidedi1-vrf ! router bgp 57335 neighbor corbe peer-group neighbor corbe remote-as 65001 neighbor corbe bfd neighbor core peer-group neighbor core remote-as 57335 neighbor 10.64.14.2 peer-group corbe neighbor 193.160.88.1 peer-group core ! address-family ipv4 unicast redistribute connected neighbor core next-hop-self exit-address-family ! ip prefix-list AS57335-V4 seq 10 permit 184.203.204.0/22 le 24 ip prefix-list AS57335-V4 seq 15 permit 193.160.88.0/22 le 24 ip prefix-list AS57335-V4 seq 20 permit 45.154.216.0/22 le 24 ip prefix-list AS57335-V4 seq 5 permit 45.132.96.0/22 le 24 ip prefix-list DEFAULT-V4 seq 5 permit 0.0.0.0/0 ip prefix-list INTERNET-V4 seq 5 permit 0.0.0.0/0 le 24 ! line vty ! bfd peer 10.64.14.2 no shutdown ! ! end alpine routing table (as you can see the more specific route is in the kernel routing table): alpine# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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 K>* 0.0.0.0/0 [0/203] via 73.57.98.1, eth1, src 73.57.99.182, 00:53:51 C>* 10.0.0.0/24 is directly connected, eth2, 00:53:51 C>* 10.64.14.0/24 is directly connected, gre1, 00:29:15 K * 73.57.98.0/23 [0/203] is directly connected, eth1, 00:53:51 C>* 73.57.98.0/23 is directly connected, eth1, 00:53:51 K * 169.254.0.0/16 [0/204] is directly connected, eth2, 00:53:50 C>* 169.254.0.0/16 is directly connected, eth2, 00:53:50 When the tunnel is up, these are the routes being advertised: alpine# show ip bgp neighbors 10.64.14.1 advertised-routes BGP table version is 4151, local router ID is 73.57.99.182, vrf id 0 Default local pref 100, local AS 65001 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 *> 10.0.0.0/24 0.0.0.0 0 32768 ? *> 10.64.14.0/24 0.0.0.0 0 32768 ? *> 73.57.98.0/23 0.0.0.0 0 32768 ? *> 172.16.1.0/24 10.64.14.1 0 57335 ? *> 193.160.88.0/22 10.64.14.1 0 57335 ? *> 193.160.88.0/24 10.64.14.1 0 57335 ? *> 213.183.46.232/29 10.64.14.1 0 57335 ? Routing table on melbidedi1-vrtf: melbidedi1-vrf# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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 K>* 0.0.0.0/0 [0/0] via 193.160.88.1, eth0, 1d10h18m B>* 10.0.0.0/24 [20/0] via 10.64.14.2, gre1, 00:00:00 C>* 10.64.14.0/24 is directly connected, gre1, 00:23:32 B>* 73.57.98.0/23 [20/0] via 10.64.14.2, gre1, 00:00:00 K>* 73.57.99.182/32 [0/0] via 193.160.88.1, eth0, 00:23:32 C>* 172.16.1.0/24 is directly connected, eth1, 1d10h18m B>* 193.160.88.0/22 [200/0] via 193.160.88.1, eth0, 15:56:10 C>* 193.160.88.0/24 is directly connected, eth0, 1d10h18m B>* 213.183.46.232/29 [200/0] via 193.160.88.1, eth0, 15:56:10 melbidedi1-vrf# show ip bgp neighbors 10.64.14.2 advertised-routes BGP table version is 1146, local router ID is 193.160.88.2, vrf id 0 Default local pref 100, local AS 57335 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 *> 10.0.0.0/24 10.64.14.2 0 65001 ? *> 10.64.14.0/24 0.0.0.0 0 32768 ? *> 73.57.98.0/23 10.64.14.2 0 65001 ? *> 172.16.1.0/24 0.0.0.0 0 32768 ? *> 193.160.88.0/22 0.0.0.0 100 0 ? *> 193.160.88.0/24 0.0.0.0 0 32768 ? *> 213.183.46.232/29 0.0.0.0 100 0 ? Total number of prefixes 7

1 0

TCP retransmits
by Travis Garrison 31 Dec '19

31 Dec '19

We are getting sporadic speed issues and other weirdness after we installed our 2 new cores running FRR. The routers are HP DL380G8 servers with 64Gb of ram, dual Intel Xeon E5-2690 V2 3GHz 10 core CPUs. We disabled hyperthreading. The nics are Mellanox ConnectX3 Pros 40Gb using the native drivers from Debian 10. All updates and firmware have been applied. We show no errors in the frr.log or messages. We did notice that in a packet capture we are getting a lot of TCP retransmits and TCP out of orders on the internal side. Looks to be about 40 to 50% of our traffic is retransmits. Anyone here have any ideas? We have 2 10Gb internet feeds coming into 2 Mikrotik CRS326-24S+2Q+RM core switches. These switches are then connected with 40Gb DAC cables to the core routers on interface eno1. The switches are not connected together. The 2 core routers also have a 40Gb DAC cable connecting both together on interface eno1d1. Also we have 2 10Gb fiber feeds running to all the edge routers which are Mikrotik RB4011 or CCR1009s that are connected to the core switches. I can draw a diagram out but was unsure if I could attach it to this email or not. The core routers are running an MTU size of 2000 (with the exception of the ISP feed which is running 1500). We have verified that the edge routers and core switches are also running at 2000 MTU. The fiber network supports up to 8096 MTU. ISP1 is giving us full tables while ISP2 is currently giving us a default route only. They will be adding the capability of BGP and full routes in the next month. Through ISP1 we are also joining the local IXC and will be peering with Netflix. Do we need to redistribute the routes between the 2 cores? Core router /etc/network/interfaces auto eno1 iface eno1 inet manual mtu 2000 #ISP auto eno1.4003 iface eno1.4003 inet static address 1x.x.58.114/30 gateway 1x.x.58.113 dns-nameservers x.x.253.138 x.x.2.3 mtu 1500 #RTR auto eno1.3202 iface eno1.3202 inet static address 10.77.129.4/31 #Crossconnect to Core 2 auto eno1d1 iface eno1d1 inet static address 10.77.129.0/31 mtu 2000 #FRR interface eno1.3202 ip ospf network point-to-point ! interface eno1d1 ip ospf cost 1 ip ospf network point-to-point ! router-id 10.77.131.0 ! router bgp 1234 neighbor 10.77.131.1 remote-as 1234 neighbor 10.77.131.1 update-source 10.77.131.0 neighbor 1x.x.58.113 remote-as 4321 neighbor 1x.x.58.113 update-source 1x.x.58.114 ! address-family ipv4 unicast network 10.x.20.0/24 neighbor 10.77.131.5 default-originate route-map GW neighbor 10.77.131.5 prefix-list defaultonly out neighbor 1x.x.58.113 soft-reconfiguration inbound neighbor 1x.x.58.113 prefix-list infilter in neighbor 1x.x.58.113 prefix-list outfilter out exit-address-family ! router ospf ospf router-id 10.77.131.0 passive-interface eno1.4003 network 10.77.129.0/31 area 0.0.0.0 ! ip prefix-list defaultonly seq 100 permit 0.0.0.0/0 ip prefix-list infilter seq 100 permit 0.0.0.0/0 le 24 ip prefix-list infilter seq 6 deny 10.77.128.0/22 le 32 ip prefix-list outfilter seq 5 permit 10.x.20.0/24 le 24 ! route-map GW permit 10 set metric 1 #ip l 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether x:x:1b:80:c4:01 brd ff:ff:ff:ff:ff:ff 3: eno1d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether x:x:1b:80:c4:02 brd ff:ff:ff:ff:ff:ff 5: eno1.4003@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether x:x:1b:80:c4:01 brd ff:ff:ff:ff:ff:ff 8: eno1.3202@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether x:x:1b:80:c4:01 brd ff:ff:ff:ff:ff:ff Thanks Travis Garrison

2 1

RES: frog Digest, Vol 33, Issue 18
by Junior Corazza 29 Dec '19

29 Dec '19

Hello Donald, how are you? I understand that it may be a limitation of FRR or some kernels to apply l2vpn mpls, but in this case specifically I would not need FRR to participate in the VPN, the idea is that FRR serves exclusively to be RouteReflector of address-family l2vpn mpls. I will use other routers to effectively make Kompella l2vpn. I know you are an active contributor to the project, do you think this could happen in FRR? Tks ----------------------------------------------- From: Donald Sharp <sharpd(a)cumulusnetworks.com> To: Junior Corazza <corazza(a)telic.com.br> Cc: frog <frog(a)lists.frrouting.org> Subject: Re: [FROG] L2vpn MPLS AFI Message-ID: <CAK989yfbEGDwG6o5f7tKaPrW2CXmwUS+BS0F1n++xTqNE0XQgA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" FRR does not have the capability of doing `l2vpn mpls` at this point in time. I am not aware of anyone publically working on this feature at this point in time. donald On Thu, Dec 26, 2019 at 9:12 PM Junior Corazza <corazza(a)telic.com.br> wrote: > > Hello people. > > I was testing FRR 7.2 to use it as RouteReflecor for l2vpn and l3vpn. > The problem is that there is no address family for l2vpn mpls, there > is only for evpn. > > Can you tell me if it is possible to use RouteReflector for L2vpn Kompella? > I mean, is there this feature? > If not, can you tell me if this is in the roadmap of the project? > > > > > > > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog ------------------------------ Subject: Digest Footer _______________________________________________ frog mailing list frog(a)lists.frrouting.org https://lists.frrouting.org/listinfo/frog ------------------------------ End of frog Digest, Vol 33, Issue 18 ************************************

2 1