Where can I find an OLSR tutorial

[Mark]

Specifically, one that edumacates us who have no familiarity with it?

I'm thinking, "olsr for dummies"?

Also for OSPF and BGP in Star-OS.

The time has come...

[DrLove73]

Have you tried http://staros.tog.net/wiki/OLSR (http://staros.tog.net/wiki/OLSR)and http://staros.tog.net/wiki/OSPF

Google is the best place to look for manuals and howto's.

[nickwhite]

And depending on how familiar you are/want to be with routing in general: http://forums.star-os.com/showthread.php?t=3768

[Mark]

Does OLSR now interact so that it transfers routing info to Quagga (BGP) now?

[lonnie]

There is no Quagga interaction.

[tog]

It's possible on a vanilla Linux or BSD box of your own where you can compile your own olsrd and make use of the quagga olsr plugin, but that olsr plugin to talk to quagga hasn't been tested and included in StarV3 as far as I know.

[Mark]

Ahh, so then we're back to OSPF...

And no, having "another box" isn't an option. All of this has to fit in an outdoor enclosure and be powered via POE.

dang. It started to look like OLSR was actually an option. Since it doesn't interact with Quagga for BGP purposes, exactly what DO you do with it, other than some self healing internal routing?

I need internal routing AND the ability to tell my provider what routes need to go where, because I'll have gateway redundancy, as well.

[Beebe]

Mark, can't you just advertise your class C or whatever sized networks via BGP, and put them into your border router manually? You can't have all THAT many class C's surely?

Is there another reason why BGP needs to interact with your internal routes?

Thanks,
Roger

[tog]

OLSR is my IGP, BGP is my EGP. I do not need the two to interact with each other for any particularly good reason.

[lonnie]

tog, in fact OLSR would make the ideal IGP since it will choose another exit gateway if its preferred one quits. BGP should really only be at the edge where it announces that it can handle your subnets. BGP does not need and probably should not have any knowledge of your internal scheme.

[bobbyc]

How many of you guys actually use these OSPF/OLSR setups? I don't know much about them.

I'm quite proud of my huge routing tables. Makes me feel smart :)

[DrLove73]

So far, I use RIP since I do not have any mesh, just simple backhaul links. It beats static routes anytime of day or night.

[knolan]

We are running both OLSR and BGP on our network. We are using OLSR for all our internal routing and BGP at our Edge routers to the internet.

We have our own IP range and an AS number from RIPE.

We are using BGP to peer with 2 Transit providers and 1 customer.

Our Edge, Core & Distribution network is 100% StarV3

The 2 Edge routers are both running OLSR to connect to our Core network, and they are also running BGP to connect to our BGP Peers.

These are the only machines to announce to OLSR a default route, and they do iBGP between them, and eBGP to the Transit peers.

Does OLSR announce into BGP? No, but there isn't a requirement to allow this, as we aggregate our IP Ranges at the edge, these are static links. since both OLSR & BGP populate the Kernal routing table, and utilse the Kernal routing table they are working together.



Regards,
Keith

[tog]

Good post, knolan. That's exactly how it works here, too.

Funny that the topic came up, I'm spending the day at the datacenter in Miami tomorrow putting new border routers in, cutting over to GigE on Sat morning and turning up BGP a few days later.

I'm using OpenBGP which I had to hack on a bit to update to 4.3 and make it work under FreeBSD and olsr.org's olsrd running on my own customized compact flash dist of FreeBSD 7 at my edge. I'm using a BGP session established from each of the two routers and CARP for redundancy. My peers setup two sessions and set the nexthop for both to the CARP IP.

[Mark]

I'm not quite sure how to get this across... Perhaps my poor tech vocabulary will not get in the way...

My network will, in the short term, have two providers... One with one and growing to at least 3 gateways in physically diverse locations and two gateways for the other provider.

Initially, one provider will simply be statically routed, and supply bandwidth to a mere handful of hosts. This is my current SOLE provider, and I am moving most of my traffic away from him.

The other, will provide me with a private ASN, and I will announce to him via BGP, which subnets to route to which gateways.

This all seems and is relatively straightforward. However, should one gateway go down, or a backhaul connected to this gateway, it is not a matter of simply re-routing internally, but a matter of tranferring announced networks to another gateway, as there's really no way to squeeze enough bandwidth through each/any of the backhauls to remain fully functional. BGP alone has no idea if my internal network reconfigures via failure, or execessively loaded link, so that's what OSPF or OLSR should do.

A bit further down the road - along the lines of 6 to 12 months, I will add yet more gateways and possibly a 3rd provider...again, in physically diverse locations, with multiple paths from and to each gateway to various points on the network.

In the end, I will have ~ 5 gateways running BGP, each with 1 to 3 links to various parts of the network.

This being the case, I really DO need to be able to dynamically update BGP's announced networks at each gateway.

BTW, I have a SWIP'd /23 from my newest provider and 2 /24's from the old one, one of which I'm giving back.

Forgive my impertinence here, but this seems to require either OLSR or OSPF to keep this network up and reasonably functional. If I merely reconfigure the internal routing, I could end up totally swamping one long distance, low capacity backhaul with highly roundabout routing, rather than just transferring routing to a more capable gateway/backhaul combination. Many of my sites have or will have narrow channel redundant links to them to other parts of the network, and these cannot carry enough to be 'failover' routing internally. At least not in some locations.

BTW, bandwidth at ALL locations will be 100Mbit ethernet, and the provider has it all available, with just 10 to 14ms latency to the carrier hotel in Seattle.

Further, there will be some higher latency, lower bandwidth backup connections in physically diverse locations, as well... again, BGP needs to announce changes to my provider(s) that reflect my internal connectivity.

[DrLove73]

I failed to understand your actual question/problem. What is your exact concern?

[tog]

I can't really provide much in the way of expert BGP advice, if you're going to announce a /23, I'm not sure how you'd get quagga's bgpd to announce or stop announcing that /23 based on what's going on with your IGP. A straight simple redistribute routes from kernel (plus proper filters for bgpd so you only announce what you're supposed to...) wouldn't really be the answer since your IGP isn't going to have one route for the /23, it's most likely just going to have smaller networks inside the /23.

[Beebe]

Several issues here - I hope I can get my head around them since I've had a few drinks...

1. BGP normally only advertises /24 or larger blocks in order to keep the Internet routing table below a certain size (what 256Mb or something these days?) filtered by your upstream provider.

2. OLSR doesn't interface with BGP.

3. OSPF does interface with BGP.

So if you have a larger than /24 - say a /23 then you could have one half of the /24s on one end of the network with one provider, and the other half of the /24s on the other end of the network with the other provider. Then you could use OSPF routing over the network.

You could in theory have a tower hit by lightning / tornado/ power outage in the middle of your network and have it only effect that one tower and all of the others find and route to and from the Internet through whichever gateway it can reach.

This is not possible with OLSR because it doesn't talk with BGP. If you loose a link in the middle of your network, BGP would be unaware of it and it would still be advertising ALL of your class C blocks - even the ones it can no longer route packets to.

I hope this makes sense. Otherwise I might be able to explain it better tomorrow - or see the error in my ways.

Thanks,
Roger

[Mark]

Ok, we're on the same wavelength then.

As far as advertising small blocks... please note, that for t he moment, my provider and I will use a PRIVATE ASN, and my routes are only broadcast to him. Nobody else.

[Beebe]

Aha! I'm using diverse providers, so I don't have that luxury. I guess you're stuck with OSPF instead of OLSR?

I'm also finding a problem with the bridging. I wanted to do lonnie's suggestion of running VDS tunnels back to the NOC. But that's kind of inefficient when it comes to BGP through diverse providers. Traffic might end up coming in through one NOC then traversing my backbone to the other NOC where the VDS server is, before traversing the backbone again to get to the client. Also it wouldn't fail-over should I loose a tower. Only option would be to put a server at each tower, but that is impractical due to cost/power/AC/security concerns. And you loose the ability of the saved IP addresses since you end up with bunches of public subnets everywhere again.

There are so many good solutions to solve certain problems, but you always end up sacrificing something else. I've been pushing to get my network multi-homed with my own IP space for years and there's always something stopping me.

I guess my dream of having no single point of failure and an extremely scalable network will have to remain just a dream?

Thanks,
Roger

[Beebe]

Sorry, I have been reading the thread as it developed and I just read over the whole thread again and i'd missed quite a few things. I'll do a bit more studying.

Thanks,
Roger