On Wed, 17 Jan 2001, Gleb Natapov wrote:
> I am not talking about sending or receiving packets here. OSPF has a strong
> notion
> of interface. Interface has mtu, ip address and many OSPF specific parameters,
> it has state that changes according to interface state machine, it has list
> of neighbours,
> etc, etc. All this things are needed in order to be able to build adjacency
> through the
> interface.
>
urgh. OK. I forgot about ospf "interfaces". I think the term interface is
highly overloaded.
> Currently zebra has one to one mapping between "kernel interfaces" and "zebra
> interfaces".
> If I want to run OSPF (I don't know about other protocols) on secondary ips
> zebra should
> be able to have "zebra interface" for each ip (and not for each interface),
> or, in other words
> one to many mapping. This is only theory, I don't know if it's even possible
> to implement such
> thing (you never know until you'll try ;)).
It sounds reasonable especially from the perspective that you are
forced to maintain distinct neighbor lists per "interface". I think the
problem is solved if Zebra knows how to do NBMA OSPF. On the same link: at
least the physical attributes can be shared (MTU etc) between all the "virtual
links" or maybe not even that if you use path/per-route MTUs.
cheers,
jamal
|