Twee verschillende netwerken op 1 server?

[Verwijderd]

Op een server in het datacentrum heb ik nu twee verschillende uplinks. Dit omdat ik geen IP's meer bij één provider kon krijgen en de klant bereid is te betalen voor de additionele IP-adressen.

Hierdoor is het interessant geweest om de UTP-kabel van een andere provider ook aan de server te hangen, maar ik ben gisteren 45 minuten bezig geweest en heb het maar niet werkend gekregen.

Is het uberhaupt mogelijk om 2 verschillende uplinks van verschillende providers te hebben op één server?

[Osiris]

Waarom zou het niet mogelijk zijn?

[Zwelgje]

hangt er vanaf wat voor server het is

Windows based dan zou je eens kunnen kijken naar: http://blogs.technet.com/...p-redundancy-feature.aspx

[CyBeR]

Kan prima. Op het moment dat een van de twee netwerken filtert op source address of er NAT toegepast wordt moet je wel al in je server policy routing toepassen zodat je, gebaseerd op source adres, de goede verbinding en route uitkiest.

[TrailBlazer]

Het is routing technisch nogal lastig om dit voor elkaar te krijgen. Je server zal altijd de default gateway gebruiken om het verkeer neer waar buiten te sturen. Je krijgt hierdoor asymetrisch verkeer. Provider A ziet nu dat jij verkeer stuurt met als source een adres van Provider B. Dit zal hij zien als spoofing en het vrolijk droppen. Ik zie niet in hoe je dit op kan lossen behalve dat je op een router ervoor een source nat doet zodat je makkelijker met statische routes de goede next-hop kan bepalen.

[Verwijderd]

Uptime is belangrijk, waardoor ik heb gekozen voor Linux. Het verkeer zal inderdaad asymetrisch zijn.

Het schijnt inderdaad te moeten via een routing table, wordt waarschijnlijk veel documentatie lezen.

[CyBeR]

Verwijderd schreef op vrijdag 05 februari 2010 @ 19:49:
Uptime is belangrijk, waardoor ik heb gekozen voor Linux. Het verkeer zal inderdaad asymetrisch zijn.

Het schijnt inderdaad te moeten via een routing table, wordt waarschijnlijk veel documentatie lezen.

Had dat er meteen bijgezegd. Met linux is 't namelijk heel simpel. Overigens is wat TrailBlazer zegt gedeeltelijk waar, onder voorwaarde dat je geen policy routing doet (wat je gaat doen) en dat je een ISP hebt die filtert, wat de meeste colo-isp's niet doen. Verder is asymmetrische routing helemaal geen big deal, op 't internet is dat zelfs zo'n beetje de norm.

Policy routing in linux doe je als volgt. Je hebt er 'iproute2' voor nodig en 't is alleen fatsoenlijk te doen met statische ip's of maximaal één dhcp interface. Ik heb dhcpd nog niet wijs weten te maken dat 'ie een bepaalde routing tabel moet gebruiken.

code:

ip route add 1.2.3.0/24 dev eth1
ip route add default 1.2.3.1 dev eth1  table 100

ip rule add prio 100 from 1.2.3.0/24 table 100
ip route flush cache

Wat je doet is een extra routing tabel aanmaken, nummer 100. Vervolgens gebruik je 'ip rule' om afhankelijk van 't gebruikte source-adres die routetabel te gebruiken in plaats van de normale routetabel. Dus die routetabel moet alle routes hebben die belangrijk zijn.

[ Voor 4% gewijzigd door CyBeR op 05-02-2010 21:49 ]

[Osiris]

TrailBlazer schreef op vrijdag 05 februari 2010 @ 17:57:
Het is routing technisch nogal lastig om dit voor elkaar te krijgen. Je server zal altijd de default gateway gebruiken om het verkeer neer waar buiten te sturen. Je krijgt hierdoor asymetrisch verkeer. Provider A ziet nu dat jij verkeer stuurt met als source een adres van Provider B. Dit zal hij zien als spoofing en het vrolijk droppen. Ik zie niet in hoe je dit op kan lossen behalve dat je op een router ervoor een source nat doet zodat je makkelijker met statische routes de goede next-hop kan bepalen.

Hoe je dat moet doen? Nou, simpel, zoals al eerder soort van gezegd door CyBeR: source-based routing.

Zo heb ik 4 IPv6-tunnels naast elkaar draaien: XS4ALL, Scarlet, Concepts ICT en Surfnet. Zonder source-based routing gingen alle ICMPv6-reply-packets inderdaad via de default gateway (en bijbehorende tunnel) van XS4ALL. Ongewenst uiteraard.

Echter, als bijvoorbeeld een IP van Concepts ICT als destination gepinged werd, werd dat IP ook als source gebruikt. En je kunt Linux probleemloos op basis van source-IP laten routen. `ip -6 rule help`

[CyBeR]

Osiris schreef op vrijdag 05 februari 2010 @ 21:57:
[...]

Hoe je dat moet doen? Nou, simpel, zoals al eerder soort van gezegd door CyBeR: source-based routing.

Bijna. Source-based routing is dan weer iets anders* Namelijk dat de source aangeeft hoe een packet geroute moet worden. Daar zijn extra IP headers voor. Maar dat wordt eigenlijk niet of nauwelijks gebruikt. Het benodigde principe heet policy routing, en de policy is dan in dit geval gebaseerd op het source adres (maar dat hoeft niet; 't kan net zo goed de destination address zijn, een tcp poort, etc.)

*) klik: http://www.gweep.net/~crimson/network/lsrr.html

[ Voor 4% gewijzigd door CyBeR op 05-02-2010 22:20 ]

[joopv]

Ik ken het tweakers/hosting wereldje niet zo erg goed, maar in de professionele netwerking wereld is het 'not done' om ip routerings functies op hosts (servers, werkstations) te gebruiken.

Routering hoort in het netwerk te zitten. op apparatuur die daarvoor gemaakt is (vrijwel iedere professionele router werkt met dedicated packet forwarding hardware), en niet op de 'gebruikers' van het netwerk. Die horen alleen een ip /netmask/gateway/dns adres te hebben en alles wat niet lokaal is af te leveren bij hun gateway.

Van de oplossingen die hier aangedragen worden knijp ik m'n tenen bij elkaar... asymmetrische routering kan b.v. leiden tot flooding en dat heeft hele nare security implicaties. Policy based routing is een beheers nachtmerrie. BGP is the way to go...

Maar misschien heb ik gewoon teveel ellende meegemaakt van wintel systeembeheerders die te weinig van IP begrepen om de implicaties van wat ze aan het doen waren te begrijpen...

[CyBeR]

Van elke server die meerdere aparte internetverbindingen heeft direct een BGP router maken is ook weer het andere uiterste (en helpt bovendien niet in dit geval). Er is geen andere manier om dit geintje uit te halen dan de lokale routing van de host te beinvloeden. En dat is wat hier gebeurt met policy routing: 'als source adres A dan stuur naar default gateway A, anders naar default gateway B'.

[Verwijderd]

Het is inderdaad gelukt met de "iproute2"-package
http://www.linuxfoundatio...roups/networking/iproute2

Ik kan dit moeilijk toelichten, omdat ik het werk niet zelf heb uitgevoerd.