RE: BGP attribute ext-next-hop
Hi , Thanks for your response. Could you help me for another question. If ext-next-hop is enabled and AFI is BGP_AF_IPV4, next- hop is a IPV4 address, when update message created, the function bgp_create_mp_reach is called, what is the format of UPDATE message ? Firstly, bgp_encode_attrs function encode all attributes, is the attribute BA_NEXT_HOP encoded in this step ? If yes, as comment said, IPV4 NLRI is not used; If no, bgp_encode_next_hop assert next-hop is 16 bytes or 32 bytes, but IPV4 next-hop is 4 bytes Thanks Arvin -Original Message- From: Ondrej Zajicek Sent: Tuesday, April 03, 2018 10:14 PM To: Arvin Gan Cc: bird-users@network.cz Subject: Re: BGP attribute ext-next-hop On Tue, Apr 03, 2018 at 09:42:18AM +, Arvin Gan wrote: > Hi all, > > The version of my bird is 2.0.0, I found the source code of bird can > support the attribute ext_next_hop for BGP, and this attribute is also parsed > in cf-parse.y, but cannot found in user's guide document. > Does anyone know what configuration is coherent with the attribute > ext_next_hop? Is the attribute ext_next_hop fully supported in version > 2.0.0 ? Hi 'extended next hop' is a BGP channel option, is fully supported in version 2.0.2 (and likely also in 2.0.0 but i think there were some bugfixes in this). Unfortunately we forgot to document it. Will fix that. See doc/bird.conf.example2, where it is used (but commented out). The option allows to use IPv4 next hop with IPv6 routes and vice versa. For IPv4 channels, it requires that the peer announces the support by the capability (RFC 5549). For IPv6 channels there is no relevant capability. It can be used with all BGP channels with the exception of flowspec ones, which do not have next hops anyways). It is disabled by default, but perhaps we should change it to be enabled by default for MPLS/VPNv6 channel (not sure what are expectations here). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 07:55:28AM +, Arvin Gan wrote: > Hi , > Thanks for your response. Could you help me for another question. > If ext-next-hop is enabled and AFI is BGP_AF_IPV4, next- hop is a IPV4 > address, when update message created, the function bgp_create_mp_reach is > called, what is the format of UPDATE message ? Firstly, bgp_encode_attrs > function encode all attributes, is the attribute BA_NEXT_HOP encoded in > this step ? Hi In traditional BGP (encoded by bgp_create_ip_reach() function), NEXT_HOP is encoded like other attributes by bgp_encode_next_hop() function from attrs.c file as part of bgp_encode_attrs(). In MP-BGP (encoded by bgp_create_mp_reach() function), NEXT_HOP attribute should not be encoded independently as part of bgp_encode_attrs(), but is encoded by bgp_encode_next_hop_ip() function (or its variant based on SAFI), called through dispatch function directly from bgp_create_mp_reach()). But now when i checked it, it seem like the condition in bgp_encode_next_hop() does not take in to account ext-next-hop option. So it is possible there is a bug here. > If yes, as comment said, IPV4 NLRI is not used; If no, > bgp_encode_next_hop assert next-hop is 16 bytes or 32 bytes, but IPV4 > next-hop is 4 bytes The assert in bgp_encode_next_hop_ip() function checks the length of the internal representation of the next hop, which is always 16 bytes (type ip_addr), even if IPv4 next hop is used (in such case it is encoded as IPv4-mapped IPv6 address). Function ipa_to_ip4() gets 4B ip4_addr from 16B ip_addr. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
RE: BGP attribute ext-next-hop
Hi , Thanks for so quick reply. Do you mean if (s->channel->afi == BGP_AF_IPV4) maybe have bug, need change to if (s->channel->afi == BGP_AF_IPV4 && !s->channel-> ext_next_hop) ? Thanks Arvin -Original Message- From: Ondrej Zajicek Sent: Wednesday, April 11, 2018 5:26 PM To: Arvin Gan Cc: bird-users@network.cz Subject: Re: BGP attribute ext-next-hop On Wed, Apr 11, 2018 at 07:55:28AM +, Arvin Gan wrote: > Hi , > Thanks for your response. Could you help me for another question. > If ext-next-hop is enabled and AFI is BGP_AF_IPV4, next- hop is a IPV4 > address, when update message created, the function bgp_create_mp_reach > is called, what is the format of UPDATE message ? Firstly, > bgp_encode_attrs function encode all attributes, is the attribute > BA_NEXT_HOP encoded in this step ? Hi In traditional BGP (encoded by bgp_create_ip_reach() function), NEXT_HOP is encoded like other attributes by bgp_encode_next_hop() function from attrs.c file as part of bgp_encode_attrs(). In MP-BGP (encoded by bgp_create_mp_reach() function), NEXT_HOP attribute should not be encoded independently as part of bgp_encode_attrs(), but is encoded by bgp_encode_next_hop_ip() function (or its variant based on SAFI), called through dispatch function directly from bgp_create_mp_reach()). But now when i checked it, it seem like the condition in bgp_encode_next_hop() does not take in to account ext-next-hop option. So it is possible there is a bug here. > If yes, as comment said, IPV4 NLRI is not used; If no, > bgp_encode_next_hop assert next-hop is 16 bytes or 32 bytes, but IPV4 > next-hop is 4 bytes The assert in bgp_encode_next_hop_ip() function checks the length of the internal representation of the next hop, which is always 16 bytes (type ip_addr), even if IPv4 next hop is used (in such case it is encoded as IPv4-mapped IPv6 address). Function ipa_to_ip4() gets 4B ip4_addr from 16B ip_addr. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
RE: BGP attribute ext-next-hop
Hi, I found the traditional BGP and MP-BGP are independent in bird, if use MP_REACH_NLRI, IPV4 NLRI are not used. Has any case that need to support traditional BGP and MP-BGP at the same time ? That mean have a configuration option that create UPDATE message with MP-BGP and traditional BGP, transmit IPV4 route and IPV6 route in one UPDATE message. Thanks Arvin -Original Message- From: Ondrej Zajicek Sent: Wednesday, April 11, 2018 5:26 PM To: Arvin Gan Cc: bird-users@network.cz Subject: Re: BGP attribute ext-next-hop On Wed, Apr 11, 2018 at 07:55:28AM +, Arvin Gan wrote: > Hi , > Thanks for your response. Could you help me for another question. > If ext-next-hop is enabled and AFI is BGP_AF_IPV4, next- hop is a IPV4 > address, when update message created, the function bgp_create_mp_reach > is called, what is the format of UPDATE message ? Firstly, > bgp_encode_attrs function encode all attributes, is the attribute > BA_NEXT_HOP encoded in this step ? Hi In traditional BGP (encoded by bgp_create_ip_reach() function), NEXT_HOP is encoded like other attributes by bgp_encode_next_hop() function from attrs.c file as part of bgp_encode_attrs(). In MP-BGP (encoded by bgp_create_mp_reach() function), NEXT_HOP attribute should not be encoded independently as part of bgp_encode_attrs(), but is encoded by bgp_encode_next_hop_ip() function (or its variant based on SAFI), called through dispatch function directly from bgp_create_mp_reach()). But now when i checked it, it seem like the condition in bgp_encode_next_hop() does not take in to account ext-next-hop option. So it is possible there is a bug here. > If yes, as comment said, IPV4 NLRI is not used; If no, > bgp_encode_next_hop assert next-hop is 16 bytes or 32 bytes, but IPV4 > next-hop is 4 bytes The assert in bgp_encode_next_hop_ip() function checks the length of the internal representation of the next hop, which is always 16 bytes (type ip_addr), even if IPv4 next hop is used (in such case it is encoded as IPv4-mapped IPv6 address). Function ipa_to_ip4() gets 4B ip4_addr from 16B ip_addr. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 09:57:44AM +, Arvin Gan wrote: > Hi , >Thanks for so quick reply. Do you mean if (s->channel->afi == BGP_AF_IPV4) > maybe have bug, need change to if (s->channel->afi == BGP_AF_IPV4 && > !s->channel-> ext_next_hop) ? Yes, likely. I will check that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Re: BGP attribute ext-next-hop
On Wed, Apr 11, 2018 at 10:41:25AM +, Arvin Gan wrote: > Hi, > > I found the traditional BGP and MP-BGP are independent in bird, > if use MP_REACH_NLRI, IPV4 NLRI are not used. Has any case that need to > support traditional BGP and MP-BGP at the same time ? That mean have a > configuration option that create UPDATE message with MP-BGP and > traditional BGP, transmit IPV4 route and IPV6 route in one UPDATE > message. Hi Mixing traditional BGP and MP-BGP in one UPDATE is forbidden by RFC 7606, section 5.1. Of course, if you have BGP session with both IPv4 and IPv6, then both traditional BGP and MP-BGP can be used in one session, but not in one UPDATE. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
BGP import route
Hello, I'm not able to import route from BGP (CentOS 7). In log file I read "Got UPDATE" but "import updates" is always 0. With TCPDUMP I see that BGP receive the routes Rr # more bird.conf log syslog all; log stderr all; log "/var/log/bird.logg" all; debug protocols all; protocol kernel { persist;# Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds } protocol device { scan time 10; # Scan interfaces every 10 seconds } router id 192.168.200.6; protocol bgp bgp1 { local as 64521; neighbor 192.168.200.1 as 64520; import filter all; } # tail -f /var/log/bird.logg 2018-04-11 17:46:53 kernel1 < interface lo goes up 2018-04-11 17:46:53 kernel1 < interface eth0 goes up 2018-04-11 17:46:53 kernel1 < interface eth1 goes up 2018-04-11 17:46:53 kernel1: State changed to up 2018-04-11 17:46:53 bgp1: Started 2018-04-11 17:46:53 bgp1: Connect delayed by 5 seconds 2018-04-11 17:46:53 kernel1: Scanning routing table 2018-04-11 17:46:53 kernel1: 0.0.0.0/0: [alien] ignored 2018-04-11 17:46:53 kernel1: 192.168.44.0/24: [alien] ignored 2018-04-11 17:46:53 kernel1: Pruning table master 2018-04-11 17:46:57 bgp1: Connecting to 192.168.200.1 from local address 192.168.200.6 2018-04-11 17:46:57 bgp1: Connected 2018-04-11 17:46:57 bgp1: Sending OPEN(ver=4,as=64521,hold=240,id=c0a8c806) 2018-04-11 17:46:57 bgp1: Connection closed 2018-04-11 17:46:57 bgp1: Connect delayed by 5 seconds 2018-04-11 17:47:03 device1: Scanning interfaces 2018-04-11 17:47:03 bgp1: Connecting to 192.168.200.1 from local address 192.168.200.6 2018-04-11 17:47:03 bgp1: Connected 2018-04-11 17:47:03 bgp1: Sending OPEN(ver=4,as=64521,hold=240,id=c0a8c806) 2018-04-11 17:47:03 bgp1: Got OPEN(as=64520,hold=90,id=a3a2e686) 2018-04-11 17:47:03 bgp1: Sending KEEPALIVE 2018-04-11 17:47:03 bgp1: Got KEEPALIVE 2018-04-11 17:47:03 bgp1: BGP session established 2018-04-11 17:47:03 bgp1: Connected to table master 2018-04-11 17:47:03 bgp1: State changed to feed 2018-04-11 17:47:03 bgp1: State changed to up 2018-04-11 17:47:03 bgp1: Sending End-of-RIB 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 ... # birdc show protocols all bgp1 BIRD 1.4.5 ready. name prototablestate since info bgp1 BGP master up 17:47:03Established Preference: 100 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filteredignored accepted Import updates: 0 0 0 0 0 Import withdraws:0 0--- 0 0 Export updates: 0 0 0--- 0 Export withdraws:0--------- 0 BGP state: Established Neighbor address: 192.168.200.1 Neighbor AS: 64520 Neighbor ID: 163.162.230.134 Neighbor caps:restart-aware Session: external Source address: 192.168.200.6 Hold timer: 62/90 Keepalive timer: 22/30 # tcpdump -i eth1 tcp port 179 -vvv -XX 17:37:51.260061 IP (tos 0x0, ttl 1, id 49246, offset 0, flags [DF], proto TCP (6), length 1353) 192.168.200.1.bgp > vm-1.59873: Flags [P.], cksum 0xad25 (correct), seq 61:1362, ack 69, win 210, options [nop,nop,TS val 1643220008 ecr 25496328], length 1301: BGP Update Message (2), length: 66 Origin (1), length: 1, Flags [T]: Incomplete 0x: 02 Next Hop (3), length: 4, Flags [T]: 192.168.200.1 0x: c0a8 c801 Multi Exit Discriminator (4), length: 4, Flags [O]: 100 0x: 0064 AS Path (2), length: 4, Flags [T]: 64520 0x: 0201 fc08 Multi-Protocol Reach NLRI (14), length: 14, Flags [OE]: AFI: IPv4 (1), SAFI: Unicast (1) nexthop: 192.168.200.1, nh-length: 4, no SNPA 163.162.230.199/32 0x: 0001 0104 c0a8 c801 0020 a3a2 e6c7
RPKI / roa_check() question - BIRD 2.0.2
Hello, I have found this while doing RPKI validation: net = 94.127.104.0/21 bgp_path = 48112 6830 174 13110 {30884 65004 65005} BGP.aggregator: 10.253.27.1 AS13110 (don't know how to read this from a var) roa_check(rpki4, net, bgp_path.last) returns ROA_INVALID because BIRD thinks bgp_path.last = 0 There is a valid ROA for 94.127.104.0/21 and AS13110, so I guess the validation should be done on the aggregator AS. Could you tell me what is the corect way to handle this? TIA, Radu
Re: RPKI / roa_check() question - BIRD 2.0.2
The bgp_path.last_nonaggregated attribute should help you. Don't have user manual right now here, writing from my phone, just trying to recall it from my memory. Maria Quidquid latine dictum sit, altum videtur. -Original Message- From: Radu Anghel To: bird-users@network.cz Sent: Wed, 11 Apr 2018 6:34 PM Subject: RPKI / roa_check() question - BIRD 2.0.2 Hello, I have found this while doing RPKI validation: net = 94.127.104.0/21 bgp_path = 48112 6830 174 13110 {30884 65004 65005} BGP.aggregator: 10.253.27.1 AS13110 (don't know how to read this from a var) roa_check(rpki4, net, bgp_path.last) returns ROA_INVALID because BIRD thinks bgp_path.last = 0 There is a valid ROA for 94.127.104.0/21 and AS13110, so I guess the validation should be done on the aggregator AS. Could you tell me what is the corect way to handle this? TIA, Radu
Re: BGP import route
Hello! First of all, we don't support this old version. Please upgrade, either to 1.6.4 or to 2.0.2. Second, the other side seems to send multiprotocol NLRI to you. BIRD in 1.x versions AFAIK does not support this extension and should not announce it. What is the remote software? Writing from my phone with no access to source code, trying to recall it from my memory. I might be wrong. Maria Quidquid latine dictum sit, altum videtur. -Original Message- From: RICCARDO RUSSO To: bird-users@network.cz Sent: Wed, 11 Apr 2018 6:10 PM Subject: BGP import route Hello, I'm not able to import route from BGP (CentOS 7). In log file I read "Got UPDATE" but "import updates" is always 0. With TCPDUMP I see that BGP receive the routes Rr # more bird.conf log syslog all; log stderr all; log "/var/log/bird.logg" all; debug protocols all; protocol kernel { persist;# Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds } protocol device { scan time 10; # Scan interfaces every 10 seconds } router id 192.168.200.6; protocol bgp bgp1 { local as 64521; neighbor 192.168.200.1 as 64520; import filter all; } # tail -f /var/log/bird.logg 2018-04-11 17:46:53 kernel1 < interface lo goes up 2018-04-11 17:46:53 kernel1 < interface eth0 goes up 2018-04-11 17:46:53 kernel1 < interface eth1 goes up 2018-04-11 17:46:53 kernel1: State changed to up 2018-04-11 17:46:53 bgp1: Started 2018-04-11 17:46:53 bgp1: Connect delayed by 5 seconds 2018-04-11 17:46:53 kernel1: Scanning routing table 2018-04-11 17:46:53 kernel1: 0.0.0.0/0: [alien] ignored 2018-04-11 17:46:53 kernel1: 192.168.44.0/24: [alien] ignored 2018-04-11 17:46:53 kernel1: Pruning table master 2018-04-11 17:46:57 bgp1: Connecting to 192.168.200.1 from local address 192.168.200.6 2018-04-11 17:46:57 bgp1: Connected 2018-04-11 17:46:57 bgp1: Sending OPEN(ver=4,as=64521,hold=240,id=c0a8c806) 2018-04-11 17:46:57 bgp1: Connection closed 2018-04-11 17:46:57 bgp1: Connect delayed by 5 seconds 2018-04-11 17:47:03 device1: Scanning interfaces 2018-04-11 17:47:03 bgp1: Connecting to 192.168.200.1 from local address 192.168.200.6 2018-04-11 17:47:03 bgp1: Connected 2018-04-11 17:47:03 bgp1: Sending OPEN(ver=4,as=64521,hold=240,id=c0a8c806) 2018-04-11 17:47:03 bgp1: Got OPEN(as=64520,hold=90,id=a3a2e686) 2018-04-11 17:47:03 bgp1: Sending KEEPALIVE 2018-04-11 17:47:03 bgp1: Got KEEPALIVE 2018-04-11 17:47:03 bgp1: BGP session established 2018-04-11 17:47:03 bgp1: Connected to table master 2018-04-11 17:47:03 bgp1: State changed to feed 2018-04-11 17:47:03 bgp1: State changed to up 2018-04-11 17:47:03 bgp1: Sending End-of-RIB 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 bgp1: Got UPDATE 2018-04-11 17:47:03 ... # birdc show protocols all bgp1 BIRD 1.4.5 ready. name prototablestate since info bgp1 BGP master up 17:47:03Established Preference: 100 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filteredignored accepted Import updates: 0 0 0 0 0 Import withdraws:0 0--- 0 0 Export updates: 0 0 0--- 0 Export withdraws:0--------- 0 BGP state: Established Neighbor address: 192.168.200.1 Neighbor AS: 64520 Neighbor ID: 163.162.230.134 Neighbor caps:restart-aware Session: external Source address: 192.168.200.6 Hold timer: 62/90 Keepalive timer: 22/30 # tcpdump -i eth1 tcp port 179 -vvv -XX 17:37:51.260061 IP (tos 0x0, ttl 1, id 49246, offset 0, flags [DF], proto TCP (6), length 1353) 192.168.200.1.bgp > vm-1.59873: Flags [P.], cksum 0xad25 (correct), seq 61:1362, ack 69, win 210, options [nop,nop,TS val 1643220008 ecr 25496328], length 1301: BGP Update Message (2), length: 66 Origin (1), length: 1, Flags [T]: Incomplete 0x: 02 Next Hop (3), length: 4, Flags [T]: 192.168.200.1 0x: c0a8 c801 Multi Exit Discriminator (4), length: 4, Flags [O]: 100 0x: 0064 AS Path (2), length:
Re: RPKI / roa_check() question - BIRD 2.0.2
Thank you, it works with last_nonaggregated, I don't know how I didn't notice that in the doc. Radu On 11.04.2018 20:06, Matthias Waehlisch wrote: > Hi Radu, > > the path includes an AS-set ({30884 65004 65005}). > > "Both first and last return zero if there is no appropriate ASN, for > example if the path contains an AS set element as the first (or the > last) part. If the path ends with an AS set, last_nonaggregated may be > used to get last ASN before any AS set. " > > AS-sets are deprecated: https://tools.ietf.org/html/rfc6472 > > Strictly speaking, you you don't know which AS in AS-set is the actual > origin. > > > > Cheers > matthias > > > On Wed, 11 Apr 2018, Radu Anghel wrote: > >> Hello, >> >> I have found this while doing RPKI validation: >> >> net = 94.127.104.0/21 >> bgp_path = 48112 6830 174 13110 {30884 65004 65005} >> BGP.aggregator: 10.253.27.1 AS13110 (don't know how to read this from a var) >> >> roa_check(rpki4, net, bgp_path.last) returns ROA_INVALID because BIRD >> thinks bgp_path.last = 0 >> >> There is a valid ROA for 94.127.104.0/21 and AS13110, so I guess the >> validation should be done on the aggregator AS. >> >> Could you tell me what is the corect way to handle this? >> >> TIA, >> Radu >> > >
Re: BGP import route
Ok. I have installed bird via epel on Centos The router sending BGP announcement is Juniper Open Contrail Virtual Router (on Openstack). I downloaded and installed the 2.0.2 and used this config: - # more /usr/local/etc/bird.conf log syslog all; log stderr all; log "/var/log/bird.logg" all; debug protocols all; protocol kernel { ipv4 { import all; export all; }; persist; scan time 20; } protocol device { scan time 10; # Scan interfaces every 10 seconds } router id 192.168.200.6; protocol bgp bgp1 { local as 64521; neighbor 192.168.200.1 as 64520; ipv4 { import all; export all; }; } - And finally I see all routes: - [root@vm-1 bird-2.0.2]# birdc show route BIRD 2.0.2 ready. Table master4: 163.162.35.131/32unicast [bgp1 20:48:36.342] * (100) [AS64520?] via 192.168.200.1 on eth1 163.162.35.80/32 unicast [bgp1 20:48:36.342] * (100) [AS3269i] via 192.168.200.1 on eth1 100.64.3.28/32 unicast [bgp1 20:48:36.342] * (100) [AS64520?] via 192.168.200.1 on eth1 ... - Rr 2018-04-11 19:21 GMT+02:00 Jan Maria Matějka : > Hello! > > First of all, we don't support this old version. Please upgrade, either to > 1.6.4 or to 2.0.2. > > Second, the other side seems to send multiprotocol NLRI to you. BIRD in > 1.x versions AFAIK does not support this extension and should not announce > it. What is the remote software? > > Writing from my phone with no access to source code, trying to recall it > from my memory. I might be wrong. > > Maria > > Quidquid latine dictum sit, altum videtur. > > -Original Message- > From: RICCARDO RUSSO > To: bird-users@network.cz > Sent: Wed, 11 Apr 2018 6:10 PM > Subject: BGP import route > > Hello, > I'm not able to import route from BGP (CentOS 7). In log file I read "Got > UPDATE" but "import updates" is always 0. With TCPDUMP I see that BGP > receive the routes > > Rr > > > # more bird.conf > log syslog all; > log stderr all; > log "/var/log/bird.logg" all; > debug protocols all; > > protocol kernel { > persist;# Don't remove routes on bird shutdown > scan time 20; # Scan kernel routing table every 20 > seconds > } > > protocol device { > scan time 10; # Scan interfaces every 10 seconds > } > > router id 192.168.200.6; > > protocol bgp bgp1 { >local as 64521; >neighbor 192.168.200.1 as 64520; >import filter all; > } > > > > > > # tail -f /var/log/bird.logg > 2018-04-11 17:46:53 kernel1 < interface lo goes up > 2018-04-11 17:46:53 kernel1 < interface eth0 goes up > 2018-04-11 17:46:53 kernel1 < interface eth1 goes up > 2018-04-11 17:46:53 kernel1: State changed to up > 2018-04-11 17:46:53 bgp1: Started > 2018-04-11 17:46:53 bgp1: Connect delayed by 5 seconds > 2018-04-11 17:46:53 kernel1: Scanning routing table > 2018-04-11 17:46:53 kernel1: 0.0.0.0/0: [alien] ignored > 2018-04-11 17:46:53 kernel1: 192.168.44.0/24: [alien] ignored > 2018-04-11 17:46:53 kernel1: Pruning table master > 2018-04-11 17:46:57 bgp1: Connecting to 192.168.200.1 from local > address 192.168.200.6 > 2018-04-11 17:46:57 bgp1: Connected > 2018-04-11 17:46:57 bgp1: Sending > OPEN(ver=4,as=64521,hold=240,id=c0a8c806) > 2018-04-11 17:46:57 bgp1: Connection closed > 2018-04-11 17:46:57 bgp1: Connect delayed by 5 seconds > 2018-04-11 17:47:03 device1: Scanning interfaces > 2018-04-11 17:47:03 bgp1: Connecting to 192.168.200.1 from local > address 192.168.200.6 > 2018-04-11 17:47:03 bgp1: Connected > 2018-04-11 17:47:03 bgp1: Sending > OPEN(ver=4,as=64521,hold=240,id=c0a8c806) > 2018-04-11 17:47:03 bgp1: Got OPEN(as=64520,hold=90,id=a3a2e686) > 2018-04-11 17:47:03 bgp1: Sending KEEPALIVE > 2018-04-11 17:47:03 bgp1: Got KEEPALIVE > 2018-04-11 17:47:03 bgp1: BGP session established > 2018-04-11 17:47:03 bgp1: Connected to table master > 2018-04-11 17:47:03 bgp1: State changed to feed > 2018-04-11 17:47:03 bgp1: State changed to up > 2018-04-11 17:47:03 bgp1: Sending End-of-RIB > 2018-04-11 17:47:03 bgp1: Got UPDATE > 2018-04-11 17:47:03 bgp1: Got UPDATE > 2018-04-11 17:47:03 bgp1: Got UPDATE > 2018-04-11 17:47:03 bgp1: Got UPDATE > 2018-04-11 17:47:03 bgp1: Got UPDATE > 2018-04-11 17:47:03 ... > > > > > >
Am I missing the announcements for New releases or ???
Hello All , Am I missing the announcements for New releases or are they ONLY on the webpage ? I really use email except for general reasearch and was hoping that the announcements of new releases would be announced here . Hope I am missing something obvious . Tia , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +--+
Re: Am I missing the announcements for New releases or ???
On 12.4.2018 00:23, James W. Laferriere wrote: Hi! All releases are announced in this mailing list as well. Ondrej > Hello All , Am I missing the announcements for New releases or > are they ONLY on the webpage ? I really use email except for general > reasearch and was hoping that the announcements of new releases would > be announced here . > Hope I am missing something obvious . > > Tia , JimL
Re: Am I missing the announcements for New releases or ???
On 2018/04/11 14:23, James W. Laferriere wrote: > Hello All , Am I missing the announcements for New releases or are they > ONLY on the webpage ? I really use email except for general reasearch and > was hoping that the announcements of new releases would be announced here . > Hope I am missing something obvious . They were sent here too, - Forwarded message from Ondrej Filip - From: Ondrej Filip Date: Thu, 22 Mar 2018 13:36:55 +0100 To: bird User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Subject: BIRD 2.0.2 and 1.6.4 Dear BIRD users, we just released two new versions - 1.6.4 and 2.0.2. There is an important security bugfix in both. Upgrade is highly recommended. Version 2.0.2 (2018-03-22) o Source-specific routing support for Linux kernel and Babel o BGP: New option 'disable after cease' o Filter: Allow silent filter execution o Filter: Fixed stack overflow in BGP mask expressions. o Several bugfixes Notes: Syntax prefix:netmask for IPv4 prefixes was dropped. Just use prefix/pxlen. Version 1.6.4 (2018-03-22) o Basic VRF support o Simplified autoconf scripts o BGP: Shutdown communication (RFC 8203) o BGP: Allow exchanging LOCAL_PREF with eBGP peers o BGP: Allow to specify interface for regular sessions o BGP: New option 'disable after cease' o RAdv: Support for more specific routes (RFC 4191) o RAdv: Proper handling of prefix retraction o Filter: Allow silent filter execution o Filter: Fixed stack overflow in BGP mask expressions. o Several bug fixes Ondrej - End forwarded message -