- Bird-users - Mailing Lists

bird 1.3.8 vs 1.3.6
by fredrik danerklint 10 Sep '12

10 Sep '12

Hi! Is there something with these versions that is not compatibly with each other for the ospf to work in ipv6? Right now I have a bird 1.3.8 instance neither announce nor getting an routes in a area. It is stuck in the exchange state. The ip4 versions also get stuck in the loading state for a while and then continue. (during the loading state the routes are announced to the others - so it's working somewhat). -- //fredan

2 3

Re: No routes??
by ril.kidd 09 Sep '12

09 Sep '12

Ok, i have DNS running on one peer (route client) and listening on a virtual sub-interface (I intend to add more and do anycasting). the other peer will be a route server. It is the route to the virtual IP on the route client that I want to propagate to the route server. bird> sh protocols all name proto table state since info kernel1 Kernel master up 14:03 Preference: 10 Input filter: ACCEPT Output filter: ACCEPT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 device1 Device master up 14:03 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 RC1p BGP master up 14:04 Established Description: Route Client1 Peer Preference: 100 Input filter: ACCEPT Output filter: ACCEPT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored 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.128.32 Neighbor AS: 64496 Neighbor ID: 192.168.128.32 Neighbor caps: refresh AS4 Session: external route-server AS4 Source address: 192.168.128.31 Hold timer: 179/240 Keepalive timer: 37/80 #Route client bird.conf router id 192.168.128.21; #protocol direct { # interface "-eth*", "*"; # Restrict network interfaces it works with #} protocol kernel { # learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds # import none; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol bgp RouteSrv { # disabled; description "Route Server Peer"; local as 64496; neighbor 192.168.128.20 as 65000; import all; export all; # multihop; } #Route Server bird.conf router id 192.168.128.20; # Martian networks function net_martian() { return net ~ [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 127.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 0.0.0.0/0{25,32}, 0.0.0.0/0{0,7} ]; } #Local networks function net_local() { return net ~ [ 192.168.128.0/24+, 192.168.122.0/24+ ]; } function rt_import(int asn; int set peer_asns; prefix set peer_nets) { if ! (net ~ peer_nets) then return false; if ! (bgp_path.last ~ peer_asns) then return false; if bgp_path.first != asn then return false; if bgp_path.len > 64 then return false; if bgp_next_hop != from then return false; return true; } function rt_export_all() { if proto = "static_bgp" then return true; if source != RTS_BGP then return false; if net_martian() then return false; if bgp_path.len > 64 then return false; return true; } #protocol direct { # interface "-eth*", "*"; # Restrict network interfaces it works with #} protocol kernel { # learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds # import none; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } protocol device { scan time 10; # Scan interfaces every 10 seconds } filter bgp_in_client { if ! rt_import(64496, [ 64496 ], [ 192.168.128.0/24, 10.0.0.0/23+ ]) then reject; accept; } filter bgp_out_client { if ! rt_export_all() then reject; accept; } protocol bgp RC1 { # disabled; description "Route Client1 Peer"; local as 65000; neighbor 192.168.128.21 as 64496; import filter bgp_in_client; export filter bgp_out_client; rs client; } [admin@rs ~]# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:1A:64:22:5F:E9 inet addr:192.168.128.31 Bcast:192.168.128.255 Mask:255.255.255.0 inet6 addr: fe80::21a:64ff:fe22:5fe9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3726 errors:0 dropped:0 overruns:0 frame:0 TX packets:1964 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:331155 (323.3 KiB) TX bytes:187893 (183.4 KiB) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [admin@rc ~]# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:1A:64:22:60:01 inet addr:192.168.128.33 Bcast:192.168.128.255 Mask:255.255.255.0 inet6 addr: fe80::21a:64ff:fe22:6001/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25056 errors:0 dropped:0 overruns:0 frame:0 TX packets:10341 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2368094 (2.2 MiB) TX bytes:1065046 (1.0 MiB) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:22 errors:0 dropped:0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1900 (1.8 KiB) TX bytes:1900 (1.8 KiB) lo:0 Link encap:Local Loopback inet addr:10.0.1.1 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1 This worked ok on Ubuntu On 09/09/12 18:49, ??????? ??????? wrote: > 2012/9/9 ril.kidd <ril.kidd(a)gmail.com>: >> The following commands give me: Peer is not a protocol >> >> >> birdc show protocols all Peer >> birdc show route all protocol Peer >> birdc show route all export Peer >> >> Output from "'# netstat -rn" is: >> Kernel IP routing table >> Destination Gateway Genmask Flags MSS Window irtt >> Iface >> 192.168.128.0 0.0.0.0 255.255.255.0 U 0 0 0 >> eth0 >> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 >> eth0 >> 0.0.0.0 192.168.128.28 0.0.0.0 UG 0 0 0 >> eth0 > Well, 1: which routes you expect your bird to propagate to peer? > 169.254.0.0/16 network. must NOT be routed anyway. > 2: ports out otput of "show protocols all " command here please. > 3: show your FULL and UNCUT config file. > 4: ifconfig -a > > >> >> On 09/09/12 17:18, ??????? ??????? wrote: >>> 2012/9/9 ril.kidd <ril.kidd(a)gmail.com>: >>>> On 09/09/12 16:57, ril.kidd wrote: >>>> >>>> Sorry, bird.conf looks like this: >>>> >>>> >>>> router id 192.168.128.21; >>>> >>>> #protocol direct { >>>> # interface "-eth*", "*"; # Restrict network interfaces it works >>>> with >>>> #} >>>> >>>> protocol kernel { >>>> # learn; # Learn all alien routes from the >>>> kernel >>>> persist; # Don't remove routes on bird >>>> shutdown >>>> scan time 20; # Scan kernel routing table every 20 >>>> seconds >>>> # import none; # Default is import all >>>> export all; # Default is export none >>>> # kernel table 5; # Kernel table to synchronize with >>>> (default: >>>> main) >>>> } >>>> >>>> protocol device { >>>> scan time 10; # Scan interfaces every 10 seconds >>>> } >>>> >>>> protocol bgp Peer { >>>> # disabled; >>>> description "Peer"; >>>> local as 64496; >>>> neighbor 192.168.128.20 as 65000; >>>> import all; >>>> export all; >>>> # multihop; >>>> } >>>> >>>> On 09/09/12 16:53, Crest wrote: >>>> >>>> On 09.09.2012 17:50, ril.kidd wrote: >>>> >>>> On 09/09/12 16:10, ril.kidd wrote: >>>> >>>> hello, >>>> I have two ubuntu 12.04 linux servers running bird 1.3.8 and peered >>>> with >>>> each other. >>>> The routes from each show in both routing tables. >>>> >>>> I installed centos 6.3 on an (identically configured) different set of >>>> servers and copied the configuration files. I see peering >>>> established but >>>> no >>>> routes in both routing tables. It doesnt work when peered with the >>>> ubuntu >>>> servers either. >>>> Please what may be wrong? Or am I just missing something? >>>> >>>> >>>> Actually, when i do "show route" from birdc> i dont get any results >>>> >>>> Sorry my crystal ball is unaligned how about a few bird.conf >>>> snippets to >>>> calibrate it? >>>> >>>> >>>> >>> What about output from these commands: >>> birdc show protocols all Peer >>> birdc show route all protocol Peer >>> birdc show route all export Peer >>> netstat -rn >>> ? >>> > >

2 5

Re: No routes??
by ril.kidd 09 Sep '12

09 Sep '12

On 09/09/12 16:57, ril.kidd wrote: > Sorry, bird.conf looks like this: > > / > router id 192.168.128.21; > > #protocol direct { > # interface "-eth*", "*"; # Restrict network interfaces it works > with > #} > > protocol kernel { > # learn; # Learn all alien routes from the kernel > persist; # Don't remove routes on bird shutdown > scan time 20; # Scan kernel routing table every 20 > seconds > # import none; # Default is import all > export all; # Default is export none > # kernel table 5; # Kernel table to synchronize with > (default: main) > } > > protocol device { > scan time 10; # Scan interfaces every 10 seconds > } > > protocol bgp Peer { > # disabled; > description "Peer"; > local as 64496; > neighbor 192.168.128.20 as 65000; > import all; > export all; > # multihop; > }/ > > On 09/09/12 16:53, Crest wrote: >> On 09.09.2012 17:50, ril.kidd wrote: >>> On 09/09/12 16:10, ril.kidd wrote: >>>> hello, >>>> I have two ubuntu 12.04 linux servers running bird 1.3.8 and peered >>>> with each other. >>>> The routes from each show in both routing tables. >>>> >>>> I installed centos 6.3 on an (identically configured) different set >>>> of servers and copied the configuration files. I see peering >>>> established but no routes in both routing tables. It doesnt work >>>> when peered with the ubuntu servers either. >>>> Please what may be wrong? Or am I just missing something? >>>> >>>> >>> Actually, when i do "show route" from birdc> i dont get any results >> Sorry my crystal ball is unaligned how about a few bird.conf snippets >> to calibrate it? >

2 3

No routes??
by ril.kidd 09 Sep '12

09 Sep '12

hello, I have two ubuntu 12.04 linux servers running bird 1.3.8 and peered with each other. The routes from each show in both routing tables. I installed centos 6.3 on an (identically configured) different set of servers and copied the configuration files. I see peering established but no routes in both routing tables. It doesnt work when peered with the ubuntu servers either. Please what may be wrong? Or am I just missing something?

1 1

Re: BIRD v1.3.8 - some notes and hamradio requests
by Ondrej Zajicek 31 Aug '12

31 Aug '12

On Tue, Aug 28, 2012 at 02:33:44PM +0200, Gustavo Ponza wrote: > Eureka! that patch *definitively* solved the above problem, too :) > The BIRD behavior is now *perfectly* equal to that of quagga and > the Mikrotik and so, for me, no other limitations to run exclusively > the BIRD program. > Then, that patch *MUST* definitively enter on the official BIRD > release. It probably will. >> 1) your only activated interfaces in config file were ppp0, tap0 and eth0, >> therefore no reason to propagate 44.134.33.71/32, which is just on sl0. >> You probably want to activate these ifaces as stub ifaces ('stub' option >> for them). > > My tests confirm that: declaring an 'iface' as a 'stub' is perfectly > equal to *not activate* that 'iface', at least this happens on the OSPF > environment. As result I obtained no OSPF activity and no prefix > prefix propagation. Not true. Interface as stub propagate its addresses to OSPF (at least if it is normal broadcast iface with normal IP prefix, ptp ifaces are a bit special), while not active iface is just ignored. >> ifaces. BTW, from the log i see that BIRD misdetected AX.25 interfaces - >> ifconfig says that they can't support multicast while BIRD says the can. > > About the disagreement between the BIRD detection and the ifconfig > output that should be a good question for the AX.25 linux developers > so, as time permits, I'll try to contact one of them. It is probably a bug in BIRD. >> Note that you can also simply add local IP or prefix for propagation >> using 'stubnet' option. The simplest way to see what your router >> is propagating is to find it in 'show ospf state'. > > I was not able to setup a 'stubnet' command to test that feature :( > no examples found on the documentation and so any setup attempts got > the reply: errors on configuration file... You can use it like: area 0.0.0.0 { stubnet 192.168.11.0/24; stubnet 192.168.12.0/24 { hidden; summary; }; }; It is documented here: http://bird.network.cz/?get_doc&f=bird-6.html#ss6.5 > But, in the meantime, since I can monitor the exported routes also > on the Mikrotik router, I discovered that my LAN prefix 192.168.1.0/ > /24 results propagated by the OSPF (FYI on quagga it does not), so, > how can I stop the propagation of such a prefix? (and naturally for > any other prefix I do not want to export). Yes, it is propagated because it is on eth0, which is activated for OSPF. You can either activate eth0 just for some of its addresses: interface "eth0" 192.168.2.0/24 { ... } see examples in here: http://bird.network.cz/?get_doc&f=bird-3.html#dsc-iface or you could suppress that prefix for propagation using stubnet option: stubnet 192.168.1.0/24 { hidden; } But this will not work if there is some other OSPF router connected through 192.168.1.0/24, but that is probably not an issue here. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)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."

2 1

bird 1.3.7 setting incorrect nexthop on FreeBSD
by Виталий Туровец 31 Aug '12

31 Aug '12

Hello there, people! I have a strange moment with bird's behaviour on FreeBSD 9.0-RC3 (FreeBSD 9.0-RC3 i386 GENERIC): It establishes BGP sessions, succesfully exchanges routes and when exporting them to kernel sets 127.0.0.1 via lo0 as next hop. An example: bird> show route all 192.168.2.0/24 192.168.2.0/24 unreachable [Cisco 22:11 from 172.16.0.252] * (100/-) [AS65002i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 172.16.0.252 BGP.med: 0 BGP.local_pref: 100 BGP.community: (65001,252) bird> show route all export kernel1 192.168.2.0/24 192.168.2.0/24 unreachable [Cisco 22:11 from 172.16.0.252] * (100/-) [AS65002i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 BGP.next_hop: 172.16.0.252 BGP.med: 0 BGP.local_pref: 100 BGP.community: (65001,252) [22:11][border][~] # netstat -rn -f inet | grep 192.168.2.0 192.168.2.0/24 127.0.0.1 UR1 0 8 lo0 [22:15][border][~] # route get 192.168.2.1 route to: 192.168.2.1 destination: 192.168.2.0 mask: 255.255.255.0 interface: lo0 flags: <UP,REJECT,DONE,PROTO1> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 And from the other side there's Cisco's router (the problem also persists on BGP between bird and quagga): OfficeCisco#show ip bgp neighbors 172.16.0.253 advertised-routes | in 192.168.2 *> 192.168.2.0 172.16.0.38 0 0 65002 i OfficeCisco#show ip route 192.168.2.0 255.255.255.0 Routing entry for 192.168.2.0/24 Known via "bgp 65001", distance 20, metric 0 Tag 65002, type external Last update from 172.16.0.38 3d02h ago Routing Descriptor Blocks: * 172.16.0.38, from 172.16.0.38, 3d02h ago Route metric is 0, traffic share count is 1 AS Hops 1 This same route with exactly same settings is also advertised to another FreeBSD box running quagga and the route is correctly handled and installed with correct nexthop: [22:21][db][~] $ netstat -rn -f inet | grep 192.168.2.0 192.168.2.0/24 172.16.0.252 UG1 0 1475392 LAN [22:21][db][~] $ s vtysh -c 'sh ip bgp 192.168.2.0/24' BGP routing table entry for 192.168.2.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 65002 172.16.0.252 (metric 1) from 172.16.0.252 (192.168.0.2) Origin IGP, metric 0, localpref 100, valid, internal, best Last update: Thu Aug 30 10:56:20 2012 My BGP neighbors and kernel configuration here: protocol kernel { learn; persist; scan time 10; import all; export where source = RTS_BGP; } protocol static AS65001 { description "Nets that we export"; route 192.168.0.0/24 reject; route 192.168.1.0/24 reject; route 172.16.0.248/29 reject; route 95.158.3.122/32 reject; route 0.0.0.0/0 reject; } filter bgp_from_db{ if net = 0.0.0.0/0 then { reject; }else{ bgp_community=add(bgp_community,(65001,253)); accept; } } filter bgp_from_cisco{ if net = 0.0.0.0/0 then { reject; }else{ bgp_community=add(bgp_community,(65001,252)); accept; } } filter bgp_to_db { if proto="AS65001" then { bgp_community=add(bgp_community,(65001,254)); accept; } else reject; } filter bgp_to_cisco { if net ~ 192.168.1.0/24 then reject; if proto="AS65001" then { bgp_community=add(bgp_community,(65001,254)); accept; } else reject; } protocol bgp DB { description "DB Server"; local as 65001; neighbor 172.16.0.253 as 65001; import filter bgp_from_db; export filter bgp_to_db; } protocol bgp Cisco { description "Office<->Service 2620"; local as 65001; neighbor 172.16.0.252 as 65001; import filter bgp_from_cisco; export filter bgp_to_cisco; } And this is what bird shows in log: 30-08-2012 22:25:35 <TRACE> kernel1: 192.168.2.0/24: seen 30-08-2012 22:25:35 <TRACE> kernel1: Pruning table master 30-08-2012 22:25:35 <TRACE> kernel1: Pruning inherited routes 30-08-2012 22:25:45 <TRACE> device1: Scanning interfaces 30-08-2012 22:25:45 <TRACE> kernel1: Scanning routing table 30-08-2012 22:25:45 <TRACE> Setting fib to 0 for route dump 30-08-2012 22:25:45 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 95.158.3.120/29: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 95.158.3.122/32: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 95.158.3.123/32: seen 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.0/27: seen 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.36/30: seen 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.248/29: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 172.16.0.254/32: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.0.0/24: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.0.1/32: [alien] seen 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.0.4/32: seen 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.1.0/24: ignored 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.1.1/32: [alien] seen 30-08-2012 22:25:45 <TRACE> ... 30-08-2012 22:25:45 <TRACE> kernel1: 192.168.2.0/24: seen 30-08-2012 22:25:45 <TRACE> kernel1: Pruning table master 30-08-2012 22:25:45 <TRACE> kernel1: Pruning inherited routes Thank you guys for help! -- ~~~ WBR, Vitaliy Turovets Systems Administrator Corebug.Net +38(093)265-70-55 VITU-RIPE

2 2

bird and OSPF on p2p
by Eugene M. Zheganin 30 Aug '12

30 Aug '12

Hi, guys ! I'm trying to use bird/OSPF on a bunch of gre tunnels. Though I'm using it successfully with ipv6 on same tunnels, I have no clue why it doesn't announce the networks when on ipv4. My typical setup is as follows: VPN HUB <-----WAN/gre/OSPF-----> branch router <--local-network--> At this time VPN HUB runs quagga/ospfd (due to this problem I'm talking about). I receive all the routing updates from HUB on a branch router, but HUB doesn't get anything from a branch router: HUB: # ifconfig gre14 gre14: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 mtu 1476 tunnel inet 192.168.3.24 --> 192.168.6.191 inet 172.16.3.134 --> 172.16.3.135 netmask 0xffffffff inet6 fe80::21a:64ff:fe21:8e80%gre14 prefixlen 64 scopeid 0x2b nd6 options=3<PERFORMNUD,ACCEPT_RTADV> # vtysh [...] sh ip ospf nei [...] 192.168.6.191 1 Full/DROther 38.434s 172.16.3.135 gre14:172.16.3.134 0 0 0 # route -n get 192.168.9.0/27 route: writing to routing socket: No such process Branch: # birdc -s /var/run/bird.ctl BIRD 1.3.8 ready. bird> show ospf neighbors ospfv4: Router ID Pri State DTime Interface Router IP 192.168.3.24 1 full/ptp 00:33 gre0 172.16.3.134 bird> sh route protocol direct1 192.168.6.128/25 dev vr2 [direct1 14:02] * (240) 192.168.9.0/27 dev bridge0 [direct1 14:02] * (240) 172.16.3.134/32 dev gre0 [direct1 14:02] * (240) bird> sh route filter exportospfv4 192.168.9.0/27 dev bridge0 [direct1 14:02] * (240) 172.16.3.134/32 dev gre0 [direct1 14:02] * (240) gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0 mtu 1476 tunnel inet 192.168.6.191 --> 192.168.3.24 inet 172.16.3.135 --> 172.16.3.134 netmask 0xffffffff inet6 fe80::20d:b9ff:fe20:d980%gre0 prefixlen 64 tentative scopeid 0x9 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Thanks. Eugene.

4 12

OSPFv3: link-local address required on loopback interface?
by Tore Anderson 29 Aug '12

29 Aug '12

I've run across a rather weird behaviour in BIRD 1.3.8 regarding the interaction between address(es) on the loopback interface and the OSPFv3 protocol. It seems that if there's no link-local address on the interface, BIRD fails to run OSPF in stub mode on it: $ birdc6 show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 ::1/128 (Primary, scope host) 2001:db8:1::3/128 (Unselected, scope univ) [...] $ birdc6 show ospf interface \"lo\" BIRD 1.3.8 ready. ospf1: $ ip -6 address add fe80::/64 scope link dev lo $ birdc6 show ospf interface \"lo\" BIRD 1.3.8 ready. ospf1: Interface lo (IID 0) Type: nbma Area: 47.4.0.0 (788791296) State: waiting (stub) Priority: 1 Cost: 10 Hello timer: 10 Poll timer: 20 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designed router (ID): 0.0.0.0 Designed router (IP): :: Backup designed router (ID): 0.0.0.0 Backup designed router (IP): :: $ birdc6 show interfaces BIRD 1.3.8 ready. lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=16436 2001:db8:1::3/128 (Primary, scope univ) ::1/128 (Unselected, scope host) fe80::/64 (Unselected, scope link) [...] Question: What does «Ignored» imply here? Also, why did the «Primary» address change as a result of fe80:: being added? In any case, this means that without a link-local address being manually added to the loopback interface, the primary address of the router won't be reachable from the rest of the network, in turn causing problems for monitoring and possibly other protocols like iBGP. This must be a bug, right? Being able to import the loopback interface of a router as a stub network into the IGP is pretty fundamental functionality. Also, link-local addresses aren't typically seen on loopback interfaces, so expecting them to be there doesn't make much sense to me. My configuration is as follows: protocol device { scan time 10; } protocol kernel { scan time 10; learn; export all; import all; } protocol ospf { area 47.4.0.0 { interface "bond0" { type broadcast; }; interface "*" { stub yes; }; }; } -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

2 3

Several ptmp OSPF sessions over a single interface
by Ruben Laban 29 Aug '12

29 Aug '12

Hello, I'm currently performing some experiments to find the "best" way to inter-connect a bunch of routers using a shared medium. A common scenario would be a set of 4 routers, for instance a pair of border routers and a pair of core routers. I'd like either a full-mesh or circle topology. Putting all nodes in a /29 isn't ideal because of the DR/BDR/etc stuff. I want all nodes and links to be treated equally. Using point-to-multipoint sounds like a decent solution. I can configure several sessions on a single link without interference, up to the point where the circle is created. Like this: A - B | | D - C However, if I try to add a link between A and C, things start to go not as expected. A already has 192.168.255.2/31 (towards B) and 192.168.255.4/31 (towards D) configured. If I add 192.168.255.10/31 (towards C) and 192.168.255.11/31 on C (towards A), A and C can't ping each other using those addresses. This is because A will announce 192.168.255.10/32 throughout the area and thus "overriding" the 192.168.255.10/31 route on C (traffic will would be sent to either B or D, and not directly to A). What would be the cleanest solution for this? Regards, Ruben Laban

2 8

BIRD cpu usage overload - question
by Javor Kliachev 24 Aug '12

24 Aug '12

3 3