OSPF vs. Default Route

[MrSmith]

I'm testing out what will soon be a redundant link between my office and the "main" tower. I'm not trying to get too fancy, yet. (Someday, all the bridged clients on the wireless network will be gone, and I'll be able to do complex routing out there. Today is not that day.)

The whole "two links" and "redundancy/failover" thing is working well enough. There are two WRAP boards, each with three Ethernet ports. Right now, this whole mess is just on the floor, and the two wireless links are being simulated by two crossover cables. The third Ethernet port on the "office" router goes into my existing infrastructure; the third one on the "tower" router is just hooked up to a laptop for now.

The two routers are talking to each other just fine. From the "office" router, I can see the "tower" router, and the gateway address on the third Ethernet port. And from the laptop, I can see the first router. The failover and redundancy works fine; I can yank one of the cables and see traffic migrate over within about thirty seconds (slow, but acceptable).

But I can't get past there. The default route isn't propagating out from the office to the tower.

IP addresses (sanitized for your protection):

The "office" router is eth0:10.232.171.194/29, eth1:10.232.171.201/29, eth2:10.232.171.209/29. It has a default gateway of 10.232.171.193 manually set up in "static and default routes".

The "tower" router is eth0:10.232.177.1/24, eth1:10.232.171.202/29, eth2:10.232.171.210/29. Same default route, though it has the (!) indicating it's not a valid route.

eth0 on each device goes to the "local" stuff (my core network for the office, and the wireless network for the tower). eth1 will be one set of bridged radios (a pair of Trangos), eth2 will be another set of bridged radios (another pair of WRAP boards with Atheros cards).

Here's the config from the "office" router:


hostname mvn-office-ospf
password 1234
!
(snipped: lo, tunl0, gre0 interfaces, which were all empty)

interface eth0
!
interface eth1
description trango
ip ospf network non-broadcast
ip ospf cost 17
ip ospf dead-interval 45
!
interface eth2
description wrapradio
ip ospf network non-broadcast
ip ospf cost 7
ip ospf dead-interval 45
!

(snipped: ecb, ipacct, beacon, wlanbr, cbq interfaces)

router ospf
ospf router-id 10.232.171.194
redistribute kernel
redistribute connected
redistribute static
network 10.232.171.192/29 area 0.0.0.20
network 10.232.171.200/29 area 0.0.0.20
network 10.232.171.208/29 area 0.0.0.20
neighbor 10.232.171.202 poll-interval 15
neighbor 10.232.171.210 poll-interval 15
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!
end


And the configuration from the "tower" router (again, with all those empty interfaces omitted):


hostname mvn-mall-ospf
password 1234
!
interface eth0
description malltower
!
interface eth1
description trango
ip ospf network non-broadcast
ip ospf cost 17
ip ospf dead-interval 45
!
interface eth2
description wrapradio
ip ospf network non-broadcast
ip ospf cost 7
ip ospf dead-interval 45
!
router ospf
ospf router-id 10.232.177.1
redistribute connected
network 10.232.171.192/29 area 0.0.0.20
network 10.232.171.200/29 area 0.0.0.20
network 10.232.171.208/29 area 0.0.0.20
neighbor 10.232.171.201 poll-interval 15
neighbor 10.232.171.209 poll-interval 15
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!
end


I can post more stuff (the 'show ip ospf neighbor' and such) if desired. Basically, though, everything else looks like it's working. The two routers can talk to each other just fine, and appear to be propagating each other's routes (not that there are that many routes, but...) For example, from the office router, I can ping 10.232.177.1 (the tower router's "other" address) and 10.232.177.42 (the laptop). And the laptop can make it as far as 10.232.171.193 (the default gateway for the office router), and that office router can get to the rest of the world (because I'm sitting at my desk, not in the server room where all this stuff is splayed out on the floor, and can see it just fine).

What magic have I overlooked to get this last step working?

[bminish]

I think all the redistribute commands need to be removed, especially redistribute kernel.
on the node that sees the default route you will need the following router ospf option set

default-information originate

I see that you have altered the default timings this is probably slowing down the route changeover once the lowest cost route goes down
so remove the following
ip ospf dead-interval 45
and
*** poll-interval 15

The defaults are 10 and 30 which will result in faster changeovers, you could try further reducing these timings but only after you get everything else working as expected

your setup is almost certainly a 'backbone and as such should be in area 0.0.0.0 rather than 0.0.0.20


.Brendan

[MrSmith]

I'm a bit fuzzy on the whole "backbone" thing, and need to do a LOT more reading on OSPF. Hopefully, O'Reilly has a book on it I can buy. There's a chapter in their small Cisco book, but it doesn't go into very much detail, since it's more of a quick-reference than a learning tool.

In the meantime, there are reasons this setup is still on the floor of the server room (with all those crossover cables running about, it looks rather like an evil plate of spaghetti). I'm playing with the timings and link costs and so on. (The costs I put in are indicative of the kind of throughput we expect; they'll no doubt be changed. The Trangos seem to max out at about 7Mbps, despite what the manuals say; the WRAPs appear to max at about 15Mbps, but that's only with the StarOS bandwidth tester, and I understand I'll get better performance in the real world.)

Addding "default-information originate" to the office router appears to have worked -- the tower router can now ping to the outside world. (My laptop got "borrowed" by a co-worker, so I haven't tested it yet, but I don't expect any problems.)

Thanks for the impressively quick reply. If you're ever in southern Illinois, I owe you a beverage.

[bminish]

I'm a bit fuzzy on the whole "backbone" thing, and need to do a LOT more reading on OSPF. Hopefully, O'Reilly has a book on it I can buy. There's a chapter in their small Cisco book, but it doesn't go into very much detail, since it's more of a quick-reference than a learning tool.


there's some reasonably good cisco info on the Internet, most of it applies to Zebra (Zebra is what Staros uses to do OSPF)

OSPF design Guide (http://www.cisco.com/warp/public/104/1.html#intro)
OSPF (http://www.riverstonenet.com/support/ospf_index.shtml)
OSPF Tutorial (http://www.geocities.com/Heartland/4394/work/ospf.html)
OSPF commands (PDF) (http://netknow.cumt.edu.cn/ospf/ospfcommand.pdf)

If you come across other useful resources on the internet please post them here.


Addding "default-information originate" to the office router appears to have worked -- the tower router can now ping to the outside world. (My laptop got "borrowed" by a co-worker, so I haven't tested it yet, but I don't expect any problems.)

just make sure that you don't have any redistribute commands in there unless you are 100% sure you need them. In particular the redistribute kernel command is likely to cause problems as it will redistribute kernel routes and this breaks things.


Thanks for the impressively quick reply. If you're ever in southern Illinois, I owe you a beverage.
Well it's a long way to go for a beer ;-) but thanks anyway

.Brendan

[MrSmith]

I've dropped most of the redistribute commands. (I'm keeping the 'redistribute connected' on the tower radio, basically to save a bit of sanity. In the real world, its eth0 will have five different addresses, and just getting the address information from the interface, instead of putting in five extra network statements, seems a bit cleaner way to do things.)

Hopefully, nothing will come crashing down on me in the absence of an "area 0" at this time. Eventually, the whole wireless network will be running on StarOS boards, and it seems like that would be a more appropriate place for "area 0" -- it'd be on the tower router's eth0, talking to other devices there, and acting as more of a backbone device. This specific link is just a fancy point-to-point. Since "area 0" is supposed to be adjacent to all other areas, this link wouldn't qualify.

O'Reilly doesn't have a whole book on OSPF, so far as I can see. They offer IP Routing (http://www.bureau42.com/amazon/0596002750), which covers OSPF and a lot more (RIP, BGP, EIGRP, the whole alphabet soup). It's said to be very Cisco-centric, but since the Zebra folks go out of their way to make the vtys look like IOS, it's probably close enough. Besides, concepts are universal.

Thanks for the help and advice. This will probably get rolled out for real next week; I'll report back on my success.

[kb1_kanobe]

The "OSPF Network Design Solutions" book from CiscoPress.com is quite good. Weighs in at 745 pages and can$93 and is obviously Cisco-centric in with its commands, but presents all the theories clearly and is 90% portable to Zebra/Quagga.

[MrSmith]

Uhoh, I just ran into another "redistribute" related problem.

I can't figure out the right set of magic incantations to handle routed subnets. Going back to my configurations from below, the tower router's "customer-facing" Ethernet port is 10.232.177.1. Suppose a customer out there has a small subnet of her own, like this:

(tower)177.1 ---> (customer)177.42 ---> (their own subnet)178.0/28

Where, with static routes, it'd just be a simple "10.232.178.0/28 routed to 10.232.177.42" and that's that.

From the office, it's all static routes up 'til the OSPF links. I can get that subnet as far as the office OSPF peer, but it's not seeing the tower OSPF peer announce 178.0/28, so a routing loop occurs.

I can't just put a static route in the office OSPF peer, because it doesn't directly see the next hop (those OSPF thingies are in the way). I've tried "redistribute static" on the tower peer, as well as just putting that subnet in as a network statement in the 'router ospf' configuration section (on either or both OSPF peers).

The current (working for everything else...) configuration, slightly tweaked, with IPs sanitized and "empty" interface statements removed, is not here, to keep this thread from getting even longer... (You can peek at http://www.thedave.us/ospf-uhoh.txt if you like.)

What have I messed up this time?

[MrSmith]

This is puzzling. Logically, what *should* work is just putting the appropriate routes in the tower router, and telling it to 'redistribute static'. But that doesn't work.

At the suggestion of another forum member, I also tried doing that at the office router, which definitely doesn't work -- the static route is tagged as invalid by StarOS. (It is, since the route points to an IP it can't directly reach; it only knows about 10.232.177.x via OSPF.)

I've even tried the dreaded 'redistribute kernel,' which didn't work either.

Is this possibly a real bug of some sort?

[lonnie]

You do not have an area 0. That is your backbone and is what drives OSPF. Everything branches off area 0. bminish has already pointed that out, so please make that change.

All ethernet should be broadcast (default so don't do anything) and radios should be non-broadcast so declare as non broadcast and declare all neighbor radios.

I declare AP units that feed off the backbone as a unique area.

I am still learning and playing. I ordered some high powered and pricy books so we'll see what happens when they get here.

[oscarBravo]

OK, between Lonnie, Brendan and myself we've got this one working.

Here's the problem: 'redistribute static' only redistributes the static routes that zebra itself is aware of. That means that the static routes have to be created in zebra using the 'ip route' command.

To do that, use the telnet client to connect to 127.0.0.1, port 2601. Enter the password and 'enable', then 'configure terminal', and 'ip route x.x.x.x/x y.y.y.y' where x.x.x.x/x is the subnet you want to route to, and y.y.y.y is the gateway address. 'write file', quit, save/activate changes.

Once you've done this, the route should show up in 'show ip ospf routes' in other OSPF-enabled routers - not in the one where you configured the route.

[edit:] You can then delete the static route from the normal static/default routes dialog - you won't be needing it.

[rasimoes]

You do not have an area 0. That is your backbone and is what drives OSPF. Everything branches off area 0. bminish has already pointed that out, so please make that change.

All ethernet should be broadcast (default so don't do anything) and radios should be non-broadcast so declare as non broadcast and declare all neighbor radios.

I declare AP units that feed off the backbone as a unique area.

I am still learning and playing. I ordered some high powered and pricy books so we'll see what happens when they get here.

Lonnie, what book you recommend for me? I need a good and complete OSPF book, because my entire network is OSPF based...

Thanks!

[lonnie]

I have ordered these and am eagerly awaiting their arrival. I do not know if they are any good so I will not yet recommend them as a must have, but they looked good. They are both supposed to go into the commands and have lots of example networks that they setup.

1. OSPF Network Design Solutions - 1 @ $89.29
2. Cisco OSPF Command and Configuration Handbook - 1 @ $81.69

The prices are CDN from Chapters (with my discount).

[rasimoes]

Thanks Lonnie!

[MrSmith]

Note: I'd tried using Area Zero, and that didn't help either.

The note about Zebra not knowing about the static routes is probably what was really going on. It just sounds right. Unfortunately, the old radios (the Trangos) were simply unable to handle the load, and to get things working *now*, I've temporarily given up on Project OSPF. (I just took the two WRAP boards, set them to route instead of bridge, jiggled a couple cables. I don't get the redundancy, but it'll work for now. And I can manually switch things back if need be.)

I've got the extra WRAP boards, and plenty of crossover cables, and will probably try this again in a week or two.

Thanks thanks thanks for all the help and input. I owe a lot of people a lot of beer. :-)

[bminish]

Note: I'd tried using Area Zero, and that didn't help either.


You can get away with using another area providing you don't need to do any inter-area routing, if you need to route between areas then you will need an area 0 as the backbone to do it .


The note about Zebra not knowing about the static routes is probably what was really going on. It just sounds right.

We tested that here and once you tell zebra about the static routes all was well. Zebra will not read routes from the static and default routes table (nor does the static and default routes table need to be configured to use static routes once zebra is running)
It took us a while to work out what was going on , however now we know how to do it and I sure am glad we managed to work it out before it became an essential requirement for us.

When you have another go, do share with us how you get on.

.Brendan