Routeren over een redundant link

[Boudewijn]

Hoihoi,


Ik ben bezig met een klusje, waarbij ik data over een netwerk wil transporteren (jaja ).
Echter, bestaat het medium hier uit 2 wireless links, die verder niet zo relevant zijn voor mijn project.

Ik wil aan de beide endpoints van deze wireless links een simpele doos neerzetten met OpenBSD (of FreeBSD, of Linux, maar OpenBSD is wel lekker makkelijk ivm security en pf).
Deze dozen wil ik de data laten routeren over beide wireless links, zolang beide links up zijn.
Zo niet, dan maar over 1 link.

Op zich zou ik hier een en ander kunnen met UCARP, maar dit regelt alleen de redundancy voor me.
Vliegt link-1 er uit, dan wordt link-2 gebruikt. Op zich is dat een goede oplossing, echter wil ik nu 2 dingen anders doen:

1. Ik wil op elk endpoint maar 1 doosje neerzetten. Dus netto 2 doosjes in het hele systeem.
2. Ik wil als beide links up zijn, de bandbreedte van beide combineren.

Weet iemand een mooie methode om dit te doen?

Ik wil hiervoor trouwens 2 soekris-achtige doosjes gaan gebruiken.


Mijn eigen idee was UCARP, maar volgens mij kan deze de bandbreedte niet bundelen.
'gewoon' routeren lijkt me lastig om te doen, zeker als je de load over beide wireless links een beetje gelijk wil houden.

[burne]

Boudewijn schreef op maandag 03 november 2008 @ 23:52:
maar volgens mij kan deze de bandbreedte niet bundelen.

Dus zul je een protocol moeten gebruiken wat wel iets snapt van bandbreedtes en beschikbaarheid van links. OSPF is het meest gebruikte protocol voor dit soort dingen. Google zegt dat het in een soekris te vinden is, dus dat moet je niet tegenhouden.

[Boudewijn]

Mja ik ga hier geen soekris, maar een soortgelijk bordje voor gebruiken.

Bedankt voor de tip voor het protocol; ik wilde het met OpenBSD toepassen (domweg omdat OpenBSD fijn is voor netwerkinfrastructuur).
Vond net deze link, en zal die eens doorlezen: http://www.openbsd.org/papers/linuxtag06-network/index.html

[CyBeR]

Aangezien 't point-to-point links zijn kun je mischien iets met channel bonding.

[UDuckling5]

Je hoeft toch niet per se ucarp te draaien op zo'n obsd trunk. Als het goed is kunnen die ook om-de-beurt loadbalancen.

[Boudewijn]

Als het goed is wel ja, maar waarmee? . Het gaat mij om de naam\techniek\daemon.
Ben me nu maar eens aan het inlezen in ospf.

[UDuckling5]

Ik ben niet zo'n held met 'Creatief met PF', maar ik meende dat het daarmee kan. Al heb ik er alleen over gelezen, en dat is al een tijd geleden.

Post je je oplossing als je het uiteindelijk vind?

[Verwijderd]

burne schreef op maandag 03 november 2008 @ 23:59:
[...]

Dus zul je een protocol moeten gebruiken wat wel iets snapt van bandbreedtes en beschikbaarheid van links. OSPF is het meest gebruikte protocol voor dit soort dingen. Google zegt dat het in een soekris te vinden is, dus dat moet je niet tegenhouden.

Naar mijn weten zorgt OSPF niet voor channel bonding. OSPF past alleen dynamisch je routing table aan.

[CyBeR]

Verwijderd schreef op dinsdag 04 november 2008 @ 18:23:
[...]


Naar mijn weten zorgt OSPF niet voor channel bonding. OSPF past alleen dynamisch je routing table aan.

Zoek 's op ECMP routing.

[Boudewijn]

UDuckling5 schreef op dinsdag 04 november 2008 @ 16:59:
Ik ben niet zo'n held met 'Creatief met PF', maar ik meende dat het daarmee kan. Al heb ik er alleen over gelezen, en dat is al een tijd geleden.

Post je je oplossing als je het uiteindelijk vind?

Uiteraard .

Verwijderd schreef op dinsdag 04 november 2008 @ 18:23:
[...]


Naar mijn weten zorgt OSPF niet voor channel bonding. OSPF past alleen dynamisch je routing table aan.

En waarom dan niet?

[Guru Evi]

Als je beide kanalen onder controle hebt kun je waarschijnlijk wel bonden (je ontvanger moet dan ook 2 draadloze netwerkkaarten hebben en beide kanten moeten bonding ondersteunen). Dat gaat enkel werken in point-to-point mode, niet in AP mode.

Als je SSID's wilt uitbreiden om meer coverage te krijgen dan kun je dat gewoon door een repeater te maken.

Kijk ook eens naar MeshBox

[Boudewijn]

Hardstikke leuk, maar dat wil ik niet.

Ik heb twee wireless links tussen 2 gebouwen (vermoed ik, ik kijk alleen of ik dit kan bouwen ).
Beide kanten hebben een eigen AP, dus in totaal 4 APs.
Nu wil ik deze 2 wireless links gewoon slim trunken, waarbij ook redundantie wordt behaald.

Hiervoor kan ik 2 appliances (pc-engines hardware, soort soekris. Als soekris echt veel beter is, is dat ook een optie) neerzetten; een aan elke kant van de links.

[axis]

Met pf zou dat moeten kunnen. Zelf geen ervaring mee, maar hier staat de uitleg: http://www.openbsd.org/faq/pf/pools.html#outgoing

Address pools can be used in combination with the route-to filter option to load balance two or more Internet connections when a proper multi-path routing protocol (like BGP4) is unavailable. By using route-to with a round-robin address pool, outbound connections can be evenly distributed among multiple outbound paths.

edit: bovenstaande impliceert dat loadbalancen ook kan met BGP (en daar heb ik al helemaal geen kaas van gegeten), hier nog wat handige info misschien: http://www.cisco.com/en/U...ple09186a00800945bf.shtml

Ik ga me er ook eens in inlezen.

[ Voor 23% gewijzigd door axis op 04-11-2008 22:02 ]

[GrooV]

Taadaaaaaaaa:

http://www.freebsd.org/do.../network-aggregation.html

En de PF firewall in FreeBSD is toch nagenoeg het zelfde als in die van OpenBSD?

quote: Freebsd MAN

HISTORY
The pf packet filtering mechanism first appeared in OpenBSD 3.0.

[ Voor 53% gewijzigd door GrooV op 04-11-2008 22:04 ]

[axis]

GrooV schreef op dinsdag 04 november 2008 @ 22:03:
Taadaaaaaaaa:

http://www.freebsd.org/do.../network-aggregation.html

En de PF firewall in FreeBSD is toch nagenoeg het zelfde als in die van OpenBSD?
[...]

Link aggregation is volgens mij hier niet van toepassing, da's echt een ethernet trunk, echt layer 2 spul.. (Werkt uitstekend trouwens, gebruik zelf ook een aantal LACP trunks met lagg).

En ja, de PF firewall is volgens mij identiek aan die van OpenBSD, alleen loopt ie in FreeBSD net altijd een beetje achter qua versie.

[Boudewijn]

True, maar ik zie niet echt voordeel in het gebruik van FreeBSD boven OpenBSD.
OpenBSD heeft de naam meer secure te zijn (komt ook wel door de wat kleinere set default installed packages verwacht ik) , en dat is wel een pre.
Het gaat mij met name om welke technieken\daemons te gebruiken, en dan kom ik zelf wss wel uit het OS.

[burne]

Verwijderd schreef op dinsdag 04 november 2008 @ 18:23:
Naar mijn weten zorgt OSPF niet voor channel bonding. OSPF past alleen dynamisch je routing table aan.

Dat beweer ik toch ook nergens? Het is aan je netwerk-stack om iets slims te doen met twee FIB-entries naar dezelfde bestemming met gelijke metric.

(Offtopic: ik heb vandaag m'n AS-nummer gekregen dus ga eens kijken hoe volwassen OpenBGPd is..)

[GrooV]

Boudewijn schreef op woensdag 05 november 2008 @ 00:05:
True, maar ik zie niet echt voordeel in het gebruik van FreeBSD boven OpenBSD.
OpenBSD heeft de naam meer secure te zijn (komt ook wel door de wat kleinere set default installed packages verwacht ik) , en dat is wel een pre.
Het gaat mij met name om welke technieken\daemons te gebruiken, en dan kom ik zelf wss wel uit het OS.

Uhm FreeBSD wordt veel meer gebruikt, heeft betere driver ondersteuning, is beter geschikt voor router taken. Als OpenBSD de "naam" heeft om meer secure te zijn maakt dat FreeBSD dan unsecure?

[axis]

Boudewijn schreef op woensdag 05 november 2008 @ 00:05:
True, maar ik zie niet echt voordeel in het gebruik van FreeBSD boven OpenBSD.
OpenBSD heeft de naam meer secure te zijn (komt ook wel door de wat kleinere set default installed packages verwacht ik) , en dat is wel een pre.
Het gaat mij met name om welke technieken\daemons te gebruiken, en dan kom ik zelf wss wel uit het OS.

Opzich maakt OpenBSD vs FreeBSD geen drol uit. Kort gezegd is de consensus dat FreeBSD sneller en makkelijker is, en OpenBSD meer secure. Maar aangezien je hier geen firewall hebt voor een bankinstituut, maakt dat in dit geval ook niet veel uit, beiden zijn secure. Dus kies gewoon de distro waar jij je prettig bij voelt

[Guru Evi]

Wat je zoekt is routing for multiple uplinks:

http://lartc.org/howto/lartc.rpdb.multiple-links.html Is voor linux maar je kunt het zelf aanpassen of iets vinden voor *BSD (maakt niet erg uit, gebruik wat je wilt, zorg dat het werkt voor jou en de services die je wilt aanbieden ondersteunt).

Je kunt inderdaad BGP of OSPF gebruiken maar dat maakt het onnodig complex. Als je tijd ervoor hebt, kun je er eens in kijken maar ik zou het gewoon scripten met ipfw en routes. Zie ook: http://www.openbsd.org/papers/linuxtag06-network.pdf

[Boudewijn]

GrooV schreef op woensdag 05 november 2008 @ 01:57:
[...]


Uhm FreeBSD wordt veel meer gebruikt, heeft betere driver ondersteuning, is beter geschikt voor router taken. Als OpenBSD de "naam" heeft om meer secure te zijn maakt dat FreeBSD dan unsecure?

Nee, maar vanuit mijn optiek is FreeBSD beter. Reden is voornamelijk een recentere PF en een spartaanser default systeem.

Even na het lezen van de pf docs, als ik de fec mode gebruik:

fec

Supports Cisco EtherChannel. This is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link, if the switch supports LACP then that should be used instead.

Balances outgoing traffic across the active ports based on hashed protocol header information and accepts incoming traffic from any active port. The hash includes the Ethernet source and destination address, and, if available, the VLAN tag, and the IPv4/IPv6 source and destination address.

Het is mij niet duidelijk of dit nog werkt als een van de links eruit vliegt.
Ik wil dus en trunking, en failover. fec is trunking, en failover is failover, maar doet fec ook failover? volgens mij niet namelijk.

[CyBeR]

Boudewijn schreef op donderdag 06 november 2008 @ 00:13:
[...]

Nee, maar vanuit mijn optiek is FreeBSD beter. Reden is voornamelijk een recentere PF en een spartaanser default systeem.

Even na het lezen van de pf docs, als ik de fec mode gebruik:

[...]


Het is mij niet duidelijk of dit nog werkt als een van de links eruit vliegt.
Ik wil dus en trunking, en failover. fec is trunking, en failover is failover, maar doet fec ook failover? volgens mij niet namelijk.

Fec is geen trunking. Fec is link aggregation. Dat is ook wat je wilt, niet trunking.

[Boudewijn]

True, maar hier http://www.freebsd.org/do.../network-aggregation.html
Lees ik heel weinig terug over failover.
Ik wil dus normaliter beide links gebruiken (dus met hogere snelheid dan met 1 link), maar als er een sneuvelt, maar 1.

Voglens mij doet fec dat niet.

[CyBeR]

Nou ja d'r zijn twee opties:

• Het OS en de andere kant hebben 't door, en gebruikt alleen de andere link: bandbreedte door de helft.
• Dat gebeurt niet, met als resultaat ruwweg 50% packet loss: bandbreedte ruwweg door de helft (ideaal geval, in de praktijk is 't wat anders.)

Als 't tweede het geval is gebruik je mischien beter LACP.

[ Voor 18% gewijzigd door CyBeR op 06-11-2008 00:53 ]