Redundantie en loadbalancing tussen 2 ISP's

[Verwijderd]

Hoi ik heb een vraag. Ik ben bezig met een om te onderzoeken of er redelijk snel een redundante verbinding naar 2 ISP kan worden gerealiseerd met een switched/router infrastructuur. De bedoeling is dat als één ISP down gaat de router automatisch verder gaat op de 2e. Of wat nog beter is, dat er geloadbalanced kan worden tussen de twee ISP's. Als ik hier over nadenk, denk ik meteen aan HSRP of GLBP. Echter zover als ik weet kun je daarmee alleen zien of een bepaalde interface down is. Je kunt volgens mij niet inzien als er een probleem aanwezig is bij de ISP.

Dus mijn vraag is nu, is er een redelijk eenvoudige manier om dit te realiseren voor zowel inkomend en uitgaan verkeer naar de twee ISP's? Zo ja, in welke richting moet ik dan zoeken? Het moet overigens een Cisco oplossing worden. Het is niet de bedoeling dat er BGP wordt gebruikt.

Alvast bedankt!

[ Voor 3% gewijzigd door Verwijderd op 06-07-2012 08:22 ]

[Exhar]

Met Cisco's kan je gebruik maken van IP SLA (google is your friend) waarbij je veel meer kan dan alleen kijken of een interface up/down is.

HSRP of GLBP is om loadbalancing of redundantie tussen je eigen 2 routers te krijgen.

[Verwijderd]

Exhar schreef op vrijdag 06 juli 2012 @ 08:36:
Met Cisco's kan je gebruik maken van IP SLA (google is your friend) waarbij je veel meer kan dan alleen kijken of een interface up/down is.

HSRP of GLBP is om loadbalancing of redundantie tussen je eigen 2 routers te krijgen.

Ik ben op de hoogte van IP SLA, alleen ik twijfel of het de volledige lading dekt van de problemen die bij een ISP kunnen voorkomen.

En wat het HSRP en GLBP verhaal. Het is natuurlijk niet de bedoeling dat de router naar het Internet een single point of failure is.

[ Voor 12% gewijzigd door Verwijderd op 06-07-2012 08:58 ]

[crazymonkey87]

GLBP is hier perfect voor... heb ik ook toegepast bij een kleine luchtvaartmaatschappij op de Carribean.. config is peanuts...

Load Sharing
You can configure GLBP in such a way that traffic from LAN clients can be shared by multiple routers, thereby sharing the traffic load more equitably among available routers.

[crazymonkey87]

GLBP creeert een virtuele router bijvoorbeeld 192.168.1.254 op welke beide routers bereikbaar zijn middels de loadbalancing weight die je hebt ingesteld...
Je fysieke routers behouden tevens hun (R1)192.168.1.253 en (R2)192.168.1.252 adres..
Dus hoezo single point of failure?

Verwijderd schreef op vrijdag 06 juli 2012 @ 08:53:
[...]


Ik ben op de hoogte van IP SLA, alleen ik twijfel of het de volledige lading dekt van de problemen die bij een ISP kunnen voorkomen.

En wat het HSRP en GLBP verhaal. Het is natuurlijk niet de bedoeling dat de router naar het Internet een single point of failure is.

[Paul]

Wil je uitgaand verkeer loadbalancen (dus het internetten door de werknemers) of het binnenkomende verkeer (e-mail, thuiswerkers, eventuele websites)? Dat maakt namelijk een groot verschil.

Die eerste kun je met alle multi-WAN-routers wel oplossen; eventueel nog instellen dat ze niet alleen kijken naar hun eigen gateway maar bijvoorbeeld ook de DNS-server van je provider pingen. Over het algemeen doen wij dat soort dingen met pfSense; aangezien je toch maar één kabelmodem of ADSL-modem per verbinding hebt (als het om zo'n verbinding gaat) hoef je niet eens per se meerdere ip-adressen van je provider te hebben (al is dat uiteraard wel beter omdat je dan het modem in bridge kunt zetten en geen NAT-over-NAT krijgt).

Inbound is lastiger en vergt bij mijn weten medewerking van je internetprovider

[Verwijderd]

nbnmaster schreef op vrijdag 06 juli 2012 @ 09:05:
GLBP creeert een virtuele router bijvoorbeeld 192.168.1.254 op welke beide routers bereikbaar zijn middels de loadbalancing weight die je hebt ingesteld...
Je fysieke routers behouden tevens hun (R1)192.168.1.253 en (R2)192.168.1.252 adres..
Dus hoezo single point of failure?


[...]

Nee ik bedoelde daarmee dat er wel GLBP nodig is om geen single point of failure te creëren. Ik dacht dat je bedoelde dat GLBP niet nodig was

Paul schreef op vrijdag 06 juli 2012 @ 09:15:
Wil je uitgaand verkeer loadbalancen (dus het internetten door de werknemers) of het binnenkomende verkeer (e-mail, thuiswerkers, eventuele websites)? Dat maakt namelijk een groot verschil.

Die eerste kun je met alle multi-WAN-routers wel oplossen; eventueel nog instellen dat ze niet alleen kijken naar hun eigen gateway maar bijvoorbeeld ook de DNS-server van je provider pingen. Over het algemeen doen wij dat soort dingen met pfSense; aangezien je toch maar één kabelmodem of ADSL-modem per verbinding hebt (als het om zo'n verbinding gaat) hoef je niet eens per se meerdere ip-adressen van je provider te hebben (al is dat uiteraard wel beter omdat je dan het modem in bridge kunt zetten en geen NAT-over-NAT krijgt).

Inbound is lastiger en vergt bij mijn weten medewerking van je internetprovider

Ik ben op de hoogte dat voor nieuw inkomend verkeer het een ander verhaal is. Met name omdat elke ISP hun eigen subnetten heeft die vaak alleen door de ISP gerouteerd worden. Dus als je een bepaald adres hebt ingesteld voor bijvoorbeeld een VPN concentrator of een website zal deze niet voor beide connecties aanwezig zijn.

Ik zat er aan te denken om dit op te lossen met DNS om een record te maken van beide adressen. Echter het probleem is dat zon failover enkele uren kan duren en dat ISP's vaak niet blij zijn als je deze failover tijd verlaagd.

Ik denk daarom dat een dergelijke oplossing veels te complex en duur wordt voor de klant als deze ook gebruik wil maken van nieuw inkomend verkeer van de ISP af.

[ Voor 60% gewijzigd door Verwijderd op 06-07-2012 09:41 ]

[Predator]

Het probleem met GLBP is dat er meestal wel iets L3 (firewall of L3 switch) tussen de clients en de routers zit.
Daardoor is er eigenlijk maar 1 client die rechtstreeks praat met de GLBP nodes, en er dus van die loadbalancing weinig in huis komt.

[Rolfie]

Ik denk daarom dat een dergelijke oplossing veels te complex en duur wordt voor de klant als deze ook gebruik wil maken van nieuw inkomend verkeer van de ISP af.

Dit hangt voor een gedeelte af van de applicaties die je hiervoor gebruikt.

Email: gaat via MX records. Kan je dus gemakkelijk verdelen over meerdere ISP.
VPN: Afhankelijk van de VPN type kan je vaak meerdere hosts / falback servers opgeven.
HTTP verkeer, dat gaat niet echt lukken, om dit gemakkelijk te doen.

[Bl@ckbird]

Er zijn verschillende manieren waarmee je dit kan oplossen.

Op de ASA heb je niet wat Dual ISP heet.
ASA pingt een IP adres (Bijvoorbeeld de DNS server van de ISP.)
Is dit IP adres onbereikbaar, dan wordt de verbindin omgezet naar ISP nummer 2.
http://www.cisco.com/en/U..._static.html#wpmkr1124422

Op de routers heet dit Enhanced Object Tracking:
http://www.cisco.com/en/U...n/guide/ipapp_eot_xe.html

Dit zijn active / standby oplossingen.
Wil je loadbalancen over meerdere links, dan zijn er andere oplossingen.

Met Policy Based Routeing kan je aangeven welk verkeer je over welke link naar buiten wil hebben.
Bijvoorbeeld web verkeer via ISP A, mail via ISP B.
http://www.cisco.com/en/U...per09186a00800a4409.shtml

Met Optimized Edge Routing (OER) of Cisco Performance Routing (PfR) kan je op basis van bepaalde parameters verkeer een bepaalde link opsturen.
Parameters kunnen bijvoorbeeld latency of beschikbare bandbreedte zijn.
http://www.cisco.com/go/pfr

Deze opties gelden allemaal voor outbound verkeer wat je organisatie verlaat richting het Internet.
Een host op het Internet weet niet welke link je gebruikt voor inbound verkeer. Bij grotere omgevingen neemt de ISP je netwerk dan op in hun routingprotocol wat ze gebruiken. (Multihoming BGP bijvoorbeeld.) Je hebt dus support van je ISP nodig.

Een andere optie is dat je een overlay netwerk bouwt. Je hab dan ergens rackspace nodig in de datacenter.
Hier hang je een router neer met security IOS. Met Dynamic Mulipoint VPN (DMVPN) kan je twee IPSec tunnels bouwen die over veschillende links van verschillende ISP's binnen komen.
Onder water gebruikt DMVPN EIGRP om dynamisch tunnels op te zetten.
http://www.cisco.com/en/U...ata_sheet_c78-468520.html

Een andere oplossing van een overlay netwerk is LISP routing. Hiermee kan je multihoming inrichten, maar LISP routing is nog wel redelijk beta. Ook hiervoor heb je een router in een centraal datacenter nodig wat zich als mapping server voordoet. Zou je LISP draaien op een mobiele telefoon, dan hoef je nooit meer van IP adres te wisselen. (Ongeacht de provider die je gebuikt.) LISP kan je ook gebruiken voor IPv4 naar IPv6 migraties.
http://lisp4.cisco.com/lisp_over.html

[Verwijderd]

Rolfie schreef op vrijdag 06 juli 2012 @ 12:49:
[...]

Dit hangt voor een gedeelte af van de applicaties die je hiervoor gebruikt.

Email: gaat via MX records. Kan je dus gemakkelijk verdelen over meerdere ISP.
VPN: Afhankelijk van de VPN type kan je vaak meerdere hosts / falback servers opgeven.
HTTP verkeer, dat gaat niet echt lukken, om dit gemakkelijk te doen.

En hoe zit dat met VOIP?

@Bl@ck

Thx voor de info ik zal dat eens even doorzoeken.

[ Voor 6% gewijzigd door Verwijderd op 06-07-2012 15:12 ]

[tlpeter]

Verwijderd schreef op vrijdag 06 juli 2012 @ 15:10:
[...]

En hoe zit dat met VOIP?

Dat ligt aan hoe dit nu geregeld is.
Goedkope (huis tuin en keuken) providers gaan "gewoon" via het internet en zullen dan wel blijven werken.
De meeste providers regelen een eigen verbinding en dan zul je dit met de provider van de sip trunk moeten regelen.

[ACM]

Rolfie schreef op vrijdag 06 juli 2012 @ 12:49:
Email: gaat via MX records. Kan je dus gemakkelijk verdelen over meerdere ISP.

SMTP gaat via MX records, maar imap en andere mailleesprotocollen niet.

HTTP verkeer, dat gaat niet echt lukken, om dit gemakkelijk te doen.

Met een GSLB-opstelling kan dat prima hoor. Althans, hier bij Tweakers.net werkt dat goed. Maar als je daar een extra stel loadbalancers voor moet kopen kan het uiteraard wel in de papieren lopen afhankelijk van de vereiste sla's, support en hoeveelheid verkeer.

[BHQ]

ACM schreef op zaterdag 07 juli 2012 @ 10:15:
[...]

SMTP gaat via MX records, maar imap en andere mailleesprotocollen niet.

Yup. Lazy man's: Dynamische DNS gebruiken voor je domein en van binnenuit laten bijwerken. DynDNS is bijv. erg snel.

+1 voor pfSense hier overigens.

[MagicTempest]

Wat is eigenlijk de reden dat er geen BGP gebruikt mag worden? Mocht je eigen PI (Provider Independent) space hebben dan is dat ideaal om redundant aangesloten te worden. Dan hoef je verder ook niet moeilijk te doen. Het enige wat nu misschien lastig zal worden is het krijgen van PI space.

[Verwijderd]

MagicTempest schreef op dinsdag 10 juli 2012 @ 13:18:
Wat is eigenlijk de reden dat er geen BGP gebruikt mag worden? Mocht je eigen PI (Provider Independent) space hebben dan is dat ideaal om redundant aangesloten te worden. Dan hoef je verder ook niet moeilijk te doen. Het enige wat nu misschien lastig zal worden is het krijgen van PI space.

Omdat wij ook support op het netwerk moeten leveren. Aangezien de kennis van BGP bij ons matig is, hebben we besloten om dit protocol ook niet te gebruiken bij klanten. Wij zitten met onze kennis meer op het LAN gedeelte.

[JMW761]

Verwijderd schreef op dinsdag 10 juli 2012 @ 14:49:
[...]


Omdat wij ook support op het netwerk moeten leveren. Aangezien de kennis van BGP bij ons matig is, hebben we besloten om dit protocol ook niet te gebruiken bij klanten. Wij zitten met onze kennis meer op het LAN gedeelte.

je bedoelt dat jullie kennis meer layer2 focussed is, dan layer3?

De enige manier om dit "netjes" te doen, is via BGP. Dat is alleen in sommige gevallen niet mogelijk en dan kan je de truuks gebruiken welke kleine routers inmiddels ingebouwd hebben, zoals opgemerkt.

Je zou ook met een private AS kunnen werken, je blijft alleen idd. die PI-space nodig hebben.

voip koppel je af op een SIP-trunk/IAX , dus als die connectie gewoon de change(refresh tijd van de connectie) opmerkt en zichzelf opnieuw verbind gaat dat automatisch.

[ Voor 0% gewijzigd door JMW761 op 13-07-2012 10:24 . Reden: het is IAX ipv AIX ]

[overhyped]

JMW761 schreef op vrijdag 13 juli 2012 @ 10:20:
[...]


je bedoelt dat jullie kennis meer layer2 focussed is, dan layer3?

De enige manier om dit "netjes" te doen, is via BGP. Dat is alleen in sommige gevallen niet mogelijk en dan kan je de truuks gebruiken welke kleine routers inmiddels ingebouwd hebben, zoals opgemerkt.

Je zou ook met een private AS kunnen werken, je blijft alleen idd. die PI-space nodig hebben.

voip koppel je af op een SIP-trunk/IAX , dus als die connectie gewoon de change(refresh tijd van de connectie) opmerkt en zichzelf opnieuw verbind gaat dat automatisch.

Voor kleine organisaties is een bgp setup met pi space e.d. helemaal geen optie. Je krijgt geen PI space blok dat groot genoeg is om zelf routeerbaar te zijn, laat staan dat je de kennis hebt om zo iets te ondersteunen. (zoals TS al heel terecht aangaf)

Wat kan je wel doen:

1: zorg er voor dat al je zaken die van buiten af benaderbaar zijn bij een hoster staat die zulke zaken geregeld heeft. Je wil je hier niet druk om maken.

2: Als je toch denkt dat je het zelf wilt regelen: Zoek een ISP die dit voor je aanbied. Ga niet zelf te veel rommelen en je krijgt 't niet beter voor elkaar dan de ISP.

[StarWing]

Kijk ook eens naar watchguard appliances, wij gebruiken deze en dit werkt perfect voor 2 isp's. We laten er zelfs onze VPN's door lopen. Valt er 1 isp uit, schakelt de firewall over naar de ingestelde backup lijn.

[CyBeR]

overhyped schreef op maandag 16 juli 2012 @ 21:04:
[...]


Voor kleine organisaties is een bgp setup met pi space e.d. helemaal geen optie. Je krijgt geen PI space blok dat groot genoeg is om zelf routeerbaar te zijn, laat staan dat je de kennis hebt om zo iets te ondersteunen. (zoals TS al heel terecht aangaf)

Ten eerste: als je PI space krijgt, krijg je genoeg om te routeren. Minimaal een /24 dus.

Ten tweede: PI space is helemaal niet nodig en zelfs af te raden. Een blokje van een grotere isp z'n PA space is veel handiger. De meeste ISPs die BGP peerings aangaan met klanten vinden het ook vrij normaal dat jij een stukje van hun PA space adverteert bij jouw andere transits. Voordeel: die paar netwerken die advertisements van kleinere netwerkjes (/24 dus, daarom is PI onhandig) filteren, komen via de aggregated route van je provider toch nog bij jou uit.

[MagicTempest]

CyBeR schreef op maandag 16 juli 2012 @ 22:16:
[...]


Ten eerste: als je PI space krijgt, krijg je genoeg om te routeren. Minimaal een /24 dus.

Ten tweede: PI space is helemaal niet nodig en zelfs af te raden. Een blokje van een grotere isp z'n PA space is veel handiger. De meeste ISPs die BGP peerings aangaan met klanten vinden het ook vrij normaal dat jij een stukje van hun PA space adverteert bij jouw andere transits. Voordeel: die paar netwerken die advertisements van kleinere netwerkjes (/24 dus, daarom is PI onhandig) filteren, komen via de aggregated route van je provider toch nog bij jou uit.

Wij zijn overgegaan naar PI space juist omdat KPN het niet toestond dat wij hun PA space adverteerden via Tele2. Tele2 zelf vond het overigens geen enkel probleem.

[CyBeR]

Mijn ISP vindt dat ook geen probleem inderdaad, maar KPN is op veel fronten een ander verhaal

[overhyped]

CyBeR schreef op maandag 16 juli 2012 @ 22:16:
[...]


Ten eerste: als je PI space krijgt, krijg je genoeg om te routeren. Minimaal een /24 dus.

Ten tweede: PI space is helemaal niet nodig en zelfs af te raden. Een blokje van een grotere isp z'n PA space is veel handiger. De meeste ISPs die BGP peerings aangaan met klanten vinden het ook vrij normaal dat jij een stukje van hun PA space adverteert bij jouw andere transits. Voordeel: die paar netwerken die advertisements van kleinere netwerkjes (/24 dus, daarom is PI onhandig) filteren, komen via de aggregated route van je provider toch nog bij jou uit.

Ten eerste: Die klopt niet: Vorig jaar heb ik nog voor een groot bedrijf PI space aangevraagd. Ik heb moeten vechten en smeken voor een /24. Een en /25 en een /26 pas precies genoeg, en de ripe policy is dat je precies genoeg krijgt. De routeerbaarheid is geen besliscriterium voor riep bij allocatie! Ripe kan dus prima minder uitgeven, dat jij 't niet gerouteerd krijgt is jouw probleem.

Ten tweede: Het is ondersteunt als de provider een route opbject wil aanmaken in de ripe database. Dat zijn er een stuk minder dan degene die zeggen: Veel plezier en succes er mee.

Zeker met de toegenomen interesse in route origin validation wil je niet bij een nieuwe setup beginnen met niet gevalideerde advertisements. Het werkt wel, voor nu, maar op den duur gaan gingen hard fout. niet iets waar je

De praktijk is dat een /24 overal doorheen komt, als het maar een "legale" /24 is. (apnic geeft nu alleen nog maar /24's uit omdat die al in de emergency /8's zitten, en wij maar blijven roepen dat ipv6 niet nodig is, maargoed, andere discussie )

[CyBeR]

overhyped schreef op dinsdag 17 juli 2012 @ 14:42:
[...]

Ten eerste: Die klopt niet: Vorig jaar heb ik nog voor een groot bedrijf PI space aangevraagd. Ik heb moeten vechten en smeken voor een /24. Een en /25 en een /26 pas precies genoeg, en de ripe policy is dat je precies genoeg krijgt. De routeerbaarheid is geen besliscriterium voor riep bij allocatie! Ripe kan dus prima minder uitgeven, dat jij 't niet gerouteerd krijgt is jouw probleem.

Hmm. Het stond me bij dat de minimum PI allocation een /24 was, net zoals de minimum PA allocation (nu nog) een /21 is. Maar ik kan dat niet meer vinden. Mischien is 't veranderd of had ik 't verkeerd onthouden.

Ten tweede: Het is ondersteunt als de provider een route opbject wil aanmaken in de ripe database. Dat zijn er een stuk minder dan degene die zeggen: Veel plezier en succes er mee.

Zoals ik al zei: je moet een isp vinden die er welwillend tegenover staat. Kleinere ISPs zoals colo-toko's (True, ReasonNet, PCExtreme, NXS, dat soort verhalen) zijn dat meestal wel.

[Verwijderd]

Over wat voor omgeving praten we eigenlijk? Het maakt nogal verschil of je een Cisco omgeving optuigt, of dat je het afkan met een dual WAN linux gateway op een servertje dat nog ergens stof loopt te happen.

[vliegjong]

Kijk ook eens naar een F5 Linkcontroller.
Dit is een product welke hiervoor specifiek gebouwd is en kan alles wat je wilt.

[SubSoNick]

Niet de goedkoopste oplossing maar heb goede ervaringen met Microsoft TMG.
Doet alles waar je naar op zoek bent (en nog veel meer).

[xares]

overhyped schreef op dinsdag 17 juli 2012 @ 14:42:
[...]

Ten eerste: Die klopt niet: Vorig jaar heb ik nog voor een groot bedrijf PI space aangevraagd. Ik heb moeten vechten en smeken voor een /24. Een en /25 en een /26 pas precies genoeg, en de ripe policy is dat je precies genoeg krijgt. De routeerbaarheid is geen besliscriterium voor riep bij allocatie! Ripe kan dus prima minder uitgeven, dat jij 't niet gerouteerd krijgt is jouw probleem.

Kleiner als een /24 PI geeft RIPE echt niet uit. Waarom zouden ze deze uitdelen als je er niks aan hebt?
Vrijwel alle partijen filteren met BGP alles eruit wat kleiner is als een /24.

[Verwijderd]

Enige tijd geleden heb ik zelf gekeken voor een werkgever naar een Peplink loadbalancer.
Op het gebied van de benodigde specifiacties voldeed deze loadbalancer prima. (Peplink A380)
Tevens was de website van de fabrikant erg overzichtelijk en open op het gebied van technische informatie.
Bij andere grote merken moest je voor specifieke informatie een abbo nemen. (beetje een scheve wereld in mijn ogen, Support op hardware(configuratie) krijg je mits je ervoor betaald..

[overhyped]

xares schreef op zondag 22 juli 2012 @ 13:59:
[...]


Kleiner als een /24 PI geeft RIPE echt niet uit. Waarom zouden ze deze uitdelen als je er niks aan hebt?
Vrijwel alle partijen filteren met BGP alles eruit wat kleiner is als een /24.

Wanneer heb jij voor het laatst een aanvraag PI space gedaan? Op een plek waar je minder dan een /24 echt in gebruik had? Ik vorig jaar. Zoals eerder in dit topic aangeven: Het heeft me veel moeite gekost om uiteindelijk die /24 te krijgen. Puur qua adressering was een /25 en een /26 voldoende (net geen /24 dus) dat was dus ook wat ik in eerste instantie zou gaan krijgen.

Nogmaals: routeerbaarheid is geen criterium voor het toewijzen van ip space.