Several ptmp OSPF sessions over a single interface

[Ondrej Zajicek]

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.


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120827/286ac118/attachment-0001.asc>