Several ptmp OSPF sessions over a single interface

[Ruben Laban]

On 8/27/2012 2:10 PM, Ruben Laban wrote:
> On 8/27/2012 1:58 PM, 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:
>>
>> 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?
>
> FTR, the solution I'm currently testing with is using:
>
> ip address add 192.168.255.10 peer 192.168.255.11 dev eth1
>
> instead of:
>
> ip address add 192.168.255.10/31 dev eth1
>
> Seems to work fine so far, but suggestions/comments/etc are still more
> than welcome.

Forgot to mention something in my previous follow-up: the downside of 
the alternative mentioned above is that now 192.168.255.10 and 
192.168.255.11 don't show up in the routing tables of the other nodes. 
Which, without applying other "fixes" would break traffic originating 
from those nodes using those IP addresses, including for instance 
traceroutes.

Regards,
Ruben Laban