Likes Likes:  0
Resultaten 1 tot 6 van de 6
Geen
  1. #1
    Redundantie met L3 Switches en InterVLAN routing
    geregistreerd gebruiker
    462 Berichten
    Ingeschreven
    22/05/06

    Locatie
    Belgie

    Post Thanks / Like
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    26 Berichten zijn liked


    Ondernemingsnummer: 0812210395

    Thread Starter

    Redundantie met L3 Switches en InterVLAN routing

    Ik ben bezig met een een setup die gebruik maakt van L3 routing via een switch.
    Momenteel bestaat de uit een aantal (managable) desktop switches die verbonden zijn met één 24-poort L3 switch. Er zijn verschillende VLANs waar de L3 switch voor de routing tussen de VLANs zorgt. De switch heeft dus in elke VLAN een IP adres en dit IP wordt door de clients in die VLAN als gateway gebruikt. Dit werkt.

    Nu zou ik de setup redundant willen maken door een tweede L3 switch toe te voegen en elke desktop switch ook aan die hangen. RSTP zou dan de rest doen.

    Nu weet ik niet goed hoe ik dit moet aanpakken naar IP adressering toe. Even heel simpel voorgesteld, 3 VLANs, 1, 2 en 3. Subnet telkens 192.168.X.0/24 waar X overeenkomt met de VLAN. Switch 1 zit in elke VLAN op het IP adres 192.168.X.1. De clients krijgen dit adres als default gateway.

    Ik zou denken dat ik de tweede switch in elke VLAN zijn eigen IP adres moet krijgen, bv .2 achteraan.
    Als het actieve RSTP path van een desktop switch echter over switch 2 gaat, dan gaat traffiek dus via switch 2 naar switch 1 om daar pas geroute te worden naar de andere VLAN (want de client stuurt het pakket naar de default gateway, nl het VLAN IP van switch 1). Klopt dit, of weet switch 2 toch dat hij die routing mag/moet uitvoeren? Als die switch dat niet doet, dan heb ik volgens mij ook geen redundatie als switch 1 uitvalt, toch?

    Ik kan de clients uiteraard 2 gateways doorsturen via DHCP, maar die moeten volgens de DHCP in de volgorde worden gebruikt als ze in de DHCP vermeld staan. Alle traffiek wordt dus ook steeds eerste naar switch 1 gestuurd.

    Het enige wat ik daar voor zou kunnen bedenken is om de switches in alle VLANs (met uitzondering van management VLAN) hetzelfde IP adres te geven. Dit klinkt op het eerste zicht niet correct, maar aangezien binnen dezelfde VLAN enkel L2 traffiek tussen die 2 switches gaat, zie ik niet meteen in waarom dat niet zou werken.

    Iemand nog ideeën?

  2. #2
    Redundantie met L3 Switches en InterVLAN routing
    geregistreerd gebruiker
    1.554 Berichten
    Ingeschreven
    20/07/10

    Locatie
    's-Gravenhage

    Post Thanks / Like
    Mentioned
    20 Post(s)
    Tagged
    0 Thread(s)
    308 Berichten zijn liked



    Citaat Oorspronkelijk geplaatst door Cakkie Bekijk Berichten
    Ik ben bezig met een een setup die gebruik maakt van L3 routing via een switch.
    Momenteel bestaat de uit een aantal (managable) desktop switches die verbonden zijn met één 24-poort L3 switch. Er zijn verschillende VLANs waar de L3 switch voor de routing tussen de VLANs zorgt. De switch heeft dus in elke VLAN een IP adres en dit IP wordt door de clients in die VLAN als gateway gebruikt. Dit werkt.

    Nu zou ik de setup redundant willen maken door een tweede L3 switch toe te voegen en elke desktop switch ook aan die hangen. RSTP zou dan de rest doen.

    Nu weet ik niet goed hoe ik dit moet aanpakken naar IP adressering toe. Even heel simpel voorgesteld, 3 VLANs, 1, 2 en 3. Subnet telkens 192.168.X.0/24 waar X overeenkomt met de VLAN. Switch 1 zit in elke VLAN op het IP adres 192.168.X.1. De clients krijgen dit adres als default gateway.

    Ik zou denken dat ik de tweede switch in elke VLAN zijn eigen IP adres moet krijgen, bv .2 achteraan.
    Als het actieve RSTP path van een desktop switch echter over switch 2 gaat, dan gaat traffiek dus via switch 2 naar switch 1 om daar pas geroute te worden naar de andere VLAN (want de client stuurt het pakket naar de default gateway, nl het VLAN IP van switch 1). Klopt dit, of weet switch 2 toch dat hij die routing mag/moet uitvoeren? Als die switch dat niet doet, dan heb ik volgens mij ook geen redundatie als switch 1 uitvalt, toch?
    Een router met een ander IP adres dan waar de client het verkeer naar toe stuurt doet gewoon niks.
    Zo heb je inderdaad geen redundantie.

    Ik kan de clients uiteraard 2 gateways doorsturen via DHCP, maar die moeten volgens de DHCP in de volgorde worden gebruikt als ze in de DHCP vermeld staan. Alle traffiek wordt dus ook steeds eerste naar switch 1 gestuurd.
    Dat gaat ook niet werken. Niet goed en snel in elk geval, en ik vraag me af of alle (enige ?) hosts op die manier omgaat met gateway failures, doorgaan naar een tweede default route. Sterker, hoe weet de host dat er een gateway failure is ?
    Niet op basis van ethernet link down , zo .
    Met genoeg script werkt kun je natuurlijk wat in elkaar prutsen (ping gateway, geen antwoord, insert andere default).

    Het enige wat ik daar voor zou kunnen bedenken is om de switches in alle VLANs (met uitzondering van management VLAN) hetzelfde IP adres te geven. Dit klinkt op het eerste zicht niet correct, maar aangezien binnen dezelfde VLAN enkel L2 traffiek tussen die 2 switches gaat, zie ik niet meteen in waarom dat niet zou werken.
    Iemand nog ideeën?
    Hm. Je krijgt minimaal een hoop ruis van duplicate ip adres meldingen hier, maar misschien werkt het wel een beetje.
    Misschien ook nog issues met niet geleerde unicast adressen als je heen- en terug verkeer via een verschillende switch lopen.
    Ik heb er geen goed gevoel bij, maar te kort over gedacht om meteen te roepen 'werkt niet'.
    Speaking of which, hoe sluit je je hosts dubbel aan ? De host doet bridging , of heeft een actief/passief nic ?

    De nette en betere manier hier is VRRP. (Of HSRP, hetzelfde van Cisco ).
    De switches praten een onderling protocol wie 'het' (actieve) gateway adres en gateway mac heeft

    De andere nette manier is stacking, hierbij gedragen twee switch chassis zich als een enkel device, maar waarbij bij uitval van een stack member de andere(n) doorgaan .
    Je hebt dan geen twee 24 poort switches, maar een 48 poort stack, en je configureert ook een enkel 'apparaat'.

    "De gateway adressen" zijn dus een eigenschap van de gehele stack, niet iets wat op de linker of rechter switch zit.
    Andere termen (mn voor high end switches die als enkel apparaat presenteren) zijn multi-chassis , of (Cisco ) VSS .

    Het voordeel van een switch stack is, dat je dan de host met een gebundeld ethernet aan kunt sluiten (lacp) met beide linken actief.
    Anders krijg je toch iets waarbij spanning tree een pad dicht (moet) zetten, of wat vanuit de host actief/down staat.

  3. #3
    Redundantie met L3 Switches en InterVLAN routing
    geregistreerd gebruiker
    462 Berichten
    Ingeschreven
    22/05/06

    Locatie
    Belgie

    Post Thanks / Like
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    26 Berichten zijn liked


    Ondernemingsnummer: 0812210395

    Thread Starter
    VRRP had ik ook al aan gedacht, maar voor zover ik kan zien onderteunen die switchen dit niet. Stacking + LACP, daar had ik nog niet aan gedacht. De L3 switches zijn in ieder geval stackable en ook de kleinere switchen ondersteunen LACP. Spaart ook meteen 2 poorten uit op elke L3 switch, die ik wou gebruiken voor uplink.

    Enige wat ik verder nog kon bedenken was kijken of ik via de DHCP relay de volgorde van de gateways kon bepalen. Zou het probleem van welke eerst kunnen oplossen, maar geeft natuurlijk nog geen redundantie echte redundantie.

    In ieder geval al bedankt om mee te denken!



  4. #4
    Redundantie met L3 Switches en InterVLAN routing
    geregistreerd gebruiker
    1.892 Berichten
    Ingeschreven
    17/08/05

    Locatie
    Amsterdam

    Post Thanks / Like
    Mentioned
    34 Post(s)
    Tagged
    0 Thread(s)
    35 Berichten zijn liked


    Naam: Wieger Bontekoe
    Bedrijf: Skynet ICT B.V.
    Functie: CEO
    URL: skynet-ict.nl
    Registrar SIDN: Nee
    View wbontekoe's profile on LinkedIn

    Switch != Router.

    Ik kan me voorstellen dat in een kleine setup men kiest voor een L3 switch die toevallig "ook" kan routeren, maar ga je kijken naar een échte failover mogelijkheid (met name de gateway in dit geval) dan kom je toch al snel bij een router uit. VRRP is in dit geval de beste oplossing.

    Ik weet niet welke switches je gebruikt maar onze switches ondersteunen bridged interfaces (LACP) die we over twéé core switches verdelen. Ik geloof dat de Cisco term "VPC" is. Hiermee kunnen we makkelijk een core switch uitzetten en de servers merken er niets van. Dit is echter functionaliteit die niet op alle switches beschikbaar is.

    Stop je alle switches met hun uplink slechts in één core switch dan heb je natuurlijk nog geen redundancy bij uitval
    Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.

  5. #5
    Redundantie met L3 Switches en InterVLAN routing
    geregistreerd gebruiker
    1.554 Berichten
    Ingeschreven
    20/07/10

    Locatie
    's-Gravenhage

    Post Thanks / Like
    Mentioned
    20 Post(s)
    Tagged
    0 Thread(s)
    308 Berichten zijn liked



    Citaat Oorspronkelijk geplaatst door CharlieRoot Bekijk Berichten
    Switch != Router.

    Ik kan me voorstellen dat in een kleine setup men kiest voor een L3 switch die toevallig "ook" kan routeren, maar ga je kijken naar een échte failover mogelijkheid (met name de gateway in dit geval) dan kom je toch al snel bij een router uit. VRRP is in dit geval de beste oplossing.
    Mw, VRRP/HSRP is niet zo'n speciale feature dat je vooral daaraan een echte router herkent (vs een L3 switch).

    Het vraagt niks speciaals in het forwarding pad, buffering of pakket manipulatie - dat zijn meer dingen waar een 'router' zich onderscheid van een 'L3 switch' .

    Het zit dus ook vaak genoeg als feature op relatief simpele L3 switches.

    Ik weet niet welke switches je gebruikt maar onze switches ondersteunen bridged interfaces (LACP) die we over twéé core switches verdelen. Ik geloof dat de Cisco term "VPC" is. Hiermee kunnen we makkelijk een core switch uitzetten en de servers merken er niets van. Dit is echter functionaliteit die niet op alle switches beschikbaar is.

    Stop je alle switches met hun uplink slechts in één core switch dan heb je natuurlijk nog geen redundancy bij uitval
    Cisco smaken :

    Stack - low-end L3 switches, gedragen zich als een enkel chassis, backplane gekoppeld met speciale stack kabels. 3750 lijn e.a.
    VSS - Catalyst 4500,6500 lijn - high end L3 switches, gedragen zich als een enkel chassis (single controlplane) .
    vPC - Nexus lijn , high end L3 switches (virtual Port Channel) - dual control plane, maar naar dual-homed clients een single etherchannel/STP entity.

    VSS/VPC (en equivalenten van andere vendors) zijn echt core switch features; Als je dat draait/die (L3)switches hebt weet je dat ook wel.

    TS heeft het over 24 poort switches (dus zeker geen high end core switches), dus dan is de keuze stacking of VRRP, indien beschikbaar.
    Als geen van beide beschikbaar zijn zou ik overigens dan geen klungeldingen gaan bouwen , per saldo is dat toch pseudo-redundantie die waarschijnlijk meer storingen geeft dan dat het voorkomt.
    Stacking (en de hosts aansluiten met een portchannel, met lacp) lijkt me de meest fraaie oplossing,ook met de snelste en meest betrouwbare omschakeling bij uitval van een stack member.

  6. #6
    Redundantie met L3 Switches en InterVLAN routing
    geregistreerd gebruiker
    611 Berichten
    Ingeschreven
    29/01/09

    Locatie
    Meerlo

    Post Thanks / Like
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    32 Berichten zijn liked


    Naam: T
    Registrar SIDN: nee
    KvK nummer: 14115174
    Ondernemingsnummer: nvt

    Wat voor switches heb je? Er zijn natuurlijk diverse mogelijkheden, zoals al aangehaald door visser, van VRRP tot een AE / port channel over je stack members. Maar je praat over clients en desktops, hoe verwacht je daar redundantie te introduceren? Ga je de 2 nics in Windows / Linux bundelen?

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2021 Webhostingtalk.nl.
Web Statistics