ospf uses private ip as a gateway
Hi. I'm using bird 1.2.5 from debian squeeze respository. I've got two routers with public a private ip addresses on the connecting interfaces. The public addresses are selected as primary in device protocol but ospf chooses private address as the address to route prefixes over. When I block ospf packets from the private addresses it switches fine but when I allow ospf to them it switches all the routes to the private gateways again. Is there any way to force bird to use public addresses other then setting them as primary in device protocol specification? I want to keep interface names in interfaces definitions instead of ip addresses. thanks for your help mk
On Sun, Mar 20, 2011 at 03:56:02AM +0100, Martin Kraus wrote:
Hi. I'm using bird 1.2.5 from debian squeeze respository. I've got two routers with public a private ip addresses on the connecting interfaces. The public addresses are selected as primary in device protocol but ospf chooses private address as the address to route prefixes over. When I block ospf packets from the private addresses it switches fine but when I allow ospf to them it switches all the routes to the private gateways again.
Is there any way to force bird to use public addresses other then setting them as primary in device protocol specification? I want to keep interface names in interfaces definitions instead of ip addresses.
For a while, BIRD handles more addresses on one iface as a virtually separate ifaces/networks (that is, AFAIK, the same way as Quagga handles that). You can check that with 'show ospf interface'. So in your case, you got two adjacencies between the routers with the same cost and it is up to a chance which will be chosen as a route. When you blocked private addresses, one adjacency broke. The primary setting in device protocol does nothing for OSPF, because OSPF now does not handle primary addresses in a special way. That was a kludge before we got proper multi-address support. [*] So you would need to specify addresses (or at least prefixes) in interface definitions. See http://bird.network.cz/?get_doc&f=bird-3.html#dsc-iface for details. You could either add prefixes to interface definitions to restrict application of that definitions on the public addresses, or you could add something like this as the first definition: interface 192.168.0.0/16 { stub; }; That would match all private addresses and change that to stubs, public addresses get over that and matches with later definitions. [*] That is true for Linux. On *BSD, we still have the old behavior and generally multi-address support is problematic there. -- 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 Sun, Mar 20, 2011 at 03:47:21PM +0100, Ondrej Zajicek wrote:
For a while, BIRD handles more addresses on one iface as a virtually separate ifaces/networks (that is, AFAIK, the same way as Quagga handles that). You can check that with 'show ospf interface'. So in your case, you got two adjacencies between the routers with the same cost and it is up to a chance which will be chosen as a route. When you blocked private addresses, one adjacency broke.
Hi. Thanks. I thought that the primary definition still had a meaning.
So you would need to specify addresses (or at least prefixes) in interface definitions. See http://bird.network.cz/?get_doc&f=bird-3.html#dsc-iface for details. You could either add prefixes to interface definitions to restrict application of that definitions on the public addresses, or you could add something like this as the first definition:
interface 192.168.0.0/16 { stub; };
That would match all private addresses and change that to stubs, public addresses get over that and matches with later definitions.
Is it possible to use sets in the interface definition? like interface 10.0.0.0/8+ { stub; }; to match all the possible prefixes from the 10.0.0.0/8 private definition? mk
On Sun, Mar 20, 2011 at 04:48:22PM +0100, Martin Kraus wrote:
interface 192.168.0.0/16 { stub; };
That would match all private addresses and change that to stubs, public addresses get over that and matches with later definitions.
Is it possible to use sets in the interface definition? like
interface 10.0.0.0/8+ { stub; };
to match all the possible prefixes from the 10.0.0.0/8 private definition?
No and yes - you cannot specify prefix sets (like in filters), but the prefixes in interface definitions are meant to match subprefixes. interface 10.0.0.0/8 { stub; }; should do that. -- 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 Sun, Mar 20, 2011 at 03:47:21PM +0100, Ondrej Zajicek wrote:
For a while, BIRD handles more addresses on one iface as a virtually separate ifaces/networks (that is, AFAIK, the same way as Quagga handles that). You can check that with 'show ospf interface'. So in your case, you got two adjacencies between the routers with the same cost and it is up to a chance which will be chosen as a route. When you blocked private addresses, one adjacency broke.
The primary setting in device protocol does nothing for OSPF, because OSPF now does not handle primary addresses in a special way. That was a kludge before we got proper multi-address support. [*]
....
[*] That is true for Linux. On *BSD, we still have the old behavior and generally multi-address support is problematic there.
Hi. So what is the "primary" setting in device protocol for at this moment? In the documentation it still states that it is for use by ospfv2. I've used it for ospf so I guess I can delete it now. Just curious. thanks mk
participants (2)
-
Martin Kraus -
Ondrej Zajicek