April 2014 - Bird-users - Mailing Lists

IPv6 BGP debugging
by Peter Andreev 11 Apr '14

11 Apr '14

Hi everybody, I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following: bird> sh pro name proto table state since info kernel1 Kernel master up 13:10:06 device1 Device master up 13:10:06 NICbr1 BGP master up 13:10:28 Established NICbr2 BGP master up 13:10:29 Established PTTlg BGP master start 13:10:24 Connect Socket: Invalid argument MLPA1 BGP master start 13:10:24 Connect Socket: Operation timed out MLPA2 BGP master start 13:10:24 Connect Socket: Invalid argument MLPA3 BGP master start 13:12:51 OpenConfirm BGP Error: Hold timer expired MLPA4 BGP master start 13:10:24 Connect Socket: Invalid argument STATIC_BGP Static master up 13:10:06 All these BGP protocols are inherited from one template. The only difference is that those are established, use another source address which is configured on virtual interface. However my question is how to find out what's going on and how to detect a problem? Setting "log syslog all;" is not very helpful - it only fills the log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to kernel: No such process" messages. -- Is there any problem Exterminatus cannot solve? I have not found one yet.

4 12

bgp route selection
by Thomas Goldberg 10 Apr '14

10 Apr '14

Hello, can yomeone please explain me the following behaviour: There's one eBGP session (b_dtag1) and one iBGP session with one of our RR Servers (b_rr1). The RR redistributes the blackhole prefixes learned from the Spamhouse BGP Feed (BGPf). The prefix 64.112.128.0/18 is supposed to be blackholed. These are the two routes learned from the two peers: bird> show route all 64.112.128.0/18 64.112.128.0/18 via X.X.X.X on eth0 [b_dtag1 Apr06] * (100) [AS3320i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3320 3491 25847 46879 BGP.next_hop: X.X.X.X BGP.local_pref: 100 blackhole [b_rr1 15:36 from Y.Y.Y.Y] (100/-) [AS65535i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65190 BGP.next_hop: 192.168.2.11 BGP.med: 0 BGP.local_pref: 40000 BGP.community: (65190,1000) (65535,65281) As you can see the (older) regular eBGP route is picked over the blackhole route: Based on the Route selection rules from http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 I expected that the first (Prefer route with the highest Local Preference attribute) and the second (Prefer route with the shortest AS path) rule would result in the blackhole route being picked. Best Regards Thomas Goldberg

4 5

ipv6 ecmp ospf
by Vasiliy Tolstov 10 Apr '14

10 Apr '14

Hi all. I'm try to get working ecmp with ipv6 and bird 1.4. Now i'm not understand why routes to test ip installed and removed after 3-5 seconds. Can somebody helps me? In log i have : Apr 6 15:14:31 rl01 bird6: device1: Scanning interfaces Apr 6 15:14:31 rl01 bird6: kernel1: Scanning routing table Apr 6 15:14:31 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: will be updated Apr 6 15:14:31 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: already seen Apr 6 15:14:31 rl01 bird6: kernel1: Pruning table master Apr 6 15:14:31 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: updating Apr 6 15:14:31 rl01 bird6: Netlink: No such process Apr 6 15:14:31 rl01 bird6: kernel1: Pruning inherited routes Apr 6 15:14:32 rl01 bird6: radv1: Timer fired on eth1 Apr 6 15:14:32 rl01 bird6: radv1: Sending RA via eth1 Apr 6 15:14:32 rl01 bird6: radv1: Timer fired on eth0 Apr 6 15:14:32 rl01 bird6: radv1: Sending RA via eth0 Apr 6 15:14:32 rl01 bird6: ospf1: HELLO packet received from fe80::225:90ff:fe97:a719 via eth1 Apr 6 15:14:32 rl01 bird6: ospf1: HELLO packet received from fe80::225:90ff:fe97:a718 via eth0 Apr 6 15:14:37 rl01 bird6: device1: Scanning interfaces Apr 6 15:14:37 rl01 bird6: kernel1: Scanning routing table Apr 6 15:14:37 rl01 bird6: kernel1: Pruning table master Apr 6 15:14:37 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: reinstalling Apr 6 15:14:37 rl01 bird6: kernel1: Pruning inherited routes Apr 6 15:14:37 rl01 bird6: ospf1: HELLO packet sent via eth1 Apr 6 15:14:37 rl01 bird6: ospf1: HELLO packet sent via eth0 Apr 6 15:14:37 rl01 bird6: ospf1: HELLO packet received from fe80::225:90ff:fe97:a719 via eth1 Apr 6 15:14:37 rl01 bird6: ospf1: HELLO packet received from fe80::225:90ff:fe97:a718 via eth0 Apr 6 15:14:42 rl01 bird6: ospf1: HELLO packet sent via eth0 Apr 6 15:14:42 rl01 bird6: ospf1: HELLO packet sent via eth1 Apr 6 15:14:42 rl01 bird6: device1: Scanning interfaces Apr 6 15:14:42 rl01 bird6: kernel1: Scanning routing table Apr 6 15:14:42 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: will be updated Apr 6 15:14:42 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: already seen Apr 6 15:14:42 rl01 bird6: kernel1: Pruning table master Apr 6 15:14:42 rl01 bird6: kernel1: 2001:db8:0:f101:ccde:85ff:fe22:ec43/128: updating Apr 6 15:14:42 rl01 bird6: Netlink: No such process Apr 6 15:14:42 rl01 bird6: kernel1: Pruning inherited routes Apr 6 15:14:42 rl01 bird6: ospf1: HELLO packet received from fe80::225:90ff:fe97:a719 via eth1 Apr 6 15:14:42 rl01 bird6: ospf1: HELLO packet received from fe80::225:90ff:fe97:a718 via eth0 rl01 bird config: log syslog all; #{error, info}; router id 172.16.250.251; debug protocols all; protocol kernel { learn; scan time 5; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none } protocol direct { interface "eth0", "eth1", "dummy0"; export all; import all; } protocol device { scan time 5; # Scan interfaces every 10 seconds } protocol radv { interface "eth0" { max ra interval 30; link mtu 9000; prefix 2001:db8:0:f102::/64; }; interface "eth1" { max ra interval 30; link mtu 9000; prefix 2001:db8:0:f103::/64; }; } filter ospf_filter { if net ~ [ ::/0 ] then reject; else accept; } protocol ospf { tick 5; ecmp 4; import filter ospf_filter; export all; #filter ospf_filter; area 0 { interface "eth0","eth1" { check link yes; cost 5; hello 5; retransmit 2; wait 10; dead 20; ecmp weight 5; }; interface "dummy0" { stub yes; cost 1; }; stubnet 2001:db8:0:f101::/128; }; } birdc6 show route BIRD 1.4.0 ready. 2001:db8:0:f101:ccde:85ff:fe22:ec43/128 multipath [ospf1 15:14:27] ! I (150/5) [172.16.250.8] via fe80::225:90ff:fe97:a718 on eth0 weight 5 via fe80::225:90ff:fe97:a719 on eth1 weight 5 2001:db8:0:f101:e010:b8ff:feb6:d4a/128 dev dummy0 [direct1 15:14:16] * (240) dev dummy0 [ospf1 15:14:17] I (150/0) [172.16.250.251] 2001:db8:0:f103::/64 dev eth1 [direct1 15:14:16] * (240) dev eth1 [ospf1 15:14:27] I (150/5) [172.16.250.8] 2001:db8:0:f102::/64 dev eth0 [direct1 15:14:16] * (240) dev eth0 [ospf1 15:14:27] I (150/5) [172.16.250.8] birdc6 show ospf top BIRD 1.4.0 ready. area 0.0.0.0 router 172.16.250.8 distance 5 network [172.16.250.8-2] metric 5 network [172.16.250.8-3] metric 5 router 172.16.250.251 distance 0 network [172.16.250.8-2] metric 5 network [172.16.250.8-3] metric 5 network [172.16.250.8-2] distance 5 router 172.16.250.8 router 172.16.250.251 network [172.16.250.8-3] distance 5 router 172.16.250.8 router 172.16.250.251 birdc6 show ospf ne BIRD 1.4.0 ready. ospf1: Router ID Pri State DTime Interface Router IP 172.16.250.8 1 full/dr 00:20 eth0 fe80::225:90ff:fe97:a718 172.16.250.8 1 full/dr 00:20 eth1 fe80::225:90ff:fe97:a719 birdc6 show interfaces BIRD 1.4.0 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 ::1/128 (Primary, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=9000 2001:db8:0:f102:92e2:baff:fe31:44c/64 (Primary, scope univ) fe80::92e2:baff:fe31:44c/64 (Unselected, scope link) eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=9000 2001:db8:0:f103:92e2:baff:fe31:44d/64 (Primary, scope univ) fe80::92e2:baff:fe31:44d/64 (Unselected, scope link) eth2 DOWN (index=4) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth3 up (index=5) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::92e2:baff:fe31:44f/64 (Primary, scope link) eth4 up (index=6) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::225:90ff:fea1:82a6/64 (Primary, scope link) eth5 DOWN (index=7) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 bond0 DOWN (index=8) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 ovs-system DOWN (index=9) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 ovs-vm up (index=10) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::b485:3ff:fe6b:e1f5/64 (Primary, scope link) dummy0 up (index=11) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2001:db8:0:f101:e010:b8ff:feb6:d4a/128 (Primary, scope univ) fe80::94c5:c3ff:fe84:dd26/64 (Unselected, scope link) -- Vasiliy Tolstov,

2 5

BIRD - iBGP between both RS - invalid NEXT-HOP notification.
by Javor Kliachev 08 Apr '14

08 Apr '14

Hello, We use BIRD as route server for a long time without any problems. We have both fully symmetric RS for redundancy. Yesterday we decided to establish "internal BGP session" between both of them. The reason to do this is to achieve prefix symmetric on both RS. Some of our members hold BGP session only with one of our route servers. But after establishing this BGP session we began to see the following message into our logs on both RS for total random prefixes on absolutely random intervals. Here is part of my bird.log: 07-03-2014 14:19:41 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:19:41 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.156.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.148.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/20 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.152.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.156.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/20 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.148.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.152.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/22 07-03-2014 14:16:39 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:16:39 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:01:39 R0_52: Invalid NEXT_HOP attribute in route 95.168.66.0/23 07-03-2014 14:01:39 R0_52: Invalid NEXT_HOP attribute in route 95.168.68.0/23 07-03-2014 13:52:02 R0_14: Invalid NEXT_HOP attribute in route 151.252.198.0/24 07-03-2014 13:51:57 R0_14: Invalid NEXT_HOP attribute in route 151.252.198.0/24 07-03-2014 13:29:36 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:29:28 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:29:15 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:29:06 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:28:14 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:28:14 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:36 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:31 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:31 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:19:31 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:22 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:13:43 R0_71: Invalid NEXT_HOP attribute in route 46.229.194.0/24 07-03-2014 13:13:43 R0_71: Invalid NEXT_HOP attribute in route 46.229.192.0/23 07-03-2014 13:13:42 R0_29: Invalid NEXT_HOP attribute in route 46.229.194.0/24 07-03-2014 13:13:42 R0_29: Invalid NEXT_HOP attribute in route 46.229.192.0/23 07-03-2014 13:06:22 R0_60: Invalid NEXT_HOP attribute in route 193.104.73.0/24 07-03-2014 13:03:54 R0_52: Invalid NEXT_HOP attribute in route 178.79.61.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 89.35.114.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 86.105.150.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 46.102.181.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 46.102.176.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 37.156.69.0/24 07-03-2014 12:54:25 R0_60: Invalid NEXT_HOP attribute in route 188.240.70.0/24 07-03-2014 12:54:25 R0_60: Invalid NEXT_HOP attribute in route 188.212.157.0/24 07-03-2014 12:34:43 R0_52: Invalid NEXT_HOP attribute in route 91.148.106.0/24 07-03-2014 12:27:48 R0_52: Invalid NEXT_HOP attribute in route 91.148.118.0/24 07-03-2014 12:16:33 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 12:16:33 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 12:09:39 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 12:09:10 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 12:08:57 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 12:08:50 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 12:08:49 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 12:02:41 R0_52: Invalid NEXT_HOP attribute in route 212.200.0.0/21 07-03-2014 11:47:01 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 11:47:01 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 10:55:50 R0_60: Invalid NEXT_HOP attribute in route 91.206.209.0/24 I had checked many times and make many tests if the next-hop is correct and everything looks fine but this messages comes permanently :) We managed to troubleshoot the following behavior and relationship and see the following effect: Our scenario: 0.100 0.200 RS1 <- iBGP -> RS2 | | | | TEST.AS ----------- 0.252 TEST.AS announce: 31.13.244.0/24 RS2 learn this prefix as: 31.13.244.0/24 via 10.1.0.252 on eth0 [R0_252 14:44] * (100) [AS60230i] via 10.1.0.252 on eth0 [*R0_100* 15:12 from 10.1.0.100] (100) [AS60230i] As soon as we stop to announce 31.13.244.0/24 from TEST.AS to RS1, in the logs of RS1 begin to come the following message: 07-03-2014 15:10:09R0_252: Invalid NEXT_HOP attribute in route 31.13.244.0/24 But when we try to shutdown (administratively ) the session between TEST.AS and RS1 this behavior does not occur and everything seems normal. I hope this information will be useful for resolving this strange issue. Here is our configuration set on both RS. The real AS number & IPs has been changed for security reason :) # RS2: table T65535 protocol pipe P65535 from iBGP_PIPES { description "RS1"; peer table T65535; export where RS_PIPE_OUT(); } protocol bgp R0_100 from iBGP { description "0.100_iBGP_RS1"; source address 10.1.0.200; neighbor 10.1.0.100 as 65535; import all; export all; passive off; table T65535; route limit 10000; gateway direct; } # RS1: table T65535 protocol pipe P65535 from iBGP_PIPES { description "RS2"; peer table T65535; export where RS_PIPE_OUT(); } protocol bgp R0_200 from iBGP { description "0.200_iBGP_RS1"; source address 10.1.0.100; neighbor 10.1.0.200 as 65535; import all; export all; passive off; table T65535; route limit 10000; gateway direct; } # show bgp summary shows the following: # RS2: ---------------------------------------------------------------- adv / rcv / limit --- 0.100_iBGP_RS1 10.1.0.100 65535 Mar06 Established 4527/3235/10000 -------------------------------------------------------------------------------------- # RS1: ---------------------------------------------------------------- adv / rcv / limit --- 0.200_iBGP_RS2 10.1.0.200 65535 Mar06 Established 3235/4527/10000 -------------------------------------------------------------------------------------- Any ideas or thoughts are highly appreciated! Thanks in advance! -- --- Find out about our new Cloud service - Cloudware.bg <http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link…> Access anywhere. Manage it yourself. Pay as you go. ------------------------------------------------------------------------ *Javor Kliachev* IP Engineer Neterra Ltd. Telephone: +359 2 975 16 16 Fax: +359 2 975 34 36 www.neterra.net <http://www.neterra.net>

4 7

BGP TTL Hack and BIRD
by Kris Pederson 07 Apr '14

07 Apr '14

Hi, Does BIRD support the "TTL Hack"? If so, please advise on configuration recommendations. Thanks! Details on this hack: === The Generalized TTL Security Mechanism (GTSM, RFC 3682 [39]), often referred to as the "TTL hack", is a simple but effective defense that takes advantage of TTL processing. As noted, normal communications such as e-mail or Web browsing often require 20 or more nodes to reach their destination, and this value varies depending on the application. With BGP, however, peers are normally adjacent, thus only one hop should be required for a packet sent in a BGP message. A BGP message that has passed through multiple nodes is therefore almost certainly either an error or a packet from an attacker. The TTL hack sets the TTL to 255 on outgoing packets. Since routers decrement the TTL field by one when a packet is forwarded, adjacent peers should see incoming packets with TTL = 255. (Note that some implementations decrement the TTL before processing, in which case the incoming packets should have TTL = 254.) A lower value is an indication that the packet originated from somewhere other than the neighboring peer router (see Fig. 4-3). (Note that it is impossible for the packet to start with an initial value above 255, because the TTL field is an 8-bit value.) When implementing the TTL hack, it is also possible to set an expected incoming value below 255 on a per-peer basis when the peer is a known number of hops away, allowing a small variation to allow for changes in topology. For example, if the peer is known to be one hop away, the adjacent peer should reject packets with a TTL < 254. One limitation with the TTL hack is its availability. Code implementing RFC 3682 is provided on newer routers from major vendors, but may not always be included on older, or "legacy", routers, so not all organizations may be able to deploy it. Kris Pederson Equinix

2 1

Cnange next-hop
by Alexander Shikov 04 Apr '14

04 Apr '14

Hi, continuing the implemetation of blackhole in our IXP, I've faced with problem of changing next-hop for the route. Construction looks like if (net.len = 32 && bgp_community ~ [ (31210,*) ] && bgp_community ~ [ (0,666) ] ) then { gw = 193.25.181.253; return true; } results in : bird> show route for 95.67.13.2/32 all 95.67.13.2/32 via 193.25.181.253 on bge0 [COSMONOVA2 2014-04-04 17:59:19 from 193.25.180.133] * (50) [AS34867i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 34867 BGP.next_hop: 193.25.180.133 BGP.local_pref: 100 BGP.community: (0,666) (31210,31210) And when this route is announced to other peer, next-hop remains unchanged: Peerings.inet.0: 16708 destinations, 50556 routes (16627 active, 0 holddown, 88 hidden) + = Active Route, - = Last Active, * = Both 95.67.13.2/32 *[BGP/170] 00:12:14, localpref 100, from 193.25.180.255 AS path: 34867 I > to 193.25.180.133 via xe-1/0/0.777 As far as I understand from User's Guide, gw is an read-write attribute, so why it didn't change next-hop? Thanks in advance! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/

3 3

BIRD 1.4.2 compile fails with debug option
by Bahram BahramBeigy 04 Apr '14

04 Apr '14

Hi, When I want to compile BIRD with --enable-debug option, it fails with the following error. while without the debug option it compiles fine. [Archlinux gcc 4.8.2 20140206 (prerelease), kernel 3.13.8] gcc -I../ -I../.. -g -O2 -pthread -Wall -Wstrict-prototypes > -Wno-parentheses -Wno-pointer-sign -fno-strict-aliasing > -fno-strict-overflow -o proto.o -c ../../nest/proto.c > In file included from ../../nest/bird.h:13:0, > from ../../nest/proto.c:11: > ../../nest/proto.c: In function ‘proto_want_export_up’: > ../../nest/proto.c:1238:27: error: ‘CS_HAPPY’ undeclared (first use in > this function) > ASSERT(p->core_state == CS_HAPPY); > ^ > ../lib/birdlib.h:125:30: note: in definition of macro ‘ASSERT’ > #define ASSERT(x) do { if (!(x)) bug("Assertion `%s' failed at %s:%d", > #x, __FILE__, __LINE__); } while(0) > ^ > ../../nest/proto.c:1238:27: note: each undeclared identifier is reported > only once for each function it appears in > ASSERT(p->core_state == CS_HAPPY); > ^ > ../lib/birdlib.h:125:30: note: in definition of macro ‘ASSERT’ > #define ASSERT(x) do { if (!(x)) bug("Assertion `%s' failed at %s:%d", > #x, __FILE__, __LINE__); } while(0) > ^ > ../../nest/proto.c: In function ‘proto_want_core_down’: > ../../nest/proto.c:1261:27: error: ‘CS_HAPPY’ undeclared (first use in > this function) > ASSERT(p->core_state == CS_HAPPY); > ^ > ../lib/birdlib.h:125:30: note: in definition of macro ‘ASSERT’ > #define ASSERT(x) do { if (!(x)) bug("Assertion `%s' failed at %s:%d", > #x, __FILE__, __LINE__); } while(0) > ^ > ../Rules:76: recipe for target 'proto.o' failed -- Best wishes, Bahram BahramBeigy http://www.bahrambeigy.ir

2 1

Version 1.4.2
by Ondrej Filip 02 Apr '14

02 Apr '14

Hi! To release a new version on April 1st was of course a joke. :-( So here is a new version with important bugfix in BFD implementation. Ondrej

1 0

OSPF interface going down, why?
by Ruben Laban 02 Apr '14

02 Apr '14

Hi, I was wondering about possible causes for the following log message: 2014-04-02 05:14:02 <TRACE> ospf1: Changing state of iface vlan0251 from ptp to down No other log messages prior to this one currently. I did enable debug logging hoping it would shed some more light on the issue. But I don't know when it'll happen again. This is bird 1.3.8 running in a vSphere VM, so there's plenty of areas where network issues could arise. Regards, Ruben Laban

1 0

ospf ecmp with ipv6
by Vasiliy Tolstov 02 Apr '14

02 Apr '14

Hello. Does bird supports ecmp on ipv6 and how can i test that ecmp works? -- Vasiliy Tolstov,

1 0