October 2017 - frog - lists.frrouting.org

received-routes.. doesn't work?
by Mark Kamichoff 02 Sep '18

02 Sep '18

Hi - I'm running various 3.1-dev versions of FRR and noticed that the "show ip bgp nei <peer> received-routes" doesn't seem to work as expected on any of them. Here's an example of the relevant parts of the configuration: ! router bgp 395460 neighbor 169.254.169.254 remote-as 64515 neighbor 169.254.169.254 password <snip> neighbor 169.254.169.254 ebgp-multihop 2 address-family ipv4 unicast neighbor 169.254.169.254 soft-reconfiguration inbound neighbor 169.254.169.254 route-map DENY_ALL in neighbor 169.254.169.254 route-map DENY_ALL out exit-address-family ! route-map DENY_ALL deny 65535 ! orca# show ip bgp neighbors 169.254.169.254 routes orca# show ip bgp neighbors 169.254.169.254 received-routes BGP table version is 0, local router ID is 10.3.4.36 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 orca# >From tcpdump and other t-shooting I know that there is an IPv4 DFZ being received, but received-routes doesn't show any of the routes that should be in the adj-rib-in. Oddly, if I remove the inbound route-map I see expected prefixes using the "routes" /and/ "received-routes" command. If I put it back, the "received-routes" shows nothing once again. It would almost seem like soft-reconfiguration isn't really enabled, but received-routes should give me an error if it wasn't and the neighbor information confirms that it is: orca# show ip bgp neighbors 169.254.169.254 <snip> For address family: IPv4 Unicast Update group 5, subgroup 5 Packet Queue length 0 Inbound soft reconfiguration allowed <----- <snip> This isn't limited to the IPv4 AF, either. I've got IPv6 peers that echibit the same behavior. Have I found a bug or am I doing something wrong? I'm happy to file a bug report. More info., if it helps: orca# show version FRRouting 3.1-dev (). Copyright 1996-2005 Kunihiro Ishiguro, et al. configured with: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libexecdir=${prefix}/lib/frr' '--disable-maintainer-mode' '--disable-dependency-tracking' '--enable-exampledir=/usr/share/doc/frr/examples/' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--enable-ospfapi=yes' '--enable-vtysh=yes' '--enable-isisd=yes' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-werror' '--enable-gcc-rdynamic' '--with-libpam' '--enable-systemd=yes' '--enable-poll=yes' '--enable-cumulus=yes' '--enable-pimd=yes' '--enable-dependency-tracking' '--enable-bgp-vnc=no' 'build_alias=x86_64-linux-gnu' orca# (orca:20:08:PDT)% uname -a Linux orca 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64 GNU/Linux (the build is from August 26th) Thanks! - Mark -- Mark Kamichoff prox(a)prolixium.com https://www.prolixium.com/

1 1

Re: [FROG] [dev] VTY status 13 while sending config over vty socket
by Donald Sharp 23 Oct '17

23 Oct '17

Siddhesh - This works for me: dell-s6000-02# conf t dell-s6000-02(config)# exit dell-s6000-02# configure terminal dell-s6000-02(config)# router bgp 1234 vrf foo dell-s6000-02(config-router)# neighbor 2.2.2.2 remote-as 3456 dell-s6000-02(config-router)# neighbor 2.2.2.2 shutdown dell-s6000-02(config-router)# address-family ipv6 unicast dell-s6000-02(config-router-af)# redistribute connected dell-s6000-02(config-router-af)# exit-address-family dell-s6000-02(config-router)# address-family ipv6 unicast dell-s6000-02(config-router-af)# redistribute static dell-s6000-02(config-router-af)# exit-address-family dell-s6000-02(config-router)# address-family ipv4 unicast dell-s6000-02(config-router-af)# redistribute connected dell-s6000-02(config-router-af)# exit-address-family dell-s6000-02(config-router)# address-family ipv4 unicast dell-s6000-02(config-router-af)# redistribute static dell-s6000-02(config-router-af)# exit-address-family dell-s6000-02(config-router)# end dell-s6000-02# end dell-s6000-02# show run ! router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown ! address-family ipv4 unicast redistribute connected redistribute static exit-address-family ! address-family ipv6 unicast redistribute connected redistribute static exit-address-family ! What version of FRR are you using? On Wed, Oct 18, 2017 at 4:06 PM, $iddhe$h Divekar <siddhesh.divekar(a)gmail.com> wrote: > Hi, > Am getting following error when sending config over vty socket. > VTY status 13. > > Below is the config am trying to send. > It happens when "redistribute connected" is sent over the socket. > > configure terminal > router bgp 1234 vrf foo > neighbor 2.2.2.2 remote-as 3456 > neighbor 2.2.2.2 shutdown > address-family ipv6 unicast > redistribute connected > exit-address-family > address-family ipv6 unicast > redistribute static > exit-address-family > address-family ipv4 unicast > redistribute connected > exit-address-family > address-family ipv4 unicast > redistribute static > exit-address-family > end > > If I do show running I see following config applied. > router bgp 1234 vrf foo > neighbor 2.2.2.2 remote-as 3456 > neighbor 2.2.2.2 shutdown > ! > address-family ipv6 unicast > redistribute connected > exit-address-family > ! > > Is there anything wrong with the config. > Copy pasting the config directly works fine. > > -- > -$iddhesh. > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

2 1

VTY status 13 while sending config over vty socket
by $iddhe$h Divekar 20 Oct '17

20 Oct '17

Hi, Am getting following error when sending config over vty socket. VTY status 13. Below is the config am trying to send. It happens when "redistribute connected" is sent over the socket. configure terminal router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown address-family ipv6 unicast redistribute connected exit-address-family address-family ipv6 unicast redistribute static exit-address-family address-family ipv4 unicast redistribute connected exit-address-family address-family ipv4 unicast redistribute static exit-address-family end If I do show running I see following config applied. router bgp 1234 vrf foo neighbor 2.2.2.2 remote-as 3456 neighbor 2.2.2.2 shutdown ! address-family ipv6 unicast redistribute connected exit-address-family ! Is there anything wrong with the config. Copy pasting the config directly works fine. -- -$iddhesh.

1 1

BGP CPU Usage
by Richard J Palmer 17 Oct '17

17 Oct '17

Hi We have FRR running on a number of core routers here - However it seems that bgpd is using 100% CPU most of the time: top - 12:48:16 up 95 days, 20:02, 1 user, load average: 1.41, 1.25, 1.20 Tasks: 151 total, 4 running, 147 sleeping, 0 stopped, 0 zombie %Cpu(s): 11.7 us, 3.6 sy, 0.0 ni, 83.8 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st MiB Mem : 3937.914 total, 509.301 free, 2035.738 used, 1392.875 buff/cache MiB Swap: 3082.750 total, 3082.750 free, 0.000 used. 1410.402 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23010 root 20 0 1651212 1.515g 3764 R 93.0 39.4 1594:12 bgpd 1050 root 20 0 409292 347104 3676 R 36.2 8.6 48720:02 zebra 7 root 20 0 0 0 0 S 0.3 0.0 866:46.42 rcu_sch There's only 15 peers mostly internal (one transit link). I am using both Ipv4 and IPv6 I am happy to share the bgp config as needed - biut there's nothing obvious I can see ... And the log is not showing any substantial entries Is there something I am missing / or would give a hint on what is causing this high load / and how to resolve it ? Thanks Richard

2 1

FRR 3.0 Released
by Martin Winter 16 Oct '17

16 Oct '17

FRRouting 3.0 is released! Git: https://github.com/FRRouting/frr/tree/stable/3.0 (Some) Binary Package Downloads: https://github.com/FRRouting/frr/releases/tag/frr-3.0 3.0 Changes (since version 2.0): https://github.com/FRRouting/frr/wiki/FRR-2.0-%E2%86%92-FRR-3.0-Changelog Snap packages are online in the Ubuntu Store as well (amd64, i386, armhf, arm64, ppc64el architectures). Enjoy! - Martin Winter

1 0

nexthop_set failed
by Xinwei Hong 07 Oct '17

07 Oct '17

Hi I have a two bgp router setting between 192.168.3.2 and 192.168.3.3. On 192.168.3.2, I have to following config. similar config as on 192.168.3.3 ----bgpd.conf ! -*- bgp -*- ! hostname bgpd password zebra ! router bgp 7632 neighbor 192.168.3.3 remote-as 7633 bgp router-id 192.168.3.2 network 10.200.0.0/16 ! address-family ipv4 unicast network 10.201.142.0/24 neighbor 192.168.3.3 activate neighbor 192.168.3.3 next-hop-self exit-address-family ! access-list all permit any ! route-map set-nexthop permit 10 match ip address all set ip next-hop 192.168.3.3 ! log file /var/log/frr/bgpd.log log stdout log syslog ------------------ In log, I find the following errors. 2017/10/03 23:29:40 BGP: 192.168.3.3: nexthop_set failed, resetting connection - intf (nil) 2017/10/03 23:29:40 BGP: bgp_connect_success: bgp_getsockname(): failed for peer 192.168.3.3, fd 9 2017/10/03 23:29:40 BGP: 192.168.3.3 [FSM] Failure handling event TCP_connection_open in state Connect, prior events BGP_Start, BGP_Start, fd 9 Is there anything wrong with my config? Thanks, Xinwei

2 7

nexthop_set failed
by Xinwei Hong 04 Oct '17

04 Oct '17

Hi I have a two bgp router setting between 192.168.3.2 and 192.168.3.3. On 192.168.3.2, I have to following config. similar config as on 192.168.3.3 ----bgpd.conf ! -*- bgp -*- ! hostname bgpd password zebra ! router bgp 7632 neighbor 192.168.3.3 remote-as 7633 bgp router-id 192.168.3.2 network 10.200.0.0/16 ! address-family ipv4 unicast network 10.201.142.0/24 neighbor 192.168.3.3 activate neighbor 192.168.3.3 next-hop-self exit-address-family ! access-list all permit any ! route-map set-nexthop permit 10 match ip address all set ip next-hop 192.168.3.3 ! log file /var/log/frr/bgpd.log log stdout log syslog ------------------ In log, I find the following errors. 2017/10/03 23:29:40 BGP: 192.168.3.3: nexthop_set failed, resetting connection - intf (nil) 2017/10/03 23:29:40 BGP: bgp_connect_success: bgp_getsockname(): failed for peer 192.168.3.3, fd 9 2017/10/03 23:29:40 BGP: 192.168.3.3 [FSM] Failure handling event TCP_connection_open in state Connect, prior events BGP_Start, BGP_Start, fd 9 Is there anything wrong with my config? Thanks, Xinwei

1 0

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