- frog - lists.frrouting.org

RIP route announcements & OpenVPN
by Jim Carroll 03 Oct '17

03 Oct '17

We manage a large network of OpenVPN clients that connect into a central location (think Hub & Spoke design). We have a need to distribute RIP routes to these remote machines - but we've run into a design limitation of RIP and was hoping for some guidance. RIPd will not send out announcements through an interface that it knows it learned the routes from (which I believe is 100% in keeping with the RFC). The problem for us is these remote hosts connect into a single tap interface, which OpenVPN uses to maintain their tunnels. This means the Hub can receive routes from the remote hosts, but it will not send out route announcements to the tap that it learns from the remote hosts so that the remotes can then reach other. We have experimented with using the RIP neighbor statement to try to force RIPd to override this restriction, but it looks like this is not honored. That RIPd still will refuse to send out routes to a tap interface from which it sees it learned the route from. We know we could define a series of point-to-point gre tunnels between each remote host and the RIPd hub, and then configure RIPd to distribute routes over each individual gre interface, but this is pretty messy, and we were hoping someone else might have a better idea. Thanks Jim C.

2 2

Default action associated w/ distribute-list
by Jim Carroll 01 Oct '17

01 Oct '17

I've scrutinized the docs https://frrouting.org/user-guide/Filtering-RIP-Routes.html#Filtering-RIP-Rou tes but cannot determine default announcement behavior. So I have a basic question about 'distribute-list prefix' applied outbound to an interface in RIP. Is the default action to permit or deny? For example, say we have router rip distribute-list prefix mylist out eth0 ip prefix-list mylist seq 10 permit 10.0.0.0/8 What would the RIP process do with an announcement for 192.168.0.0/24 - would it default to deny (because it doesn't match the permit list) or would it default to permit?

2 2

Re: [FROG] FRR + VPP( FD.io)
by James Bensley 25 Sep '17

25 Sep '17

On 22 September 2017 at 16:52, Stephen Barry via frog <frog(a)lists.frrouting.org> wrote: > ---------- Forwarded message ---------- > From: Stephen Barry <stephen.barry(a)sensical.net> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 22 Sep 2017 15:52:27 +0000 > Subject: RE: [FROG] FRR + VPP( FD.io) > Hi James > > Assume you have read this? > > https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP Hi Steve, Thanks for your response, Yes I have read that page however, this paragraph was a little off-putting; "Unfortunately the VPP's router plugin is not being actively maintained and is not part of the official VPP repository, being maintained separately in the VPP Sandbox (VPPsb) [5]. Its latest versions are broken since a few changes were made in the VPP API, so we're going to use older versions of VPP/VPPsb where things are known to work." I'm wondering if support between VPP and FRR is on the official feature list (unless I've missed it I can't see it) or roadmap for FRR? Either way, are there any forwarding plane engines that are expected to be officially supported by FRR, other than the Kernel? Cheers, James.

2 2

FRR + VPP( FD.io)
by James Bensley 22 Sep '17

22 Sep '17

Hi All, I've looked through the list archives but couldn't find anything. Are there any data plane software stacks that are supported (officially or not) by FRR apart from the Linux Kernel? Specifically, I am thinking about using FRR for the control plane and VPP for the data plane forwarding on x86 boxes. Does anyone know if anyone is already doing this? Has anyone tired this, results, war stories etc? Cheers, James.

2 1

OSPF and protos
by Алексей Болдырев 17 Aug '17

17 Aug '17

Проблема описанна здесь: https://github.com/FRRouting/frr/issues/995, https://www.linux.org.ru/forum/admin/13617547 Проблема описанна здесь: https://github.com/FRRouting/frr/issues/995 Самое интересное, когда я создал VLAN, то OSPF каким то образом заработал. Это также касается и других протоколов, таких как eigrp. Всю делал на виртуалках. Виртуалки запущенны через libvirt.

1 0

FRR 3.0-rc1 tagged & available for testing
by David Lamparter 16 Aug '17

16 Aug '17

Hi all, FRRouting 3.0-rc1 has been tagged on git and the appropriate tarballs are available for download at: https://github.com/FRRouting/frr/releases/tag/frr-3.0-rc1 https://github.com/FRRouting/frr/releases/download/frr-3.0-rc1/frr-3.0-rc1.… For a list of changes, please refer to https://github.com/FRRouting/frr/wiki/FRR-2.0-%E2%86%92-FRR-3.0-Changelog Highlights include: - BGP Large Community support - OSPFv3 Authentication/Confidentiality support - PIM-SM - NHRP - L2VPN/VPLS support (OpenBSD only) The CLI has been significantly reworked, though old configurations should still load. This would be a good time for all interested parties to test and file issues on github for any problems found: https://github.com/FRRouting/frr/issues This *is* a release candidate, so please expect a glitch or two. Cheers, -David

1 0

PIM VRF
by Donald Sharp 03 Aug '17

03 Aug '17

All - The ability for PIM to work within the context of linux VRF's has been committed into master. To configure for a VRF: vrf red <---- VRF configuration, same as global configuration ip pim ecmp ip pim rp 99.1.1.1 224.0.0.0/4 interface vrf red ip pim sm The 'interface vrf red' is treated like the loopback. So if you intend to use the particular router as a RP you should configure an ip address on your vrf device and configure pim to use it. interface swp1 vrf red <----- Turn on pim on the interface as per normal ip pim sm interface swp2 vrf red ip pim sm ip igmp thanks! donald

1 0

network xxx in BGP configurations not working?
by Nigel Kukard 30 Jul '17

30 Jul '17

Hi guys, I must be doing something wrong here, because switching this configuration from Quagga to FRR 2.0 results in the network xxx routes not being sent? (my config below doesn't show v6 routes, but its not working either, I've sed'd out the actual AS and IP ranges) Re-distributed routes do however work. === > Router 1 < === Current configuration: ! frr version 2.0 frr defaults datacenter no ip forwarding no ipv6 forwarding username cumulus nopassword ! service integrated-vtysh-config ! debug bgp neighbor-events debug bgp update-groups debug bgp updates in debug bgp updates out debug bgp zebra ! log file /var/log/frr/frr.log ! router-id 9.9.9.9 ! router bgp 65001 no bgp default ipv4-unicast neighbor 10.10.140.48 remote-as 65002 neighbor fec0::48 remote-as 65002 ! address-family ipv4 unicast network 10.201.142.0/24 network 10.201.146.0/24 network 10.201.185.0/24 network 10.201.189.0/24 network 10.201.229.0/24 network 10.201.244.0/24 network 10.201.254.0/24 redistribute static neighbor 10.10.140.48 activate neighbor 10.10.140.48 next-hop-self exit-address-family ! address-family ipv6 unicast neighbor fec0::43 activate exit-address-family ! line vty ! end --------------------------------- debian# show ip bgp BGP table version is 0, local router ID is 9.9.9.9 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path 10.201.142.0/24 0.0.0.0 0 32768 i 10.201.146.0/24 0.0.0.0 0 32768 i 10.201.185.0/24 0.0.0.0 0 32768 i 10.201.189.0/24 0.0.0.0 0 32768 i 10.201.229.0/24 0.0.0.0 0 32768 i 10.201.244.0/24 0.0.0.0 0 32768 i 10.201.254.0/24 0.0.0.0 0 32768 i Displayed 7 routes and 7 total paths --------------------------------- debian# show ip bgp sum BGP router identifier 9.9.9.9, local AS number 65001 vrf-id 0 BGP table version 0 RIB entries 13, using 1560 bytes of memory Peers 2, using 81 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd debian(10.10.140.48) 4 65002 477 476 0 0 0 00:12:01 0 Total number of neighbors 1 === > Router 2 < === Current configuration: ! frr version 2.0 frr defaults datacenter username cumulus nopassword ! service integrated-vtysh-config ! debug bgp neighbor-events debug bgp update-groups debug bgp updates in debug bgp updates out debug bgp zebra ! log file /var/log/frr/frr.log ! router-id 8.8.8.8 ! router bgp 65002 no bgp default ipv4-unicast neighbor 10.10.140.47 remote-as 65001 neighbor fec0::47 remote-as 65001 ! address-family ipv4 unicast network 10.99.142.0/24 network 10.99.146.0/24 network 10.99.185.0/24 network 10.99.189.0/24 network 10.99.229.0/24 network 10.99.244.0/24 network 10.99.254.0/24 neighbor 10.10.140.47 activate neighbor 10.10.140.47 next-hop-self exit-address-family ! address-family ipv6 unicast neighbor fec0::47 activate neighbor fec0::47 next-hop-self exit-address-family ! line vty ! end --------------------------------- debian# show ip bgp BGP table version is 0, local router ID is 8.8.8.8 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path 10.99.142.0/24 0.0.0.0 0 32768 i 10.99.146.0/24 0.0.0.0 0 32768 i 10.99.185.0/24 0.0.0.0 0 32768 i 10.99.189.0/24 0.0.0.0 0 32768 i 10.99.229.0/24 0.0.0.0 0 32768 i 10.99.244.0/24 0.0.0.0 0 32768 i 10.99.254.0/24 0.0.0.0 0 32768 i Displayed 7 routes and 7 total paths --------------------------------- debian# show ip bgp sum BGP router identifier 8.8.8.8, local AS number 65002 vrf-id 0 BGP table version 0 RIB entries 13, using 1560 bytes of memory Peers 2, using 41 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd debian(10.10.140.47) 4 65001 509 527 0 0 0 00:13:36 0 Total number of neighbors 1 -N

1 1

Announcing EVPN support merged to FRRouting master
by David Lamparter 15 Jul '17

15 Jul '17

Hello everyone, just an hour ago, we've merged EVPN support into FRRouting's master branch. I'd particularly like to thank Vivek Venkatraman (author of most of it), Donald Sharp, Lou Berger, Philippe Guibert and Russ White for their hard work in getting this rather large chunk of code through. As always there are things left to be polished, but right now it's time to have some cake! Cheers, -David P.S.: as context for the FROG list, this will be in the next release /after/ 3.0, so it's still some time out.

3 2

EIGRP - Zebra version mismatch
by Crypto.Troop 27 Jun '17

27 Jun '17

Hi, With EIGRP I am receiving these messages: EIGRP: zclient_read: socket 12 version mismatch, marker 0, version 0 I cannot seem to manage EIGRP via vtysh. I add "router eigrp 1" and a "network x.x.x.x/24" and show run fails to show any EIGRP configs. I can telnet to EIGRP's TCP socket, but no matter what configuration I put in, there seems to be no outbound Hello's when I tcpdump my LAN interface. Other routing daemons such as BGPD are working fine with no errors. I installed per this: https://github.com/FRRouting/frr/blob/master/doc/Building_FRR_on_Ubuntu1604… I am manually running it with /usr/lib/frr/eigrpd -u frr -g frr --vty_socket /var/run/frr/ -i /var/run/frr/eigrpd.pid -z /var/run/frr/zebra.vty -f /etc/frr/eigrpd.conf Any ideas? Thanks

2 3