- frog - lists.frrouting.org

WireGuard CKR key from BGP dupport
by Алексей 01 Feb '20

01 Feb '20

As an idea to implement key exchange through ckr by bgp from WireGuard?

1 0

Dual Core Design
by Travis Garrison 28 Jan '20

28 Jan '20

Trying to make sure I have the design down. We have 2 cores and 2 upstream connections. We also have a cross connect to an IX off 1 core. What would be the best way to configure iBGP between the cores so that we would gain the benefit of the IX from both cores and concurrent/failover usage from both upstream providers. Both upstream providers are the same speed and we advertise our networks to both in a multihomed scenario. We may be adding a 3rd core/upstream provider in the future. Core1 connects to ISP1 (full table) and IX Core2 connects to ISP2 (full table) All edge routers have an iBGP connection to both core routers and receive default routes only. Debian 10 FRR 7.2 Thanks Travis

1 0

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

16 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 16 Jan '20

16 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 08 Jan '20

08 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 02 Jan '20

02 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