[LARTC] Fail-over uplink problem

[LARTC] Fail-over uplink problem

[Torsten Luettgert]

Hi list,

I have a problem I thought was simple first, but now I'm stuck.
In a nutshell, it's about redundant uplinks at an outside location.
Crude ASCII-Art follows:

          Internet
           |    |
       +------------+
       | cisco with |
       | uplinks    |
       +------------+
         |         | ATM interface
 +----------+     ...
 | alvarion |      |
 | wireless |    +-------+
 | base     |    | DSL   |
 +----------+    | modem |
     |||         +-------+
 +------------+      |
 | wireless   |      |
 | subscriber |     / 
 +------------+    /  
           |      /
        +-------------+
        | small linux |
        | box         |
        +-------------+
               |
          target net      

The target net is connected via a 20 MBit wireless connection which
should be the "normal" route, and a 2 MBit DSL connection as backup.
Switching to the backup line should work automatically. There are link
networks between the linux box and the DSL modem and between the linux
box and the base (subscriber is acting as a bridge).

We control all the equipment, including the cisco. So I thought I'd use
quagga and build a small OSPF or RIP between the linux box and the
cisco where the linux box announces the target net. The wireless route
would have higher priority because of the higher line speed.

But how do I set the "default route" on the box? I don't want to
redistribute BGP into OSPF on the cisco, it knows 2x20,000 routes from
two uplink peers and the linux box is really small (300 MHz Celeron
with 128 MB RAM).

Thanks in advance for any advice.

- Torsten


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Fail-over uplink problem

[Grant Taylor]

On 11/24/06 18:05, Torsten Luettgert wrote:
> I have a problem I thought was simple first, but now I'm stuck.
> In a nutshell, it's about redundant uplinks at an outside location.
> Crude ASCII-Art follows:

It has been experience that things that seem simple seldom are.  :s

>           Internet
>            |    |
>        +------------+
>        | cisco with |
>        | uplinks    |
>        +------------+
>        |            | ATM interface
>  +----------+      ...
>  | alvarion |       |
>  | wireless |    +-------+
>  | base     |    | DSL   |
>  +----------+    | modem |
>      |||         +-------+
>  +------------+      |
>  | wireless   |      |
>  | subscriber |     / 
>  +------------+    /  
>            |      /
>         +-------------+
>         | small linux |
>         | box         |
>         +-------------+
>                |
>           target net      

Yep, this is one of things that is not as simple as it seems.

> The target net is connected via a 20 MBit wireless connection which
> should be the "normal" route, and a 2 MBit DSL connection as backup.
> Switching to the backup line should work automatically. There are link
> networks between the linux box and the DSL modem and between the linux
> box and the base (subscriber is acting as a bridge).

By "... link networks between ..." do you mean that the DSL modem and / or the subscriber unit are not directly connected to the Linux box?  I.e. you can not rely on the ethernet link state. (I'll presume yes for discussion.)

> We control all the equipment, including the cisco. So I thought I'd use
> quagga and build a small OSPF or RIP between the linux box and the
> cisco where the linux box announces the target net. The wireless route
> would have higher priority because of the higher line speed.

That seems a bit of over kill, at least on the Linux end.  However, seeing as how I'm not really that proficient at Cisco, I'm not sure what choice(s) you will have.

> But how do I set the "default route" on the box? I don't want to
> redistribute BGP into OSPF on the cisco, it knows 2x20,000 routes from
> two uplink peers and the linux box is really small (300 MHz Celeron
> with 128 MB RAM).

I would write a small daemon (Perl script) that would periodically test the link to the Cisco equipment.  If the primary link is down, try the backup.

Are you dealing with NATed traffic, or is your TargetNet a globally routable subnet?  If TargetNet is globally routable, things are a bit easier as in you don't have to maintain NAT states.

I would recommend that you not have the same subnet on the DSL and the wireless link.  This way, you can set up two different routing tables, one for the DSL and one for the wireless link.  Then you can have your daemon monitor / test connectivity to the targets.  Have your daemon do a quick "ip rule" update and "ip route flush cache" when the links change.

Something else you could try would be to have each link be a different subnet and have two different default routes, each with a different metric.  The routers should use the route with the lower metric.  If for some reason the lower metric does not work, the router should fall back to the higher metric.  However for this to work, I think one piece of equipment would have to be the aggregation point on each end.  If your equipment setup would allow this, I think this would be an easier / safer / more maintainable route to go.  However if you can not do this, think along the lines of my other suggestion.

If you can provide more information on your specific scenario, I'd be more than happy to refine my recommendations.




Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Fail-over uplink problem

[Torsten Luettgert]

On Mo, 2006-12-04 at 19:36 -0600, Grant Taylor wrote:
> On 11/24/06 18:05, Torsten Luettgert wrote:

> By "... link networks between ..." do you mean that the DSL modem
> and / or the subscriber unit are not directly connected to the
> Linux box?  I.e. you can not rely on the ethernet link state.
> (I'll presume yes for discussion.)

They are indeed directly connected, but I still don't want to rely
on the link state. I meant there are two /30 networks just for the
linux box and modem/subscriber.

> > We control all the equipment, including the cisco. So I thought I'd use
> > quagga and build a small OSPF or RIP between the linux box and the
> > cisco where the linux box announces the target net. The wireless route
> > would have higher priority because of the higher line speed.
> 
> That seems a bit of over kill, at least on the Linux end.
> However, seeing as how I'm not really that proficient at Cisco,
> I'm not sure what choice(s) you will have.

It actually worked except for one showstopper on the cisco :-(
The solution was "default-information originate always", btw.,
just for the archives. This command is identical in Cisco IOS
and quagga.

The problem: my cisco only accepts direct neighbours for OSPF, so I
built GRE tunnels and everything was fine... except the default route
(of course) pointed into the tunnel, and I'm not keen on sending
20 MBit through GRE, what with all the MTU, fragmentation and
router CPU load problems.

> I would write a small daemon (Perl script) that would periodically
> test the link to the Cisco equipment.  If the primary link is down,
> try the backup.

That's what I'm doing now. I didn't want to originally: I can easily
make the linux box send packets upstream via the backup route, but I
would need my script log in on the cisco and change routes. Gives me
a bad taste.

> Are you dealing with NATed traffic, or is your TargetNet a
> globally routable subnet?  If TargetNet is globally routable,
> things are a bit easier as in you don't have to maintain NAT
> states.

No NAT there :-)

> I would recommend that you not have the same subnet on the DSL
> and the wireless link.  This way, you can set up two different
> routing tables, one for the DSL and one for the wireless link.
> Then you can have your daemon monitor / test connectivity to
> the targets.  Have your daemon do a quick "ip rule" update and
> "ip route flush cache" when the links change.

That sounds good for the linux side.

> Something else you could try would be to have each link be a
> different subnet and have two different default routes, each
> with a different metric.  The routers should use the route
> with the lower metric.  If for some reason the lower metric
> does not work, the router should fall back to the higher metric.

How would it "know" the line is down? In my experience, in most
cases the interface stays up just fine, but packets vanish
because of radio problems or something.

Thanks for your suggestions,
Torsten


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Fail-over uplink problem

[Taylor, Grant]

Torsten Luettgert wrote:
> They are indeed directly connected, but I still don't want to rely
> on the link state. I meant there are two /30 networks just for the
> linux box and modem/subscriber.

*nod*

> The problem: my cisco only accepts direct neighbours for OSPF, so I
> built GRE tunnels and everything was fine... except the default route
> (of course) pointed into the tunnel, and I'm not keen on sending
> 20 MBit through GRE, what with all the MTU, fragmentation and
> router CPU load problems.

Ok, maybe I'm not understanding why your router is not seen as a direct neighbor.  Or is this like a Cisco CDP thing where a piece of layer 3 equipment will see a layer 2 switch as a neighbor verses the other piece of layer 3 equipment on the other side of the layer 2 switch?

Indeed.  Nor would I relish sending that much traffic through any sort of tunnel.

> That's what I'm doing now. I didn't want to originally: I can easily
> make the linux box send packets upstream via the backup route, but I
> would need my script log in on the cisco and change routes. Gives me
> a bad taste.

*nod*

> No NAT there :-)

Good.

> That sounds good for the linux side.

*nod*

> How would it "know" the line is down? In my experience, in most
> cases the interface stays up just fine, but packets vanish
> because of radio problems or something.

Don't hold me to this, but I think it has something to do with ARP caching.  If your Cisco knows that it needs to send the packets to a gateway that is in it's broadcast domain it will ARP for the gateways MAC so that it can send the packets to it.  If for some reason the ARP requests fail, the Cisco will know that the gateway's IP is unreachable and thus that it needs to use an alternant route.  Sorry, I can not get any more specific than that.  I'm not even really sure that what I said is entirely accurate, that is just the understanding that I have had based on my experiences.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc