- frog - lists.frrouting.org

Tunnel Encap attribute sub-tlv length 48582, exceeds remaining length 28
by Mike Tancsa 07 Jan '19

07 Jan '19

A couple of my peers started flapping for some reason this morning with the error messages Jan 7 09:48:39 bgpd[19828]: Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28 Jan 7 09:48:39 bgpd[19828]: %NOTIFICATION: sent to neighbor xx.yy.zz.205 3/9 (UPDATE Message Error/Optional Attribute Error) 35 bytes e0 ff 20 ac d9 bd c6 ec 73 13 8f f0 6d ed c7 52 11 5a 91 3c 0e 8b 8c 1e be aa f2 72 d5 83 92 83 5e 5b 57 Jan 7 09:48:39 bgpd[19828]: xx.yy.zz.205: Attribute VNC, parse error Jan 7 09:48:39 bgpd[19828]: %ADJCHANGE: neighbor xx.yy.zz.205(Unknown) in vrf Default Down BGP Notification send I was running frr 3.0.3 on FreeBSD RELENG11. Any idea what this bug is or problematic advertisement ? I started a pcap of the bgp sessions, but havent found anything obvious yet -- ------------------- 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

3 2

Question regarding IETF draft "Well-Known Community Policy Behavior"
by Christoffer Hansen 07 Jan '19

07 Jan '19

@FROG, <<Disclaimer: maybe this question if best answered by the devs...(?)>> Was reading the IETF draft "Well-Known Community Policy Behavior" [0]. And was wondering if FRR does any special treatment for well-known communities?* Maybe the behaviour of FRR could be included in future revisions of the draft[0] ? *) thinking if FRR does similair behaviour to ios-xr (partial special treament), or junos (no special treatment). (refer to section 4 [0]) [0]: https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ -- Cheers Christoffer

1 0

Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28
by Mike Tancsa 07 Jan '19

07 Jan '19

A couple of my peers started flapping for some reason this morning with the error messages Jan 7 09:48:39 bgpd[19828]: Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28 Jan 7 09:48:39 bgpd[19828]: %NOTIFICATION: sent to neighbor xx.yy.zz.205 3/9 (UPDATE Message Error/Optional Attribute Error) 35 bytes e0 ff 20 ac d9 bd c6 ec 73 13 8f f0 6d ed c7 52 11 5a 91 3c 0e 8b 8c 1e be aa f2 72 d5 83 92 83 5e 5b 57 Jan 7 09:48:39 bgpd[19828]: xx.yy.zz.205: Attribute VNC, parse error Jan 7 09:48:39 bgpd[19828]: %ADJCHANGE: neighbor xx.yy.zz.205(Unknown) in vrf Default Down BGP Notification send I was running frr 3.0.3 on FreeBSD RELENG11. Any idea what this bug is or problematic advertisement ? I started a pcap of the bgp sessions, but havent found anything obvious yet -- ------------------- 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

Tunnel Encap attribute sub-tlv length
by Abel Alejandro 07 Jan '19

07 Jan '19

Hello, I have a eBGP with two transit providers and they both died with the same error, as follows: Jan 7 10:51:59 serveru-1 bgpd[1776]: Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28 Jan 7 10:51:59 serveru-1 bgpd[1776]: <IP>: Attribute VNC, parse error Jan 7 10:51:59 serveru-1 bgpd[1776]: bgp_process_packet: BGP UPDATE receipt failed for peer: <IP> It seems both providers sent something frr didnt like, is there a way to avoid a shutdown on this case? serveru-1# show ver FRRouting 6.0 (serveru-1). 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' '--disable-snmp' '--enable-ospfapi=yes' '--enable-multipath=256' '--enable-ldpd' '--enable-fpm' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-werror' '--with-libpam' '--enable-systemd=yes' '--enable-poll=yes' '--enable-cumulus=no' '--enable-pimd' '--enable-dependency-tracking' '--enable-bgp-vnc=yes' '--disable-rpki' '--enable-bfdd' 'CFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong -Wformat -Werror=format-security' 'FCFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong' 'FFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong' 'GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong -Wformat -Werror=format-security' 'OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/ci/cibuild.6/debwork/frr-6.0=. -fstack-protector-strong -Wformat -Werror=format-security' 'build_alias=x86_64-linux-gnu' serveru-1#

1 0

BGP Updates -- how often?
by John Antypas 04 Jan '19

04 Jan '19

OK - thanks to this list, I've made some progress, but.... * We've set up a VTI tunnel between the two PFSense boxes -- it works * We have BGP enabled and when both ends are started up, the BGP routes are exchanged and then given to each side's OSPF * Everything works, routing-wise -- things enter the kernel BUT.... * After a while, it seems the receiving side loses the BGP routes -- if A publishes routes to B, B will lose the BGP routes. I have to start both BGP processes again. The processes were running before but I need to get the routes "re-published" * Static routes never go away - they are published all of the time Clearly, I am setting up something wrong. OSPF does a flood every 10 seconds. How often does BGP do its "updates"

2 1

Question
by o1bigtenor 03 Jan '19

03 Jan '19

Greetings I cannot find the question in the 'frog' environment and the web isn't very useful so far - - - - so I'm going to those that live this networking stuff. Cheap routers seem to not work very well. Decent routers aren't cheap? What are the system requirements to use the 'frrouting' universe in the creating of a good quality but still home brew router? (Will something like a 64 bit Raspberry Pi work? How could I achieve 1000 MB network speeds on such a system? Likely more questions later.) If this is not an appropriate place to ask this - - - please do advise! Dee

5 11

Re: [FROG] FRR (5.0) on latest pfSense 2.4.4p1 doesn't insert BGP routes into the kernel
by Muenz, Michael 01 Jan '19

01 Jan '19

Am 01.01.2019 um 13:00 schrieb John Antypas: > Exactly what we had to do. We ended up creating a VTI interface. Once we have the direct interface BGP found direct next tops and was a lot happier > > Sent from my iPad > >> On Jan 1, 2019, at 12:15 AM, Muenz, Michael <m.muenz(a)spam-fetish.org> wrote: >> >>> Am 31.12.2018 um 15:38 schrieb John Antypas: >>> I had not done anything special with the ipsec tunnel, so it probably isn't., WE had assumed since traffic was passed, all was well. We were seeing the BGP updates. We could set up a GRE tunnel between the two sites or GIF (which one would you recommend?) We had thought of that because our first attempt was to use OSPF which didn't traverse the IPSEC link. >> The enc interface in FreeBSD is not a routed device so you have to create a tunnel interface (GRE preferred) or use route-based IPSEC. >> >> >> Michael >> >> FYI

1 0

Re: [FROG] FRR (5.0) on latest pfSense 2.4.4p1 doesn't insert BGP routes into the kernel
by Muenz, Michael 01 Jan '19

01 Jan '19

Am 31.12.2018 um 15:38 schrieb John Antypas: > I had not done anything special with the ipsec tunnel, so it probably > isn't., WE had assumed since traffic was passed, all was well. We > were seeing the BGP updates. We could set up a GRE tunnel between > the two sites or GIF (which one would you recommend?) We had thought > of that because our first attempt was to use OSPF which didn't > traverse the IPSEC link. The enc interface in FreeBSD is not a routed device so you have to create a tunnel interface (GRE preferred) or use route-based IPSEC. Michael

1 0

setup and configuration
by o1bigtenor 31 Dec '18

31 Dec '18

Greetings I'm looking way beyond anything I've ever done before with this so please - - - if its stupid - - - I need to know (just don't hit me too hard - - - grin!) FRRouting looks like a very complete environment (what do I know but its got lots of things to set anyway!). If I purchase something like a sbc set up with say 2 GB of RAM and a 15 GB SDD I'm not sure how I would set things up. Is there a recipe for the noob crowd for what to do? (I'm seeing lots of options for things to ssetup and parameters to set but no having any idea on what to do makes the process more than somewhat intimidating. I'm thinking something like a router set up so that there are vlans separating a couple wired networks, one wireless network and possible another mesh network. I am wanting to be quite tough re: my security and privacy so want to very much reduce crosstalk between the lans.) TIA Dee

2 1

FRR (5.0) on latest pfSense 2.4.4p1 doesn't insert BGP routes into the kernel
by John Antypas 31 Dec '18

31 Dec '18

The subject basically says it all..... I have two sites connected over an IPSEC tunnel. Each site has its own internal routes managed by OSPF, and I am trying to exchange them by BGP. * We know the traffic is being passed over the IPSEC tunnel, and we can see that each side does get the other's BGP routes. We did have to install directives to allow multihop and disable-connection-checks.... * We do not see the routes being installed into the local kernel routing tables but for the life us, we can't understand why. We see the routes come across in the BGP debug info, but it never makes it into the FIB. Here's our BGPD.conf albeit for one side -- the other just has the AS numbers changed. # BGP Config router bgp 3000000 bgp router-id 10.0.0.5 redistribute connected redistribute static redistribute kernel redistribute ospf # BGP Neighbors neighbor 192.168.101.39 remote-as 2510000 neighbor 192.168.101.39 description Aaron Martin neighbor 192.168.101.39 update-source 10.0.0.5 address-family ipv4 unicast neighbor 192.168.101.39 activate neighbor 192.168.101.39 disable-connected-checks no neighbor 192.168.101.39 send-community neighbor 192.168.101.39 addpath-tx-bestpath-per-AS neighbor 192.168.101.39 allowas-in exit-address-family And here's what we see BGP table version is 208559, local router ID is 10.0.0.5, vrf id 0 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 0.0.0.0 192.168.101.39 0 2510000 3000000 ? 192.168.101.39 0 0 2510000 ? *> 50.247.114.30 0 32768 ? 10.0.0.0 192.168.101.39 0 2510000 ? 10.0.0.0/16 192.168.101.39 0 2510000 3000000 ? *> 0.0.0.0 1 32768 ? 10.1.6.0/24 192.168.101.39 0 2510000 3000000 ? *> 0.0.0.0 1 32768 ? 10.10.10.1/32 192.168.101.39 1 0 2510000 ? 10.147.20.0/24 192.168.101.39 0 2510000 3000000 ? *> 10.0.1.5 110 32768 ? 50.247.114.16/28 192.168.101.39 0 2510000 3000000 ? *> 0.0.0.0 1 32768 ? 50.247.114.18/32 192.168.101.39 0 0 2510000 ? 64.62.134.130/32 192.168.101.39 0 2510000 3000000 ? *> 50.247.114.30 0 32768 ? 68.115.209.232/29 192.168.101.39 1 0 2510000 ? 68.115.209.237/32 192.168.101.39 0 2510000 3000000 ? *> 50.247.114.30 0 32768 ? 72.52.104.74/32 192.168.101.39 0 2510000 3000000 ? *> 50.247.114.30 0 32768 ? 172.16.0.0 192.168.101.39 0 2510000 ? 172.16.184.0/24 192.168.101.39 0 0 2510000 ? 172.16.231.0/24 192.168.101.39 1 0 2510000 ? 172.16.232.0/24 192.168.101.39 0 0 2510000 ? 172.16.238.0/24 192.168.101.39 1 0 2510000 ? 172.17.0.0 192.168.101.39 0 2510000 3000000 ? *> 10.0.1.5 110 32768 ? 172.21.0.0 192.168.101.39 0 2510000 ? 192.168.1.0 192.168.101.39 0 2510000 ? 192.168.101.39 0 0 2510000 ? 192.168.101.0 192.168.101.39 1 0 2510000 ? 192.168.101.39 0 2510000 ? 192.168.106.0 192.168.101.39 1 0 2510000 ? 192.168.101.39 0 2510000 ? 192.168.108.0 192.168.101.39 0 2510000 ? 192.168.121.0 192.168.101.39 0 2510000 ? 192.168.128.0 192.168.101.39 1 0 2510000 ? 192.168.101.39 0 2510000 ? 192.168.131.0 192.168.101.39 0 2510000 ? 192.168.132.0 192.168.101.39 0 2510000 ? 192.168.101.39 0 0 2510000 ? 192.168.148.0 192.168.101.39 1 0 2510000 ? 192.168.150.0 192.168.101.39 0 2510000 ? 192.168.228.0 192.168.101.39 0 2510000 3000000 ? *> 0.0.0.0 1 32768 ? 192.168.229.0 192.168.101.39 0 2510000 3000000 ? *> 0.0.0.0 1 32768 ? 196.101.2.0 192.168.101.39 0 2510000 ? 209.51.161.14/32 192.168.101.39 0 0 2510000 ? Displayed 33 routes and 50 total paths Everything's there, but it never makes it into the kernel. I'm sure we've done something wrong, because I tried a different BGP-based router at the other end, and I see the connection, but again, the routes don't seem to make it into the kernel -- clearly I've broken something basic :-)

4 4