On Mon, Oct 17, 2005 at 12:00:38PM -0400, stan wrote:
> On Mon, Oct 17, 2005 at 05:41:20PM +0200, Claudio Jeker wrote:
> > On Mon, Oct 17, 2005 at 10:57:41AM -0400, stan wrote:
> > > On Mon, Oct 17, 2005 at 04:12:48PM +0159, Claudio Jeker wrote:
> > > > On Mon, Oct 17, 2005 at 09:39:01AM -0400, stan wrote:
> > 
> > > 
> > > Hmm, that seems to have gotten me close. Here's the new ospfd.conf file:
> > > 
> > > 
> > > # $OpenBSD: ospfd.conf,v 1.2 2005/02/06 20:07:09 norby Exp $
> > > 
> > > # global configuration
> > > router-id 170.85.113.111
> > > 
> > > # areas
> > > area 0.0.0.120 {
> > >   interface fxp0 {
> > >           auth-type none
> > >   }
> > >   interface fxp2 {
> > >           auth-type none
> > >           passive
> > >   }
> > > }
> > > 
> > 
> > <config stripped a bit>
> > 
> > 
> > That is not the config you pasted before. You are running OSPF
> > over carp here. This is nuts and will not work. You can not run any kind
> > of routing protocol over carp without major issues! If you have two
> > routers in front of a common network use carp towards that network and
> > OSPF to connect the two routers to the backbone.
> > If one router fails ospf will take care and adjust the routing table.
> > Currently I think you need to use "redistribute static" for that setup or
> > wait a couple of days till I fixed something.
> 
> Ah, in retrospect this makes sense. So the "externa;" interfaces on these 2
> machines don't need carp ata all. But I will still need it on the "insid"
> as the machines on the internal network just have static routes in them.
> So. I guess the gateway machines should each advertise their "real"
> interfaces in the ospfd.conf file? Or should that be their carp interface?
> 

Currently it does not matter because the result is the same. In near
future the state of the interface should be considered before announcing
it -- this is done for redistribute connected but not for stub networks.
If both routers announce the same network with the same metric it is not
fully defined how traffic will flow. In case of ciscos it will do per flow
round robin over the two routers and this may cause some issues. So to fix
this issue you should add an additional metric 50 or so to the internal
interface on the backup router. Like:

area 0.0.0.120 {
        interface fxp0 {
                auth-type none
        }
        interface carp1 {
                passive
                metric 50
        }
}

In that case the backup is less preferred and so routing will be directed
directly to the master. This helps especially pfsync.

> > 
> > As I said before don't run ospf over carp. It will not work. You can use
> > it fot the inside network but not for the one connected to the backbone.
> >  
> 
> So, my ospfd.conf file should look like this?
> 
> 
> # areas
> area 0.0.0.120 {
>       interface fxp0 {
>               auth-type none
>       }
>       interface carp1 {
>               auth-type none
>               passive
>       }
> }
> 
> Or would this be better?
> 
> # areas
> area 0.0.0.120 {
>       interface fxp0 {
>               auth-type none
>       }
>       interface fxp2 {
>               auth-type none
>               passive
>       }
> }
> 
> The "external" interface is fxp0, and the internal one is fxp2. The
> internal carp is carp1, and the outside one (carp0) will go away.
> 

I would use the carp1 interface. As soon as we make stub network
announcements dependent of the link state fail over will be more smooth
and will also track some cases that are currently unhandled.

> Thanks very much for taking the time to educate me on this.
> 

-- 
:wq Claudio

Reply via email to