[MLB-WIRELESS] Revisiting OSPF

Nick Grundy ngrundy at isoproplex.net
Tue Dec 14 19:13:56 EST 2004


Hi,

I saw the posts on the quagga-users mailing list and thought i'd add my 
thoughts on the routing stuff. (I also host www.au.quagga.net)

Down in Hobart we've gone with BGP accross our entire network.  We 
initally tried OSPF about 2 years ago now but it caused major headaches 
with regards to running stable.  Quite a few times we had the ospf 
daemons silently die but I think that was mostly due to multicast issues.

At the moment we have around 9 or 10 AS on our network a map can be seen 
here  http://starnet.shacknet.nu/taswireless.jpg  We've been lucky in 
that our network has grown as a single entity with no disconnected 
segments.  Our assignment of AS is fairly ad-hoc and no where near 
optiomal due to learning BGP while setting it up but that's what it's 
all about in our books, experimentation.

 From a keeping the shit running point of view BGP makes much more 
sence.  Within a region or whatever you can run ospf/rip/eigrp (if 
you're made of money :) etc but to get back into the main network you 
need to talk BGP and redistribute your IGP into the EGP.  It just so 
happens that our entire network uses an EGP well iBGP :)

Config is fairly simple

router bgp 64512
 redistribute connected
 neighbor 192.168.4.9 remote-as 64516
 neighbor 192.168.4.9 soft-reconfiguration inbound
 neighbor 192.168.4.22 remote-as 64512
 neighbor 192.168.4.22 next-hop-self
 neighbor 192.168.4.22 soft-reconfiguration inbound

we set next-hop-self on iBGP sessions because we use /30 point to point 
links.  This came about due to the network starting off as an ad-hoc 
card to card arangement we could move to adding subnets to aps and 
assigning like that but it's never happend.

no need to set next-hop-self on eBGP links as that happens automaticly 
when you cross an AS.

we also occasionally do some funky stuff like
 neighbor 192.168.8.14 distribute-list Filter10Network in
access-list Filter10Network deny 10.0.0.0/8
access-list Filter10Network permit any

Nothing to realy write home about but we do this crazy sort of stuff.

we don't run BGP on every node we only install it on a non endpoint 
node.  ie the site generally has an uplink and an omni and for end users 
that don't have a second interface we add a static route and 
redistribute static.

Quite a few of our routers these days are Linksys WRT54G's i think we've 
gone from 0 to 9 of these units in around 2 months. we use quagga on 
these units to do all of our routing and interface configuration the 
only IP that is hard coded into the unit is the LAN interface ip in 
NVRAM other than that they all come from zebra.conf or via bgp.

we have a bit of a basic howto listed at 
http://starnet.shacknet.nu/wiki/index.php?page=LinkSysModification 
thought i'm sure you've got plenty of guys in melboune who have played 
with these things.

~Nick

Dan Flett wrote:

>Hi all,
>
>I've been having some discussions with the people on the Quagga-Users
>mailing list about OSPF and routing in general.  The Quagga Mail Archive
>doesn't list the thread properly so here are the interesting posts so
>far:
>
>My intial message:
>http://lists.quagga.net/pipermail/quagga-users/2004-December/003350.html
>James Haesu's response:
>http://lists.quagga.net/pipermail/quagga-users/2004-December/003351.html
>My response:
>http://lists.quagga.net/pipermail/quagga-users/2004-December/003362.html
>James Haesu's response:
>http://lists.quagga.net/pipermail/quagga-users/2004-December/003365.html
>David Young of the Champaign-Urbana Community Wireless Network's
>response
>http://lists.quagga.net/pipermail/quagga-users/2004-December/003375.html
>
>The upshot of all this discussion is I've come to the realisation that
>OSPF alone is not a suitable routing protocol for the entire Melbourne
>Wireless network.
>
>Why?
>
>OSPF is an interior routing protocol.  An interior routing protocol is
>one that is designed to be used within a single Autonomous System.  An
>Autonomous System is a network or group of networks under a common
>administration and with common routing policies.
>
>The Melbourne Wireless Network has a common routing policy, but it can
>not be said to be an Autonomous System, because it is not under a common
>administration.  No one person or team of persons has administrative
>privileges (i.e. root access) to all of the routers on the entire
>Melbourne Wireless network.  To function properly - in a way that is
>truly scalable, OSPF requires this.
>
>OSPF requires that the network topology grow under the control of an
>administrative body - which then assigns nodes to a backbone and,
>optionally, to other 'areas'.  The Melbourne Wireless network grows
>organically.  An administrative body, if there was one, has no real
>control as to which nodes and areas will connect to which, and after the
>network reaches a certain size, assigning nodes to OSPF areas after the
>fact is messy and impractical - the administrative body would have to
>make requests to node-owners to change their configuration - and rely on
>the node-owners to do the changes properly and in a timely manner.  This
>is not a good solution for network based on volunteers, most of whom are
>not network engineers.
>
>OSPF has strict requirements - the backbone area must be connected, and
>all other areas must connect directly to the backbone.  However, as
>we've seen over the past couple of years, the network will grow in ways
>that don't necessarily meet OSPF requirements.
>
>Through the use of LocFinder we have automated IP and OSPF area
>allocation, which forms our Routing Policy.  But for OSPF to work, a
>single administrative body would need to control all routers to
>continuously redefine backbone routers, virtual-links and
>shortcut-areas, as links between non-backbone-areas appear and
>disappear.  Individual node-owners or Regional Groups are not allowed
>the chance to define their own routing policy under such a system.  In a
>community network, they should be allowed this chance - to be Autonomous
>Systems unto themselves.
>
>I believe we need to use an exterior or 'interautonomous system' routing
>protocol as the main routing protocol, such as BGP.  If and when a true
>backbone appears, under the control of a single administrative body, it
>should use an interior routing protocol, such as OSPF alongside iBGP.
>Region Group clusters can also form their own local backbones and run
>OSPF or any other routing protocol they deem appropriate as a regional
>Autonomous System.  The use of OSPF areas other than area 0 should
>probably be discouraged as this adds a layer of administrative
>complexity, and in any case, a regional AS probably would probably not
>get big enough to warrant it.
>
>The Melbourne Wireless network would then be seen as a network of many
>Autonomous Systems, all speaking eBGP to each other at their gateways.
>This is exactly how the Internet itself functions, and it has shown
>itself to be highly scalable.  Regional Autonomous Systems, or even
>individual nodes acting as an AS on their own, could view the rest of
>the network as a "cloud" - ignorance is bliss - and let the exterior
>routing protocol take care of things.  There would be no need for
>routers in one AS to know about the link-states (and therefore the
>network topology) in another AS.
>
>I am quite interested in hearing people's opinions on this idea.  If we
>can start to agree on things we can start to work out the details and
>come up with a proposal for change.  At this point I'm happy to discuss
>this on the main list.  If the discussion causes too much traffic that
>non-participants don't want to read we can take it to another list or a
>wiki page or whatever.
>
>Cheers,
>
>Dan
>
>PS, there's a good intro to BGP here:
>http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm
>As always, Google is your friend.
>
>To unsubscribe: send mail to majordomo at wireless.org.au
>with "unsubscribe melbwireless" in the body of the message
>
>
>  
>


To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message



More information about the Melbwireless mailing list