OpenOSPFd and multipath routing questions...

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenOSPFd and multipath routing questions...

David Ulevitch
Misc,

I'd like to hear how people are using OpenOSPFd and how it's working  
out.

Are people using it in any sort of a local-cluster load balancing  
method?  For example: rtr1 servers area 1 and has three NTP servers  
attached all announcing the same /32 over OSPF with some logic on the  
server to withdraw the OSPF announcement if the service goes down?

Also, are people having any issues with the fact that ospfd and bgpd  
each hold a copy of the routing table (at least) and are doing  
inserts into the kernel's table, without any sort of preference for  
multipath routing or metrics? (http://www.openbsd.org/papers/ven05- 
henning/mgp00026.html)

Any replies, onlist or off, appreciated.

Thanks,
david

Reply | Threaded
Open this post in threaded view
|

Re: OpenOSPFd and multipath routing questions...

Claudio Jeker
On Mon, Nov 28, 2005 at 11:46:56PM -0800, David Ulevitch wrote:
> Misc,
>
> I'd like to hear how people are using OpenOSPFd and how it's working  
> out.
>

It works for most setups. It is not optimal for big ABRs.

> Are people using it in any sort of a local-cluster load balancing  
> method?  For example: rtr1 servers area 1 and has three NTP servers  
> attached all announcing the same /32 over OSPF with some logic on the  
> server to withdraw the OSPF announcement if the service goes down?
>

Nope. There is no kernel support for multipath routing. First we need to
have working multipath routing before making ospfd multipath aware.

> Also, are people having any issues with the fact that ospfd and bgpd  
> each hold a copy of the routing table (at least) and are doing  
> inserts into the kernel's table, without any sort of preference for  
> multipath routing or metrics? (http://www.openbsd.org/papers/ven05- 
> henning/mgp00026.html)
>

In most cases this is a non issue because bgpd and ospfd are inserting
different routes into the kernel. bgpd should announce the aggregated
prefix (e.g. a /19 or so) and for that no real route is needed. ospfd on
the other hand will add more specifc networks of that /19 and so the two
should not interfere with each other.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: OpenOSPFd and multipath routing questions...

tony sarendal
On 29/11/05, Claudio Jeker <[hidden email]> wrote:

> On Mon, Nov 28, 2005 at 11:46:56PM -0800, David Ulevitch wrote:
> > Misc,
> >
> > I'd like to hear how people are using OpenOSPFd and how it's working
> > out.
> >
>
> It works for most setups. It is not optimal for big ABRs.
>
> > Are people using it in any sort of a local-cluster load balancing
> > method?  For example: rtr1 servers area 1 and has three NTP servers
> > attached all announcing the same /32 over OSPF with some logic on the
> > server to withdraw the OSPF announcement if the service goes down?
> >
>
> Nope. There is no kernel support for multipath routing. First we need to
> have working multipath routing before making ospfd multipath aware.
>
> > Also, are people having any issues with the fact that ospfd and bgpd
> > each hold a copy of the routing table (at least) and are doing
> > inserts into the kernel's table, without any sort of preference for
> > multipath routing or metrics? (http://www.openbsd.org/papers/ven05-
> > henning/mgp00026.html)
> >
>
> In most cases this is a non issue because bgpd and ospfd are inserting
> different routes into the kernel. bgpd should announce the aggregated
> prefix (e.g. a /19 or so) and for that no real route is needed. ospfd on
> the other hand will add more specifc networks of that /19 and so the two
> should not interfere with each other.
>

I would disagree a bit. Most(All ?) bigger network use bgp to carry
internal routing
info, we just filter the internal stuff away on our peerings. Seeing
the same prefix
via multiple protocols is pretty common, especially when migrating from
protocol x to protocol y.

One thing I noticed when testing with openbsd was that I wasn't able to add
xxx/yy on an interface if the same prefix already was known via bgp.

/Tony