- frog - lists.frrouting.org

BGP L3VPN support
by Heidi net 06 Jun '19

06 Jun '19

Hello, I am trying to migrate from IOX to FRR4.0. I have a simple configuration of 2 VRFs: red and blue. No VRF route leaking is needed. I know VRF route leaking was added to FRR5.0. But since I don’t do that. Can FRR4.0 be used to - Configure 2 VRFs for routes, attach different RD/RT to routes, and advertise routes into corresponding VPNs with FRR4.0? - Any configuration examples? Below is the current Cisco configuration. ip vrf red rd 100:101 route-target export 200:101 route-target import 200:101 ! ip vrf blue rd 100:201 route-target export 200:201 route-target import 200:201 ! interface Loopback101 ip vrf forwarding red ! interface Loopback102 ip vrf forwarding blue ! router bgp 100 neighbor 10.10.10.2 remote-as 200 neighbor 10.10.10.2 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.2 activate neighbor 10.10.10.2 send-community both exit-address-family ! address-family ipv4 vrf red redistribute connected exit-address-family ! address-family ipv4 vrf blue redistribute connected exit-address-family thanks - Heidi

3 6

PIM-BSM implementation in FRR
by Donald Sharp 05 Jun '19

05 Jun '19

All - Recently an implementatation of PIM-BSM was pushed into the master branch of FRR. This first release of this feature is slightly limited in it's scope, in that PIM routers can listen and respond to BSM PIM messages but cannot self-elect to make themselves an RP. By default this functionality is turned on. To turn it off issue a `no ip pim bsm` command from the cli. Further documentation can be found at http://docs.frrouting.org/en/latest/pim.html I'd like to thank Saravanan, Sarita and Rajesh for their work on getting this in. thanks! donald

2 2

Protobuf (FPM) usage survey
by David Lamparter 22 May '19

22 May '19

Hello FRR users and developers, since some extensions to the FPM interface are currently happening, it'd be nice to know how much the Protobuf interface is used. We know the netlink encoding is well used, but we don't have data for Protobuf. If you're using **Protobuf** FPM, please send a mail (in private if necessary.) Again just to be clear: this is about Protobuf FPM, NOT Netlink FPM. Cheers, -David

1 0

Announcing support for VRRP
by Quentin Young 21 May '19

21 May '19

Greetings operators, A few days ago, support for VRRP (Virtual Router Redundancy Protocol) was merged into master. VRRP is used to provide router redundancy on LANs. FRRouting supports versions 2 and 3 of the protocol. Our next release will not have this new protocol. It will ship in the subsequent release, around September/October. In the meantime it is available in our master Git branch. RFCs: https://tools.ietf.org/html/rfc5798 <https://tools.ietf.org/html/rfc5798> https://tools.ietf.org/html/rfc3768 <https://tools.ietf.org/html/rfc3768> FRRouting documentation: http://docs.frrouting.org/en/latest/vrrp.html <http://docs.frrouting.org/en/latest/vrrp.html> Big thanks to everyone who worked with me on this new protocol daemon! Quentin

3 3

Question about pimd
by kevin-chiang 13 May '19

13 May '19

Dear developers, We have some questions about pimd: 1. I see some IGMP related code in pim folder and also see the following description in README: In order to deliver end-to-end multicast routing control plane, qpimd includes the router-side of IGMPv[2|3] (RFC 3376). ==> Does it means FRR totally compliance with RFC3376?? 2. If user has its own IGMP daemons to handle IGMP packets and then install multicast route to kernel. Does FRR pimd can work with this without enable its IGMP feature? Or you will suggest user to use FRR IGMP to work with FRR pimd. 3. How pimd retrieve the multicast route change information from zebra? It seems pimd doesn't register such handler to zebra server. 4. Does FRR have any plan to support MLD in the near future? Please guide us Thanks a lot BRs Kevin Loop Telecommunication International, Inc. www.looptelecom.com 8GESW is designed to transport Ethernet services over SDH/SONET networks (EoS). It provides eight GbE ports and a range of standard L2 switch functions, including VLAN, Q-in-Q, MAC learning, MSTP/RSTP, CoS and QoS, and etc. Ethernet bridging services include EPL, EVPL, and EPLAN. Max. bandwidth for SDH/SONET transportation is either STM-4/OC-12 or STM-16/OC-48. Dual 8GESW cards can be mounted simultaneously to achieve card-level protection. Protection switch happens within 50 ms without any traffic interruption. Traffic at the SDH/SONET side is further protected by SNCP/UPSR ring and MSP (1+1). For further arrangement and more information, please do not hesitate to contact Loop Telecom. "Migrating Legacy Networks to the Future"

2 1

FRR 7.0 BGP does not connect to passive neighbor
by Chris G 29 Apr '19

29 Apr '19

Hello, I have an issue where my BGP neighbor is configured in passive mode, however my BGP (FRR 7.0) instance does not attempt to connect to this neighbor. Is this expected behavior? Is there any way I can force my BGP instance to initiate a connection to the passive BGP neighbor ? Thanks, Chris

4 7

discard interface warnings on FreeBSD
by Mike Tancsa 27 Apr '19

27 Apr '19

I have been using the discard interface - DISC(4) - on FreeBSD for some time to tie down supernets. On frr7, I am getting a warning message at startup I am not sure what to make of The nic is configured as # ifconfig disc0 disc0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 65532 inet 10.128.128.144 netmask 0xfffffff8 inet 10.129.129.1 netmask 0xfffffff0 inet6 2001:db8::1 prefixlen 64 inet6 fe80::1%disc0 prefixlen 64 scopeid 0x7 groups: disc nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> And at startup, I get /usr/local/etc/rc.d/frr start Checking zebra.conf 2019/04/26 15:58:44 warnings: ZEBRA: [EC 4043309141] warning: interface disc0 broadcast addr 10.128.128.144/29 != calculated 10.128.128.151, routing protocols may malfunction 2019/04/26 15:58:44 warnings: ZEBRA: [EC 4043309141] warning: interface disc0 broadcast addr 10.129.129.1/28 != calculated 10.129.129.15, routing protocols may malfunction 2019/04/26 15:58:44 warnings: ZEBRA: [EC 4043309105] Disabling MPLS support (no kernel support) OK Starting zebra. 2019/04/26 15:58:44 warnings: ZEBRA: [EC 4043309141] warning: interface disc0 broadcast addr 10.128.128.144/29 != calculated 10.128.128.151, routing protocols may malfunction 2019/04/26 15:58:44 warnings: ZEBRA: [EC 4043309141] warning: interface disc0 broadcast addr 10.129.129.1/28 != calculated 10.129.129.15, routing protocols may malfunction 2019/04/26 15:58:44 warnings: ZEBRA: [EC 4043309105] Disabling MPLS support (no kernel support) If I use the same IP info on another non discard interface it works / doesnt complain. Also, when starting staticd, I get these warnings as well. Checking staticd.conf 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra 2019/04/26 15:58:44 warnings: STATIC: void static_zebra_nht_register(struct static_route *, _Bool): Failure to send nexthop to zebra OK Starting staticd. Looking at the installed routes, it looks ok, except for one which I must be missing something obvious, but its ok on quagga and frr6 I have interface igb1.6: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6> ether 90:e2:ba:01:37:81 inet6 fe80::92e2:baff:fe01:3781%igb1.6 prefixlen 64 scopeid 0xe inet 64.7.149.177 netmask 0xfffffffc broadcast 64.7.149.179 and a static route of ip route 10.87.1.0/30 64.7.149.178 It ends up installing this static route on the discard interface for some reason on frr7. On frr6, it works. next hop is 64.7.149.178. I do get the same warning messages however at startup. On frr5, its the same as frr7. # vtysh -c "show ip route 10.87.1.0/30" Routing entry for 10.87.1.0/30 Known via "static", distance 1, metric 0, best Last update 00:00:14 ago 64.7.149.178 (recursive) * 10.129.129.1, via disc0 kernel confirms # netstat -nr | grep ^10.87.1. 10.87.1.0/30 10.129.129.1 UG1 disc0 # Any ideas what up ? As this is just a test box, there is no MAC addr for the next hop, but would it not mark the route as inactive rather than change the next hop to the discard interface ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike(a)sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada

1 0

Announcing availability of PIM-EVPN BUM Handling
by Donald Sharp 25 Apr '19

25 Apr '19

All - I'd like to thank Anuradha for her work on integrating PIM-EVPN BUM handling in FRRouting. For those of you interested in using this feature you'll need a linux kernel > 5.0 to pick up some new features there. In addition you can read about how to configure here: http://docs.frrouting.org/en/latest/pim.html#pim-evpn-configuration thanks! donald

1 0

FRR on NRL CORE (fyi)
by Phil Wiggins 10 Apr '19

10 Apr '19

If anyone is interested in running FRR in the NRL CORE emulation environment, I have some build scripts for FRR on CORE that I posted at the first link below. Normally CORE runs Quagga, so this script was a hack to shoehorn FRR as a Quagga replacement. These scripts are not part of CORE yet, so are unsupported. People on this list may want to use CORE for FRR experimentation and testing, so you can customize these scripts to suit your own needs. It's best to run this stuff in a VM with no internet connection (after installation) since CORE runs lots of processes as root - a well-known security issue. https://github.com/coreemu/core/issues/170 ( install_frr_for_core.sh) FRR on NRL CORE build script - assumes Ubuntu 16.04.4 clean installation in a VM or physical host: https://gist.github.com/apwiggins/44f3592a61965783372aea5881ed9f7a (core_misc_frr.py ) used by the install script above to install at ./core/misc/frr.py https://gist.github.com/apwiggins/d610c2794c8c0a12a45bfc093fd2e949 (core_services_frr.py) used by the install script above to install at ./core/services/frr.py https://gist.github.com/apwiggins/747a9a14feff2ce3a3b8760406b825a7 https://www.nrl.navy.mil/itd/ncs/products/core The Common Open Research Emulator (CORE) is a tool for emulating networks on one or more machines. You can connect these emulated networks to live networks. CORE consists of a GUI for drawing topologies of lightweight virtual machines, and Python modules for scripting network emulation. Cheers, Phil

2 3

Reg SR Static tunnel config with SID list
by kotesh 08 Apr '19

08 Apr '19

Hi, Does FRR allow to configure SID list for a given prefix (advertised by OSPF SR extensions)? If yes, can somebody point us to some sample config ? Thanks, Kotesh babu.Chundu

1 0