- frog - lists.frrouting.org

Setting defaults for autodetected VRFs/VxLANx
by Eugene Crosser 15 Jul '19

15 Jul '19

Hello all, we are trying use BGP-EVPN + VRF on Linux in L3 mode. For each VPN instance, we add two snippets into the FRR configuration: Snippet 1: ==== vrf <vrf-iface-name> vni <vni> prefix-routes-only exit-vrf ==== Snippet 2: ==== router bgp 64512 vrf <vrf-iface-name> bgp router-id 169.254.0.1 ! address-family ipv4 unicast redistribute kernel exit-address-family ! address-family l2vpn evpn advertise ipv4 unicast exit-address-family ==== Our use case requires dynamic creation and removal of VRF instances on demand. I understand that FRRouting can autodetect VRF+VxLAN interface groups that are already present in the system and start serving them, but only as "classic" L2VPNs. My question is: should it be made possible (or maybe it is already possible?) to set default attributes for VRF/EVPNs that FRR autodetects? So that one could add something like this just once: ==== vrf DEFAULT vni AUTODETECT prefix-routes-only exit-vrf ==== ==== router bgp 64512 vrf DEFAULT bgp router-id 169.254.0.1 ! address-family ipv4 unicast redistribute kernel exit-address-family ! address-family l2vpn evpn advertise ipv4 unicast exit-address-family ==== and then all newly created VRF+VxLAN groups would be automatically picked up by FRR and configured as L3 EVPNs, without the need to rewrite configuration file and restart the daemon. Does this make sense or am I missing something? On a related note, I understand that currently FRR can fetch FDB only from 'bridge' interfaces, but not directly from VxLAN interfaces. So VxLAN interface cannot be directly enslaved into the VRF interface, but instead we have to add an intermediate bridge: "vrfXX---brXX---vxlanXX". (while client interfaces are directly enslaved into the VRF interface). In such setup, 'br' interface seems unnecessary. Should it be made possible to avoid this redundant 'br' interface? Thank you, and don't get too angry if I am messing things up: I am pretty new to this. Eugene

2 4

Where do those massive ARP tables come from?
by Bernd 15 Jul '19

15 Jul '19

Hi list, I have a bunch of three routers running in a project, let's call them A, B and C. They connect to multiple AS upstream and internally via OSPF and RIPng. While B is based on an (ancient) Ubuntu 12.04.5 and (also ancient) Quagga (0.99.20.1), A and C run very recent CentOS 7 and FRR 6.0.2. B performs perfectly, while A and C put massive pressure on some Cisco switches they're connected to (OSPF and RIPng): They're sending about 2k ARP requests per second each. Looking at the ARP table (``ip nei show'') of A and C, I see about 20k entries, almost all of them in nud "FAIL" (unreachable). Most of them are IPs within the customer's AS (this is VLAN310 in the graphs attached), but some are random public IPv4 addresses. I did compare all sysctl settings to no avail, they're all set in a sane and safe manner. Every daemon not needed or adding not necessary complexity (like NetworkManager) is disabled and not running on A and C. ARP flux can be ruled out, too. Any idea what is going on here? Best Bernd

2 4

Optional attribute error peering BGP with BIRD
by Derrick Lim 11 Jul '19

11 Jul '19

Hello everyone, I’m having an issue with FRR running on Cumulus (4.0+cl3u10), which is peering BGP to BIRD (2.0.2, also tried 1.6.3). When certain routes from FRR are advertised to BIRD (I configured them through vrf leaking on FRR, but not sure if that matters, or its just something with the routes), BIRD terminates the BGP session with an `Optional attribute error` (on BIRD 2.0.2, different error on 1.6.3) when receiving the BGP UPDATE message. I’m not sure if this an FRR or BIRD issue, so I'm hoping someone here could take a look if the UPDATE message from FRR could possibly be malformed, or is BIRD handling this in an odd way. I've attached the tcpdump as well as error logs from BIRD, along with the bird.conf, as well a portion of the FRR config. 100.91.38.1 is the host running BIRD. 100.91.38.61 is the host running FRR. Regards, Derrick

2 1

Certificate expired for lists.frrouting.org
by Timo Schöler 01 Jul '19

01 Jul '19

Hi, yesterday, on Sun, 30 Jun 2019 18:37:42 UTC, the SSL/TLS certificate expired on lists.frrouting.org. Seems autorenewal of that Let's Encrypt cert failed? Best Timo

2 1

FRRouting on Juniper EX series switches
by Hansen, Christoffer 29 Jun '19

29 Jun '19

FROG & R.W., After reading [0] about FRRouting on JUNOS. I was wondering if it is possible to install JUNOS on a recently-ish EX switch series device? (E.g. 3300/3400) It is the same Operating System on top. Thou different hardware and chipsets beneth, compared to MX's. The article shows the example with a vMX and mentioning references to the Trio chipset used in series of MX routers by Juniper. /Christoffer [0]: https://forums.juniper.net/t5/Industry-Solutions-and-Trends/FRRouting-on-Ju…

2 2

staticd blackhole recursive not allowing more specific routes to work
by Patrick Boutilier 26 Jun '19

26 Jun '19

FRR 7.1 CentOS 7.6.1810 With this in staticd.conf ip route 10.1.0.0/16 Null0 everything in 10.1.0.0/16 gets blackholed even if there is a more specific route. Is this normal behaviour? If so, is there a way to turn off recursive? In vtysh: # 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 S>* 10.1.0.0/16 [1/0] unreachable (blackhole), 00:07:41 S> 10.1.1.0/24 [1/0] via 10.1.2.1 (recursive), 00:07:41 * unreachable, 00:07:41 C>* 10.1.2.0/24 is directly connected, eth0, 00:06:59 From bash: # ip r s|grep hole blackhole 10.1.0.0/16 proto 196 metric 20 blackhole 10.1.1.0/24 proto 196 metric 20

2 4

No "ip route" command in zebra
by Patrick Boutilier 23 Jun '19

23 Jun '19

FRR 7.1 CentOS 7.6.1810 Router(config)# ip forwarding Turn on IP forwarding import-table import routes from non-main kernel table multicast Multicast options nht Filter Next Hop tracking route resolution prefix-list Build a prefix list protocol Filter routing info exchanged between zebra and protocol Do you have to use staticd now for static routes?

2 2

Configured AFI/SAFIs do not overlap
by Andre Roberge 19 Jun '19

19 Jun '19

** *Hi everyone, * * I am new to frr, sorry if this is not the right place for this question. I’m trying to peer with my providers in IPv4 and IPv6, the IPv4 part is working great but I get an error on IPv6. Any help would be greatly appriciated ! Andre Roberge andre.roberge(a)maskicom.net 2019/06/19 09:54:45 BGP: 2607:fa48:f000:1b::1 OPEN has Prefixlist (old) ORF capability as Both for afi/safi: 2/1 2019/06/19 09:54:45 BGP: [EC 33554451] 2607:fa48:f000:1b::1 [Error] Configured AFI/SAFIs do not overlap with received MP capabilities 2019/06/19 09:54:45 BGP: %NOTIFICATION: sent to neighbor 2607:fa48:f000:1b::1 2/7 (OPEN Message Error/Unsupported Capability) 6 bytes 01 04 00 02 00 01 2019/06/19 09:54:45 BGP: [EC 33554451] bgp_process_packet: BGP OPEN receipt failed for peer: 2607:fa48:f000:1b::1 2019/06/19 09:54:45 BGP: 2607:fa48:f000:1b::1 [FSM] BGP_Stop (OpenSent->Idle), fd 23 2019/06/19 09:54:45 BGP: bgp_fsm_change_status : vrf 0, established_peers 1 2019/06/19 09:54:45 BGP: 2607:fa48:f000:1b::1 went from OpenSent to Deleted Here is the Router Config Current configuration: ! frr version 7.0RPKI frr defaults traditional hostname vr1.maskicom.io log file /var/log/frr/bgpd.log no ip forwarding no ipv6 forwarding ! debug bgp keepalives debug bgp neighbor-events debug bgp nht debug bgp update-groups debug bgp updates in debug bgp updates out debug bgp zebra ! router bgp 397033 bgp router-id XXX.XXX.XXX.XXX bgp log-neighbor-changes bgp deterministic-med neighbor XXX.XXX.XXX.XXX remote-as 5769 neighbor XXX.XXX.XXX.XXX password XXXXXX neighbor XXX.XXX.XXX.XXX interface eth0 neighbor XXX.XXX.XXX.XXX update-source eth0 neighbor xxxx:xxxx:xxxx:xxxx::x remote-as 5769 neighbor xxxx:xxxx:xxxx:xxxx::x interface eth0 neighbor xxxx:xxxx:xxxx:xxxx::x update-source eth0 ! address-family ipv4 unicast network 23.154.32.0/24 network 207.253.254.0/24 neighbor XXX.XXX.XXX.XXX remove-private-AS neighbor XXX.XXX.XXX.XXX prefix-list in-filter in exit-address-family ! address-family ipv6 unicast network 2602:fe36::/36 neighbor 2607:fa48:f000:1b::1 remove-private-AS exit-address-family ! ip prefix-list in-filter seq 5 deny 0.0.0.0/0 ip prefix-list in-filter seq 10 deny 0.0.0.0/8 le 32 ip prefix-list in-filter seq 15 deny 10.0.0.0/8 le 32 ip prefix-list in-filter seq 20 deny 100.64.0.0/10 le 32 ip prefix-list in-filter seq 25 deny 127.0.0.0/8 le 32 ip prefix-list in-filter seq 30 deny 169.254.0.0/16 le 32 ip prefix-list in-filter seq 35 deny 172.16.0.0/12 le 32 ip prefix-list in-filter seq 40 deny 192.0.0.0/24 le 32 ip prefix-list in-filter seq 45 deny 192.0.2.0/24 le 32 ip prefix-list in-filter seq 50 deny 192.168.0.0/16 le 32 ip prefix-list in-filter seq 55 deny 198.18.0.0/15 le 32 ip prefix-list in-filter seq 60 deny 198.51.100.0/24 le 32 ip prefix-list in-filter seq 65 deny 203.0.113.0/24 le 32 ip prefix-list in-filter seq 70 deny 224.0.0.0/3 le 32 ip prefix-list in-filter seq 75 deny 0.0.0.0/0 ge 25 ip prefix-list in-filter seq 80 permit 0.0.0.0/0 le 32 ! line vty ! end *

3 2

Re: [FROG] Multiple routing tables and BGP
by Philippe Guibert 17 Jun '19

17 Jun '19

Hi Julien, > We have a use case we don't know how to handle with BGP/FRR. > > # Our problem > Since we don't use VRFs, announce connected links to customers is easy > with prefix-list (ex: 192.168.2.0/24 ge 24 for custA). > But we don't understand how to not use static default route in our > routing tables and inject BGP routes learned from customers in each > routing table. There is a pull request [0] in progress you may be interested in: [0] https://github.com/FRRouting/frr/pull/4265 It adds a new vty command that permits exporting BGP entries to a given routing table. route-map custa_to_link permit 10 set table 302 ! route-map custb_to_link permit 10 set table 303 ! router bgp <> [..] address-family ipv4 unicast neighbor 10.0.0.2 route-map custa_to_link in neighbor 10.0.0.6 route-map custb_to_link in [..] This should help you in solving the BGP exportation to the desired table identifier, without using VRFs. Thanks, Philippe

2 1

Multiple routing tables and BGP
by Julien RICHER 17 Jun '19

17 Jun '19

Hi FRR users, We have a use case we don't know how to handle with BGP/FRR. We need to share : right side : a L3 network with dialup links - without VRF - with BGP in order to learn connected links left side : 3 customers - now : static routing without BGP - futur : with BGP in order to announce their connected links and add redundancy For now, we use multiple routing table and rules in order to isolate customers. ## Examples # Customers interconnexions CustA 10.0.0.2/30 CustB 10.0.0.6/30 # DialUP links pools CustA pool 192.168.2.0/24 CustB pool 192.168.3.0/24 # Multiple routing tables echo 302 custa >> /etc/iproute2/rt_tables echo 303 custb >> /etc/iproute2/rt_tables # Default route ip route add default via 10.0.0.2 dev eth0 table custa ip route add default via 10.0.0.6 dev eth0 table custb # Rules for isolation ip rule add from 192.168.2.0/24 lookup custa ip rule add from 192.168.3.0/24 lookup custb # 2 dialup link for CustA CustA Link1 WAN = 192.168.2.0/32 CustA Link1 LAN = 192.168.2.128/29 CustA Link2 WAN = 192.168.2.1/32 CustA Link2 LAN = 192.168.2.136/29 # Our problem This solution is good for a POC with static routing on customer's side, but we need to use BGP with customers in order to : - provide redundancy - announce its connected dialup links to each customer Since we don't use VRFs, announce connected links to customers is easy with prefix-list (ex: 192.168.2.0/24 ge 24 for custA). But we don't understand how to not use static default route in our routing tables and inject BGP routes learned from customers in each routing table. Is FRR able to inject peer's routes in a specific table without VRFs ? If needed, we can move to VRF on customer side, but since dialup network is not VRF aware, links routes are in vrf0 and we don't understand how to handle it. Is there a solution for this case ? Maybe a route-map would permit to push learned routes of a peer in a specific table ? Thank you, Julien

1 0