Hi! I have compiled bird from git with "git clone git://git.nic.cz/bird.git" on FreeBSD 8.2. (btw, why is the version on that 1.2.3 according to sysdep/config.h when there is an 1.2.5 release?) I've got ospf running on ipv4 between this machine and a OpenBSD-curent running OpenOSPF. They both can see eachother and also their lo1loopback interface where there is an ipaddress of an /32 net which ends on OpenOSPF with .1 and .4 on the bird. There is also an /128 net for the ipv6 part. This addresses is ping-able from both machine so the route does exists as expected. Now, I took that working configuration of bird and changed it to bird6. protocol ospf o6 { tick 2; area 0.0.0.0 { interface "vlan15" { hello 3; cost 7; }; interface "lo1" { stub yes; cost 1; }; }; } Bird can see and do inject the routes from OpenOSPF but can't see (?) the routes from bird6. bird> show route 2a03:xxxx:xxxx::xxxx:f01/128 via fe80::1e6f:65ff:fe81:c4ef on vlan15 [o6 15:53] * I (150/7) [xx.xx.xx.1] 2a03:xxxx:xxxx::xxxx:fc0/127 via fe80::1e6f:65ff:fe81:c4ef on vlan15 [o6 15:53] * I (150/7) [xx.xx.xx.1] 2a03:xxxx:xxxx::xxxx:fd0/127 dev vlan15 [o6 15:48] * I (150/7) [xx.xx.xx.4] bird> quit Now, why is bird6 showing that the routes should route via the link-local addresses? If bird6 is announcing that to OpenOSPF I can see that it won't add that route. -- //fredan
On Thu, Mar 03, 2011 at 04:20:34PM +0100, fredrik danerklint wrote:
Hi!
I have compiled bird from git with "git clone git://git.nic.cz/bird.git" on FreeBSD 8.2. (btw, why is the version on that 1.2.3 according to sysdep/config.h when there is an 1.2.5 release?)
Because last two versions were branches (with cherrypicked patches), so the trunk version was not updated.
I've got ospf running on ipv4 between this machine and a OpenBSD-curent running OpenOSPF.
They both can see eachother and also their lo1loopback interface where there is an ipaddress of an /32 net which ends on OpenOSPF with .1 and .4 on the bird. There is also an /128 net for the ipv6 part.
Could you send me an output of 'ip a l' to get list of addresses, 'birdc show interfaces' and 'birdc show ospf state' ?
This addresses is ping-able from both machine so the route does exists as expected.
Now, I took that working configuration of bird and changed it to bird6.
protocol ospf o6 { tick 2; area 0.0.0.0 { interface "vlan15" { hello 3; cost 7; }; interface "lo1" { stub yes; cost 1; }; }; }
Bird can see and do inject the routes from OpenOSPF but can't see (?) the routes from bird6.
bird> show route 2a03:xxxx:xxxx::xxxx:f01/128 via fe80::1e6f:65ff:fe81:c4ef on vlan15 [o6 15:53] * I (150/7) [xx.xx.xx.1] 2a03:xxxx:xxxx::xxxx:fc0/127 via fe80::1e6f:65ff:fe81:c4ef on vlan15 [o6 15:53] * I (150/7) [xx.xx.xx.1] 2a03:xxxx:xxxx::xxxx:fd0/127 dev vlan15 [o6 15:48] * I (150/7) [xx.xx.xx.4] bird> quit
Now, why is bird6 showing that the routes should route via the link-local addresses?
That is a standard behavior for OSPFv3 (IPv6).
If bird6 is announcing that to OpenOSPF I can see that it won't add that route.
In OSPF (compared to BGP or RIP) routes are not announced to peers, link state is announced. Each router then computes all its routes based on shared complete link state (which can be shown using 'show ospf state' bird command). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
On Thu, Mar 03, 2011 at 04:20:34PM +0100, fredrik danerklint wrote:
Hi!
I have compiled bird from git with "git clone git://git.nic.cz/bird.git" on FreeBSD 8.2. (btw, why is the version on that 1.2.3 according to sysdep/config.h when there is an 1.2.5 release?)
Because last two versions were branches (with cherrypicked patches), so the trunk version was not updated.
ok. Next part has I figured out with a simple "traceroute6" command and sure enough, it just seems to work "tm" the way it suppose to do! There is one thing tough and that is that the ip addresses of the loopback interface lo1 is not announced to the others within the ospd area in ip6. Is there some way to have it announced and that it follows the state of the interface (ie UP and DOWN), just like the ospf for ip4 does allready. -- //fredan
On Sun, Mar 06, 2011 at 04:34:52PM +0100, fredrik danerklint wrote:
There is one thing tough and that is that the ip addresses of the loopback interface lo1 is not announced to the others within the ospd area in ip6.
The reason for that is probably that loopback does not have a link-local address and BIRD skips that interfaces. BTW, the fact that it works in IPv4 is unexpected, it was supposed that loopback and its addresses would be completely ignored by OSPF. I thought that (at least in Linux) it is a common trick to use dummy interface for such purposes (which looks in many ways like a common interface, unlike the loopback interface) instead of loobpack but i don't know a good rationale for that.
Is there some way to have it announced and that it follows the state of the interface (ie UP and DOWN), just like the ospf for ip4 does allready.
If you add that prefix using 'stubnet' then it is completely unrelated to any interface and will be announced always. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
Hi I have similar issues running bird 1.2.5 on vanilla debian lenny. IPv4 wise I assign /32s to individual lo:x instances as service addresses. These are showing up in bird. IPv6 wise I cannot assign /128s to individual lo:x but to the "real" loopback lo. This works fine in quagga. These are not showing up in bird. If I look at the kernel table from shell with ip -6 route, the /128s are shown as "unreachable" with error -101 but working fine with ping and so on. How would I do this "right"? Assigning /128s to loopbacks is standard on ciscos and alike for setting up iBGP peering and I believe most people will try to configure it like that. Any advice or help is much appreciated. /Tias On 3/20/11 16:22 , Ondrej Zajicek wrote:
On Sun, Mar 06, 2011 at 04:34:52PM +0100, fredrik danerklint wrote:
There is one thing tough and that is that the ip addresses of the loopback interface lo1 is not announced to the others within the ospd area in ip6.
The reason for that is probably that loopback does not have a link-local address and BIRD skips that interfaces. BTW, the fact that it works in IPv4 is unexpected, it was supposed that loopback and its addresses would be completely ignored by OSPF. I thought that (at least in Linux) it is a common trick to use dummy interface for such purposes (which looks in many ways like a common interface, unlike the loopback interface) instead of loobpack but i don't know a good rationale for that.
Is there some way to have it announced and that it follows the state of the interface (ie UP and DOWN), just like the ospf for ip4 does allready.
If you add that prefix using 'stubnet' then it is completely unrelated to any interface and will be announced always.
On Tue, Mar 22, 2011 at 03:13:06PM +0100, Mathias Wolkert wrote:
Hi
I have similar issues running bird 1.2.5 on vanilla debian lenny.
IPv4 wise I assign /32s to individual lo:x instances as service addresses.
These are showing up in bird.
IPv6 wise I cannot assign /128s to individual lo:x but to the "real" loopback lo.
This works fine in quagga.
These are not showing up in bird.
If I look at the kernel table from shell with ip -6 route, the /128s are shown as "unreachable" with error -101 but working fine with ping and so on.
How would I do this "right"?
On Linux, the simplest workaround (for OSPF problem) is just to add the address to the dummy interface [*] instead of the loopback interface. But you mentioned iBGP - in current stable version (1.2.5), iBGP is significantly limited and should be used with one-hop, directly reachable addresses. For proper iBGP, you should try git version, or wait for 1.3.0 (which will be probably released 2011-04-01). [*] http://linax.wordpress.com/2009/09/12/linux-dummy-network-device/ -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
On 3/23/11 11:04 , Ondrej Zajicek wrote:
On Tue, Mar 22, 2011 at 03:13:06PM +0100, Mathias Wolkert wrote:
Hi
I have similar issues running bird 1.2.5 on vanilla debian lenny.
IPv4 wise I assign /32s to individual lo:x instances as service addresses.
These are showing up in bird.
IPv6 wise I cannot assign /128s to individual lo:x but to the "real" loopback lo.
This works fine in quagga.
These are not showing up in bird.
If I look at the kernel table from shell with ip -6 route, the /128s are shown as "unreachable" with error -101 but working fine with ping and so on.
How would I do this "right"?
On Linux, the simplest workaround (for OSPF problem) is just to add the address to the dummy interface [*] instead of the loopback interface.
This looks promising. Thanks a lot.
But you mentioned iBGP - in current stable version (1.2.5), iBGP is significantly limited and should be used with one-hop, directly reachable addresses. For proper iBGP, you should try git version, or wait for 1.3.0 (which will be probably released 2011-04-01).
I'm not doing it (yet), it was more of an example where I'd use loopbacks/dummies. Thanks for the heads up though.
[*] http://linax.wordpress.com/2009/09/12/linux-dummy-network-device/
/Tias
participants (3)
-
fredrik danerklint -
Mathias Wolkert -
Ondrej Zajicek