[Cisco] Van Routed port naar trunk over City-Ring

[Tags NL]

Onze twee locaties zijn verbonden via een City-Ring aansluiting van Ziggo Zakelijk. Voorheen gebruikten we een Routed Port op onze Cisco 6500-e die was aangesloten op de OptiSwitch van Ziggo Zakelijk waarmee we verkeer routeerden van onze primaire locatie naar de secundaire/uitwijklocatie.

We zijn inmiddels wat verder met onze internetaansluitingen en we hebben straks een internetaansluiting op beide locaties. Om onze omgeving op een makkelijke manier op twee locaties te gebruiken (En GARP te gebruiken waardoor onze Juniper Firewall's High Available kunnen worden gebruikt) wilden we een VLAN over de beide locaties kunnen gebruiken en hebben we gevraagd of Ziggo Zakelijk het mogelijk wilde maken om VLAN informatie over onze aansluiting te krijgen. Dit kon zonder problemen en down-time (met een hogere maandprijs ), ik vraag me echt af of dit wel goed gaat.

Klein schetsje:

Primaire Locatie
Cisco 6500-e
10.10.10.0/24 (VLAN2) en twee DMZ reeksen (172 en 192, VLAN99 en VLAN100)
(En nog een aantal client/printer VLAN's die niet terzake doen)

Secundaire Locatie
2xCisco 3750 in een stack
10.10.101.0/24 reeks (Vlan101)

Verkeer wordt nu met een static route van Primaire Locatie naar Secundaire Locatie gerouteerd met als next hop het adres van de optiswitch op de Secundaire Locatie. De poort op de Cisco 6500-e staat dus nu als Routed ingesteld, Ziggo Zakelijk geeft aan dat er dus niets hoeft te worden gewijzigd en dat zij het mogelijk maken dat VLAN informatie kan worden meegestuurd. Hoe krijg ik dan VLAN informatie over als de port op Routed i.p.v Trunk staat?

Mis ik iets?

[enveekaa]

Je weet dat vlan op laag 2 zit en ip op laag 3?
Als Ziggo je vlan doorzet moet je een vlan trunk configureren op de juiste poorten en bob's your uncle, geen routering meer nodig.

Tip: Als je redundant wil zijn kan je over laag 2 ook een etherchannel configureren, hiermee kun je oa vlan trunks bundelen tot 1 logische verbinding. Zeker omdat je aan 1 kant met een stack werkt een leuke oplossing.

[ Voor 39% gewijzigd door enveekaa op 09-02-2009 19:09 ]

[Tags NL]

enveekaa schreef op maandag 09 februari 2009 @ 18:56:
Je weet dat VLAN op laag 2 zit en ip op laag 3?
Als Ziggo je vlan doorzet moet je een vlan trunk configureren op de juiste poorten en bob's your uncle, geen routering meer nodig.

Dat is dan ook gelijk het rare, Ziggo zeg dat we *niets* hoeven aan te passen. Ik gaf dan ook al zelf aan in het verhaal hierboven dat de poort wel op Trunk moet staan omdat ik anders geen VLAN informatie over de lijn krijg. Ook geven ze aan dat je geen Cisco protocollen zoals VTP kan gebruiken, iets wat me wel makkelijk leek.

Het redundant zijn bij ons betekend voornamelijk onze internetaansluiting. Als de ene aansluiting weg is, dan neemt de andere het over zodat we altijd internet naar buiten hebben met een firewall die qua instellingen identiek is als degene die op de andere locatie staat. Ook kunnen we onze DMZ op de primaire locatie ontsluiten via de internetaansluiting op de secundaire locatie, hierdoor blijven onze websites (portals) beschikbaar en kunnen klanten nog steeds via SFTP bestanden uploaden.

Oh ja, quote van Ziggo:

"VLAN-transparantie aanzetten betekend dat onze switch niet het bestaande veld voor vlan-tag’s overschrijft, maar een extra veld toevoegd. Aan de andere kant wordt dat veld weer weggehaad en het orignele vled blijft dus ongewijzigd. De klant kan dat veld dus zelf gebruiken.

VTP ofwel Vlan-Trunking-Protocol heeft hier niks mee te maken. Dit soort (Cisco) protocollen gebruiken specifieke mac-adressen om met elkaar te communiceren. De zendende switch stuurt vlan-informatie met een speciale mac-adres de lijn op. Als bij ons protocol-transparantie niet aanstaat, dan herkent onze Cisco dit mac-adres als zijnde VTP. Op onze switch staat VTP uit en hij dropped het pakket. Als protocol-transparantie aan staat ziet onze Cisco het VTP-verkeer wel, maar weet dat het niet voor hem is en stuurt het gewoon door. Voor switches van andere merken speelt dit niet omdat die dat speciale mac-adres niet herkennen en het gewoon als verkeer behandeld.

Protocol-transparantie leveren we tegenwoordig wel op onze nieuwe VPN’s maar alleen als de CPE’s op bedie lokatie’s cisco’s zijn.

Kortom, klant hoeft niks voor te bereiden, zodra wij het activeren zal de lijn wel even hikken, maar meer niet.
Met deze functie kan de klant zelf vlan’s definieren en gebruiken.
VLAN-transparantie is wat anders als Protocol-Transparantie. VTP / STP / CDP etc. zal dus niet gaan werken. "

[ Voor 10% gewijzigd door Tags NL op 09-02-2009 19:17 ]

[enveekaa]

VTP heb je ook niet nodig, je moet gewoon een dot1q trunk configureren op je Cisco's, dit huppelt dan zo over
het Ziggo netwerk. Heb je al geprobeerd een trunk te configureren?

Wikipedia: VLAN Trunking Protocol
Wikipedia: IEEE 802.1Q

Als je toch aan het trunken bent, en vrijheid hebt op laag 2 is het een eitje dit ook redundant te maken, zo heb je bijvoorbeeld minder last als er 1 vd 2 stack members problemen heeft. Of dit wel of niet aantrekkelijk is hangt natuurlijk helemaal af van het belang van deze verbinding.

[ Voor 62% gewijzigd door enveekaa op 09-02-2009 19:51 ]

[Tags NL]

enveekaa schreef op maandag 09 februari 2009 @ 19:41:
VTP heb je ook niet nodig, je moet gewoon een dot1q trunk configureren op je Cisco's, dit huppelt dan zo over
het Ziggo netwerk. Heb je al geprobeerd een trunk te configureren?

Wikipedia: VLAN Trunking Protocol
Wikipedia: IEEE 802.1Q

VTP leek ons makkelijk zodat je maar een VLAN database in je netwerk hebt die je centraal kunt bijhouden, was niet noodzakelijk inderdaad. Blijft raar dat Ziggo zegt, waarom weet ik dus niet, dat er niets aan de huidige configuratie hoeft te worden gewijzigd en dat alles blijft werken ?!?!? Nou ja, nog een keertje testen in GNS3 en dan het moment inplannen dat ze de aanpassing gaan doen...

[enveekaa]

Ja dat Ziggo meldt dat je niets hoeft aan te passen snap ik ook niet.
VTP is inderdaad makkelijk, maar wordt blijkbaar niet ondersteund
Goed, met 4 VLANs is dat ook geen showstopper.

Ik blijft me posts editen, sorry

[ Voor 9% gewijzigd door enveekaa op 09-02-2009 19:53 ]

[Tags NL]

enveekaa schreef op maandag 09 februari 2009 @ 19:52:
Ja dat Ziggo meldt dat je niets hoeft aan te passen snap ik ook niet.
VTP is inderdaad makkelijk, maar wordt blijkbaar niet ondersteund
Goed, met 4 VLANs is dat ook geen showstopper.

Ik blijft me posts editen, sorry

Ben de situatie even aan het bouwen in Cisco Packet Tracer (Mooie tool trouwens t.o.v GNS3), maar... *knip* Het lijkt al te werken

[ Voor 20% gewijzigd door Tags NL op 09-02-2009 20:16 ]

[enveekaa]

Ok, laat even weten of het is gelukt, ben wel benieuwd

[Tags NL]

enveekaa schreef op maandag 09 februari 2009 @ 20:22:
Ok, laat even weten of het is gelukt, ben wel benieuwd

Ze gaan het morgenochtend voor acht uur omzetten, ben ook erg benieuwd

[Tags NL]

Ze zeggen dat ze de wijziging hebben gedaan, we hebben er niets van gemerkt en dat lijkt me toch wel raar?!? Binnenkort dus maar de poorten op Trunk zetten en kijken of het werkt...

[JackBol]

Hebben de optiswitches een IP adres?

Wat ik mij kan voorstellen is dat jullie een access poort hadden naar de optiswitches en dat ze deze omgezet hebben naar een dot1q poort met de originele configuratie in het native vlan.

Oh ja, quote van Ziggo:

"VLAN-transparantie aanzetten betekend dat onze switch niet het bestaande veld voor vlan-tag’s overschrijft, maar een extra veld toevoegd. Aan de andere kant wordt dat veld weer weggehaad en het orignele vled blijft dus ongewijzigd. De klant kan dat veld dus zelf gebruiken.

Wat ik hieruit interpreteer is dat ze je poort hebben omgeconfigureerd van een dot1q poort naar een q-in-q poort.


Het is allemaal niet zo duidelijk en ik ben ook niet bekend met de city-ring technologie.

[Tags NL]

_DH schreef op dinsdag 10 februari 2009 @ 11:30:
Hebben de optiswitches een IP adres?

Wat ik mij kan voorstellen is dat jullie een access poort hadden naar de optiswitches en dat ze deze omgezet hebben naar een dot1q poort met de originele configuratie in het native vlan.


[...]


Wat ik hieruit interpreteer is dat ze je poort hebben omgeconfigureerd van een dot1q poort naar een q-in-q poort.


Het is allemaal niet zo duidelijk en ik ben ook niet bekend met de city-ring technologie.

De optiswitch heeft geen ip-adres adres, de poorten van onze Cisco's aan beide kanten hebben een Routed Port met daarop een ip-adres. Blijkbaar hangen onze poorten nu in hetzelfde native VLAN waardoor het dus nu nog steeds allemaal werkt We gaan dus binnenkort 's avonds de instellingen van Routed naar Trunk omzetten en kijken of alles nog werkt...

[enveekaa]

Nu je gewoon een transit vlan tussen de optiswitches.
Wat je wilt is één groot laag 2 netwerk toch?

[Tags NL]

enveekaa schreef op dinsdag 10 februari 2009 @ 19:20:
Nu je gewoon een transit vlan tussen de optiswitches.
Wat je wilt is één groot laag 2 netwerk toch?

Daar komt het eigenlijk wel op neer, hierdoor is alles gelijk een stuk flexibeler tussen onze hoofd en uitwijklocatie

[Tags NL]

Change net uitgevoerd, heel even geen verbinding gehad maar ging goed Had de configuratiewijziging in een telnet sessie geplakt die ik vanaf een machine daar had gestart en ik verloor de verbinding na het eerste commando, hij had het gelukkig nog wel uitgevoerd en dat bespaarde me weer een ritje naar de andere kant van de stad