Several ptmp OSPF sessions over a single interface

Ruben Laban r.laban+lists at ism.nl
Mon Aug 27 16:38:47 CEST 2012


On 8/27/2012 4:49 PM, Ondrej Zajicek wrote:
> On Mon, Aug 27, 2012 at 01:58:27PM +0200, Ruben Laban wrote:
>> 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:
>
> First note that (our implementation of) OSPFv2 (on IPv4) is not based
> on physical interfaces, but on 'logical ifaces' based on network
> prefixes/addresses. So if your iface has two independent address
> prefixes or ptp address pairs, it is handled as two ifaces.
>
> Conclusion is that if you use /31 or ptp addresses there is no reason
> to use ptmp mode, you can use ptp mode.
>
> Another note is that whether DR/BDR is used does not depend on whether
> /29 is used, but on 'iface type', which is by default 'bcast' that
> chooses DR, but you can switch it to 'ptmp' which will give you
> probably what you want (but as ptmp mode does not have peer
> autodetection, you have to configure).
>
>> A - B
>> |   |
>> D - C
>
> I see three possibilities:
>
> (1) ptp links using /31 addresses for each link
>
> (2) ptp links using ptp addresses for each link
>
> (3) one /29 address and ptmp mode
>
> (4) one /29 address and ptp (!!) mode
>
>
> (1) Generally should work, you should probably propagate
> another /32 as loopback address.
>
> (2) generally should work and you can use half the addresses than in the
> first case as you can share local address for each ptp pair, so you can
> use just four addresses. This setting has one problem - if for example
> link between A and B (with addresses assigned like 'ip addr add
> 192.168.1.1 peer 192.168.1.2' on A) fails, then communication from A to
> IP 192.168.1.2 would always go through that link because there is
> 192.168.1.2/32 kernel 'neighbor' route in routing table which currently
> cannot be overridden by BIRD OSPF routes. Workaround for this is to
> propagate another /32 as loopback address on each router (which will
> be routed as usuall).
>
> (3) this should work OK, but you have to explicitly configure your
> neighbors using 'neighbors' on each router, because PTMP is generally
> assumed to be run on non-broadcast media, so there is no autodetection
> of peers. Your IP is automatically propagated as /32.
>
> (4) this is a bit nonstandard hack based on fact that PTP and PTMP
> implementation is almost identical so we allow more neighbors even
> on PTP ifaces. There are two small differences compared to (3) - PTP
> uses multicast autodetection so no need to configure peers, but you
> have to explicitly announce that IP as /32 using 'stubnet'
> (PTP do not automatically announce its IP in BIRD).
>
> So the conclusion is to use either (1) or (2), but consider these IP
> addresses used for links as 'link-local' and propagate different /32
> loopback address, or use (3) if you want precise control which neighbor
> adjacencies are established, or use (4) if you want automatic
> establishment of all adjacencies and are not afraid of non-standard
> hacks.
>
>
> I should probably write some thorough explanation of all OSPF interface
> modes in BIRD.

Thank you Ondrej, for these pointers. Without having done any additional 
testing (yet), (3) seems to be pretty close to what I'd want (having to 
specify all neighbors is both a pro and a con I guess). So I'll be sure 
to do some experimenting with that tomorrow.

Some detailed documentation regarding the various modes would surely be 
appreciated indeed ;-)

Regards,
Ruben Laban





More information about the Bird-users mailing list