Cisco IOS -> nieuw IP plan: vlan overlapping

[CORVETTE]

Ik zit hier met een klasse a netwerk wat een beetje uit de klauwen is gegroeit.
Alles zit in 1 groot vlan.
Nu wil ik dat vlan onderverdelen in meerdere kleintjes.

Plan gemaakt, ziet er allemaal piekfijn uit. Maar nu kom ik er na wat test werk achter dat de oude 2940/2950 werkgroep switches er niet tegen kunnen dat vlan X met 10.1.X.X en subnet 255.255.0.0 , wordt onderverdeeld door de nieuwe vlan's.
Ik weet precies waarom het gezegd wordt: de nieuwe vlan's overlappen met de oude grote.
Ik wil de vlan's toch echt in de switches hebben staan, zodat ik gelijdelijk over kan. ( lees poortje voor poortje, big bang kan niet ). De nieuwe 2960s switches accepteren het trouwens wel. Maar allemaal nieuwe switches aanschaffen is ook geen optie.
Wijzigen van ip plan is eigenlijk geen optie, omdat wij de ip adressen niet teveel kunnen wijzigen.

Wat zijn de mogelijkheden om op de oude switches toch de overlap erdoorheen te krijgen ?

Is het een optie om het grote vlan 20, weer vlan 1 te maken, en zo alle configuratie mbt vlan 20 uit de werkgroep switches te gooien, zodat die automatisch weer in vlan 1 gaan zitten. En vervolgens mijn nieuwe vlan's erin te schieten ?

[CyBeR]

Ze zouden daar alleen last van mogen hebben met enige vorm van layer-3 operation. Ik neem aan, aangezien je één groot vlan hebt, dat ze niet routen (kunnen 2950's ook niet geloof ik?) dus dan is 't een kwestie van zorgen dat de management interfaces in een ander, niet-overlappend vlan zitten. Aannemelijkerwijs is 't voor die adressen niet zo'n groot probleem om ze te wijzigen.

[knutsel smurf]

De 2950-EI heeft overigens wel wat routing functies.

Wat ik me afvraag is of dit niet weer typisch de manier waarbij cisco je forced om te upgraden. Ik neem aan dat je de laatste firmware etc hebt geladen? Vooral omdat deze range natuurlijk al lang niet meer onder enig service contract actief is zal cisco al snel zeggen dat je naar de nieuwe toe moet wanneer je voor support aan klopt.

Mocht je toch besluiten om naar nieuwe switches te gaan kijk eens naar de Alcatel-Lucent OS6450 welke in vergelijking met de 2960 een veel beter prijs punt heeft.

[CORVETTE]

CyBeR schreef op dinsdag 29 januari 2013 @ 14:25:
Ze zouden daar alleen last van mogen hebben met enige vorm van layer-3 operation. Ik neem aan, aangezien je één groot vlan hebt, dat ze niet routen (kunnen 2950's ook niet geloof ik?) dus dan is 't een kwestie van zorgen dat de management interfaces in een ander, niet-overlappend vlan zitten. Aannemelijkerwijs is 't voor die adressen niet zo'n groot probleem om ze te wijzigen.

Ah, het gaat eigenlijk dus alleen om de management interface. Door hoef ik niet perse een ip op te hebben. Alhoewel. Dan kan ik er niet remote meer bij ...... tenzij ik die management tijdenlijk in een ander vlan hang. Wij hebben nog wel wat 172 ip's over van ons wireless. Dan zou ik die kunnen pakken.
Dat zou ik inderdaad eens even kunnen testen.

Nee, de 2940 en 2950 die wij hebben ( laatste IOS ) kunnen niet routeren. Daar ze echt te oud voor

[CyBeR]

CORVETTE schreef op dinsdag 29 januari 2013 @ 19:10:
[...]


Ah, het gaat eigenlijk dus alleen om de management interface. Door hoef ik niet perse een ip op te hebben. Alhoewel. Dan kan ik er niet remote meer bij ...... tenzij ik die management tijdenlijk in een ander vlan hang. Wij hebben nog wel wat 172 ip's over van ons wireless. Dan zou ik die kunnen pakken.
Dat zou ik inderdaad eens even kunnen testen.

Ik zou er zelfs een heel apart vlan voor maken.

[DukeBox]

CyBeR schreef op dinsdag 29 januari 2013 @ 19:35:
Ik zou er zelfs een heel apart vlan voor maken.

Wilde ik ook net typen...
Hoe dan ook staat VLAN en IP-plan los van elkaar natuurlijk.

[_-= Erikje =-_]

Niet helemaal, als je vlan subnetten elkaar moeten kunnen bereiken zul je toch ergens moeten routeren

[DukeBox]

Nee, dat speelt zich af op 2 verschillende lagen. Een VLAN bereikt niet een ander VLAN, een protocol doet dat en dat heeft niets te maken met VLAN's an sich.

[DrFlash]

Over het algemeen doe je routeren op een router, en niet op een switch. het klopt inderdaad dat je op de switch alleen een ip opgeeft voor de management interface, voor de rest trekt het zich niets aan van ip adressen. switches 'snappen' alleen verkeer waar een mac in verwerkt zit. IP's zit op een andere netwerklaag waar switches verder niets mee doen.

[DukeBox]

DrFlash schreef op woensdag 30 januari 2013 @ 11:10:
Over het algemeen..

Ik denk juist dat tegewoordig 'over het algemeen' vaker L3 switches worden ingezet om te routeren dan routers.
Alleen op ISP niveau kom ik nog dedicated routers tegen.

[Anoniem: 130989]

DukeBox schreef op woensdag 30 januari 2013 @ 13:10:
[...]

Ik denk juist dat tegewoordig 'over het algemeen' vaker L3 switches worden ingezet om te routeren dan routers.
Alleen op ISP niveau kom ik nog dedicated routers tegen.

L3 switches zijn geen echte routers, ze missen veel router functies (afhankelijk van type: BGP,Netflow,NAT etcetc). L3 switches worden voornamelijk gebruikt op campus lan voor inter-vlan routeren, VRF-lite e.d. Aan de WAN kant van het campus tref je nog altijd routers aan.

[DukeBox]

De betere L3/4/5 switches kunnen ook als Border Gateway dienen (NAT is hoe dan ook geen router functionaliteit, maar een firewall optie). Ook VRF is tegenwoordig in de vorm van routed ACL terug te vinden in switches.
Ik denk dat je hetzelfde bedoeld, maar ik haakte in op 'algemeen' (als in aantallen).. de meeste omgevingen waar enige vorm van routering gebruikt wordt in het lan/wan doen dit vaak middels switches.
Dedicated routers kom je zoals je zelf ook beschrijft voornamelijk op ISP (/internet gateway) niveau tegen.

[Anoniem: 130989]

L4 L5 switches? Je kan L2 switchen op basis van L4 informatie (QOS) Maar L5? nog nooit van gehoord, wellicht een marketing term?

Switches als border gateway? verklaar je nader? als je bedoelt een SVI met een ip, dan ja. Als je een "management" boundry bedoelt, ben ik het niet met je eens.

NAT zie ik (persoonlijk) weldegelijk als een router optie en niet als firewall optie. (NAT is geen security, hoewel NAT overload dat misschien zou laten lijken) Het is sowieso een grijs gebied aangezien routers als (cbac/zone based) firewall kunnen dienen en firewalls kunnen routeren.

VRF-lite zit al gewoon in een "degelijke" layer 3 switch (cisco 3750G bijvoorbeeld)

Routed ACL? Bedoel je PBR misschien? of gewoon een ACL inbound op de SVI? Hoe dan ook zou ik waar mogelijk VRF-lite gebruiken.

Wij (multinational) hebben uitsluitend routers die sites met het WAN verbinden. Firewall's e.d staan in de DC's.
Wellicht kom jij in andere omgevingen dan ik, dat zegt niets over wat beter is. Een site met een paar vlans kan goed volstaan zonder routers waarbij de firewall NAT doet en een L3 switch intervlan routeert.

[CyBeR]

Anoniem: 130989 schreef op woensdag 30 januari 2013 @ 17:07:
L4 L5 switches? Je kan L2 switchen op basis van L4 informatie (QOS) Maar L5? nog nooit van gehoord, wellicht een marketing term?

Load balancers (die in hardware balancen.)

Switches als border gateway? verklaar je nader? als je bedoelt een SVI met een ip, dan ja. Als je een "management" boundry bedoelt, ben ik het niet met je eens.

je L3 switch BGP laten lullen met een ander netwerk. Duizenden Cisco 6500's in de wereld die precies dat doen, evenals duizenden Foundry(/Brocade) switches.

NAT zie ik (persoonlijk) weldegelijk als een router optie en niet als firewall optie. (NAT is geen security, hoewel NAT overload dat misschien zou laten lijken)

NAT werkt op basis van het bijhouden van flows. Dat komt een stuk dichter in de buurt van een firewall dan een router, welke gewoon packets moet schuiven.

Wij (multinational) hebben uitsluitend routers die sites met het WAN verbinden.

Dat is jullie keuze, maar de rest van de wereld doet niet noodzakelijkerwijs hetzelfde he Het meest ingezette platform voor ebgp de afgelopen paar jaar is geloof ik de cisco 6500. (Beetje uit de lucht gegrepen statistiek maar je moest 's weten hoe vaak die dingen ingezet worden.)

[Anoniem: 130989]

CyBeR schreef op donderdag 31 januari 2013 @ 00:21:
Load balancers (die in hardware balancen.)

Dat zijn dus geen "switches" (maar zoals je zelf zegt load-balancers)

je L3 switch BGP laten lullen met een ander netwerk. Duizenden Cisco 6500's in de wereld die precies dat doen, evenals duizenden Foundry(/Brocade) switches.

Klopt, wij hadden 4500's (jaren terug) die BGP draaiden. Dit wordt normaliter gedaan om routing informatie door te geven(IBGP). Niet als Gateway naar het WAN(EBGP). Dat er uitzondingen zijn geloof ik meteen. Maar ik kan mij haast niet voorstellen dat veel bedrijven EBGP draaien op een 6500 tenzij er specifieke supervisors zijn geinstalleerd. Hierdoor vind ik het geen "puure" switch meer aangezien je het upgrade met extra functionaliteit. Wellicht heb ik het mis, en wordt er vaak een 6500 met puur switching supervisors in EBGP gezet, toch blijf ik het design-technisch gek vinden.

NAT werkt op basis van het bijhouden van flows. Dat komt een stuk dichter in de buurt van een firewall dan een router, welke gewoon packets moet schuiven.

NAT overload werkt op basis van het bijhouden van flows. NAT is er in veel verschillende vormen. Vind jij static NAT dan ook onderdeel van firewalls? Als je wiki erop naslaat hebben ze het voornamelijk over routers. Denkt dat dit vooral mening/gevoel gebaseerd is, geen duidelijk goed/fout.

Dat is jullie keuze, maar de rest van de wereld doet niet noodzakelijkerwijs hetzelfde he Het meest ingezette platform voor ebgp de afgelopen paar jaar is geloof ik de cisco 6500. (Beetje uit de lucht gegrepen statistiek maar je moest 's weten hoe vaak die dingen ingezet worden.)

Gevoelsmatig vind ik het gek dat de 6500 als EBGP (ipv IBGP+IGP) wordt ingezet. Wellicht kom jij vaker met dit soort constructies in aanraking dan ik. I stand corrected.

We gaan wel een beetje offtopic ..

On topic:

Cisco 2950 hebben maar 1 management adres mogelijkheid. Als je een 2e configureerd verdwijnt de eerste. Dit in tegenstelling tot de 2960 die in meerdere vlans een managment IP kan hebben. (Maar geen ip routing doet, behalve de 2960-s)

Deze switches hoeven niet naar het nieuwe vlan gezet te worden als dit puur voor management is. Je kan gewoon je access VLAN's stretchen tot een layer3 switch en daar intervlan gaan. (Let wel op dat de vlans in dat geval niet mogen overlappen.)

[CyBeR]

Anoniem: 130989 schreef op donderdag 31 januari 2013 @ 09:39:
[...]


Dat zijn dus geen "switches" (maar zoals je zelf zegt load-balancers)

Mijn load balancer is toch echt een switch Strict gezien is 't load balancen zelfs een extra bij te kopen optie-- zonder die licentie is 't zelfs niet meer dan een switch.

Klopt, wij hadden 4500's (jaren terug) die BGP draaiden. Dit wordt normaliter gedaan om routing informatie door te geven(IBGP). Niet als Gateway naar het WAN(EBGP). Dat er uitzondingen zijn geloof ik meteen. Maar ik kan mij haast niet voorstellen dat veel bedrijven EBGP draaien op een 6500 tenzij er specifieke supervisors zijn geinstalleerd. Hierdoor vind ik het geen "puure" switch meer aangezien je het upgrade met extra functionaliteit. Wellicht heb ik het mis, en wordt er vaak een 6500 met puur switching supervisors in EBGP gezet, toch blijf ik het design-technisch gek vinden.

sup720 kan héél veel aan. En 't is toch echt een switch, architectuurtechnisch. Alleen dan zodanig opgerekt qua hardware dat je er een full table mee kan routen met meerdere peers. De meeste (non-chassis toch in ieder geval) switches met L3-mogelijkheden werken op zich hetzelfde maar zijn gewoon wat kleiner gedimensioneerd qua hardware (TCAM geheugen e.d.) zodat dat niet kan.

NAT overload werkt op basis van het bijhouden van flows. NAT is er in veel verschillende vormen. Vind jij static NAT dan ook onderdeel van firewalls? Als je wiki erop naslaat hebben ze het voornamelijk over routers. Denkt dat dit vooral mening/gevoel gebaseerd is, geen duidelijk goed/fout.

Laat ik 't anders zeggen: ik vind eigenlijk dat er geen plaats in de wereld is voor NAT, statisch of anders En als 't ergens moet, dan op een firewall. Een router moet asymmetrisch kunnen werken en dat gaat kapot als 't ding flows moet bijhouden of packets moet manglen.

[ Voor 22% gewijzigd door CyBeR op 31-01-2013 09:54 ]

[CORVETTE]

Hoe gaan 4500 switches met vlan overlapping om ? Dat zijn namelijk onze core switches, en die zorgen voor het routeren tussen de vlan's.

[Anoniem: 130989]

CyBeR schreef op donderdag 31 januari 2013 @ 09:50:

Mijn load balancer is toch echt een switch Strict gezien is 't load balancen zelfs een extra bij te kopen optie-- zonder die licentie is 't zelfs niet meer dan een switch.

Toch koop je geen switch voor layer >4 load balancing. Dat een load-balancer switched is niet mijn punt van discussie. Dat is gewoon zo.

sup720 kan héél veel aan. En 't is toch echt een switch, architectuurtechnisch. Alleen dan zodanig opgerekt qua hardware dat je er een full table mee kan routen met meerdere peers. De meeste (non-chassis toch in ieder geval) switches met L3-mogelijkheden werken op zich hetzelfde maar zijn gewoon wat kleiner gedimensioneerd qua hardware (TCAM geheugen e.d.) zodat dat niet kan.

Conclusie: een switch met een routermodule kan routeren.

Laat ik 't anders zeggen: ik vind eigenlijk dat er geen plaats in de wereld is voor NAT, statisch of anders En als 't ergens moet, dan op een firewall. Een router moet asymmetrisch kunnen werken en dat gaat kapot als 't ding flows moet bijhouden of packets moet manglen.

Oh jee, ik voel het het all hail ipv6 verhaal aankomend

[Anoniem: 130989]

CORVETTE schreef op donderdag 31 januari 2013 @ 09:58:
Hoe gaan 4500 switches met vlan overlapping om ? Dat zijn namelijk onze core switches, en die zorgen voor het routeren tussen de vlan's.

Routeren tussen vlans werkt alleen mits ze non-overlapping zijn. Om Layer 2 te kunnen blijven communiceren ben ik bang dat het ontkomt aan het "big bang" princiepe.

Een host in 10.0.0.0 255.0.0.0 zal namelijk nooit zijn default gateway raadplegen indien hij 10.1.0.0 255.255.0.0 moet bereiken. Hij zal locaal ARP-en voor het mac van de host en nooit een reply krijgen.

Toevoeging, Je zou met proxy arps dit kunnen bridgen. Hier moet ik nog even over nadenken

[ Voor 7% gewijzigd door Anoniem: 130989 op 31-01-2013 10:04 ]

[CyBeR]

CORVETTE schreef op donderdag 31 januari 2013 @ 09:58:
Hoe gaan 4500 switches met vlan overlapping om ? Dat zijn namelijk onze core switches, en die zorgen voor het routeren tussen de vlan's.

In theorie mag 't geen probleem zijn aan de kant van de routing (longest-prefix matching immers), maar zoals hierboven een host in je /8-subnet gaat een host in je nieuwe kleinere subnet niet zomaar kunnen vinden.

Wellicht is dat nog op te lossen door proxy arp aan te zetten op je router.

[plizz]

Anoniem: 130989 schreef op donderdag 31 januari 2013 @ 09:39:
On topic:

Cisco 2950 hebben maar 1 management adres mogelijkheid. Als je een 2e configureerd verdwijnt de eerste. Dit in tegenstelling tot de 2960 die in meerdere vlans een managment IP kan hebben. (Maar geen ip routing doet, behalve de 2960-s)

De normale Cisco 2960 kunnen ook statische routeren. Je moet alleen de sdm template veranderen. In de privilege mode moet je "show sdm prefer" intikken om te kijken wel sdm template nu op de switch actief is. Om ip routing (lees: Statisch routeren) te activeren met je in config mode "sdm prefer lanbase-routing" intikken en de switch reloaden.

[Anoniem: 130989]

plizz schreef op donderdag 31 januari 2013 @ 10:07:
[...]


De normale Cisco 2960 kunnen ook statische routeren. Je moet alleen de sdm template veranderen. In de privilege mode moet je "show sdm prefer" intikken om te kijken wel sdm template nu op de switch actief is. Om ip routing (lees: Statisch routeren) te activeren met je in config mode "sdm prefer lanbase-routing" intikken en de switch reloaden.

Cool! ik meende dat alleen de 2960-s (tot 16 statics, met template change) konden. Maar jij zegt de gewone 2960 ook ?

Edit: Helaas onze 2960 48PST-L - 12.2(50)SE4:

XXX(config)#sdm prefer ?
default Default bias
dual-ipv4-and-ipv6 Support both IPv4 and IPv6
qos QoS bias

[ Voor 14% gewijzigd door Anoniem: 130989 op 31-01-2013 10:12 ]

[plizz]

Anoniem: 130989 schreef op donderdag 31 januari 2013 @ 10:07:
[...]


Cool! ik meende dat alleen de 2960-s (tot 16 statics, met template change) konden. Maar jij zegt de gewone 2960 ook ?

Sind een bepaalde ios releas is de sdm template lanbase-routing erbij gekomen. Als die template actief is dan kan je "ip route" gebruiken.

Ik gebruik een switch met IOS: c2960-lanbasek9-mz.122-55.SE.bin

[ Voor 7% gewijzigd door plizz op 31-01-2013 10:13 ]

[Anoniem: 130989]

plizz schreef op donderdag 31 januari 2013 @ 10:12:
[...]

Sind een bepaalde ios releas is de sdm template lanbase-routing erbij gekomen. Als die template actief is dan kan je "ip route" gebruiken.

Thanks, gaan we testen

Je hebt gelijk ! Cool! " The lanbase-routing template is supported only on switches running Cisco IOS Release 12.2(55)SE or later and the LAN base image. "

WS-C2960-48PST-L - 12.2(58)SE2
xxx(config)#sdm prefer ?
default Default bias
dual-ipv4-and-ipv6 Support both IPv4 and IPv6
lanbase-routing Lanbase routing
qos QoS bias

[ Voor 39% gewijzigd door Anoniem: 130989 op 31-01-2013 10:19 ]

[pablo_p]

On topic:

Ik heb een keer een plan gemaakt om een groot subnet (/20) onder te verdelen in /24 segmenten zonder hernummering. Het betrof dan systemen met fixed IP adressen die ook elders in de organisatie in firewall rules stonden en dus niet makkelijk omgenummerd kon worden. De ongeveer 1500 gebruikers PC's had ik er al los uit gemigreerd en verdeeld in 30 verdiepings VLANs. Aangezien dat allemaal DHCP was, is dat zonder gebruikers impact 's avonds gedaan.

De default gateway voor de servers was een paartje Cisco 6500 switches.

Voorbereiding:

1. In alle reeksen het .1, .2 en .3 adres vrijmaken door IP hernummerring (betrof 2 systemen in totaal)
2. Op de 6500 switches in het bestaande VLAN dmv HSRP een .1 adres aanmaken in iedere /24 reeks
3. Changes indienen naar alle beheerders van systemen in de reeks om hun default gateway aan te passen naar het .1 adres in hun /24 reeks en het subnetmask aan te passen naar 255.255.255.0
4. Overzicht maken welk IP adres achter welke poort zit. Dit bepaald in welk VLAN die poort gezet moet worden na de change. Op basis hiervan een omzet script maken EN een rollback script
5. 15 nieuwe VLANs en bijbehorende VLAN/SVI interfaces aanmaken in shutdown state + activate en rollback script voor de SVI's

In een big-bang change de volgende acties

1. Bestaande VLAN /20 omzetten naar een /24 subnet met bijhorende IP reeks en .1 HSRP adres
2. Op de nieuwe VLANs de SVI enablen en voorzien van goede IP adres (dmv script). .1 default gateway, .2 en .3 voor de switches
3. dmv voorbereid script op alle switches (20 stuks oid) alle poorten in het oude VLAN omzetten naar het nieuwe VLAN (afhankelijk van IP adres achter poort)

Voor en na de bing-bang change alle systemen pingen om te bepalen of ze up zijn en op blijven. Indien systemen in bepaalde subnets niet reageren, VLAN controleren (FSVI en poort). Als je het systeem wel lokaal kan pingen, maar niet van buitenaf, dan proxy-arp aanzetten op het VLAN. Dan zal het wel werken en proxy-arp kan je tijdelijk laten aanstaan (is definief ongewenst). Lijst van systemen met deze problemen noteren en dan na de change de beheerder aanzetten alsnog het subnet/gateway aan te passen.

Er was een /24 reeks binnen de /20 waarin ESX guests systemen stonden. Het handigst (minste afhankelijkheid) was daarom om het oude VLAN nummer te handhaven voor die /24 reeks. Daarmee is tijdens de change er minimale afhankelijkheid van andere beheergroepen (zoals Window/Unix/Printers/Werkplek/Overig)

Off-topic: Cool dat de 2960 deze feature heeft. Ik heb het direct getest om mij core switchje thuis (2960G-8 met 15.0(2)) en het werkt prima. Zo nog even testen met iperf, maar aangezien een 2960 alleen forwarding in ASICs heeft, is het of linespeed, of het kan niet.

[pablo_p]

En over de andere off topic onderweren:
- ik zou niet zeggen dat VLANs en subnets volledig los van elkaar zijn, maar loosely coupled. Je kan meerdere subnets in een VLAN hebben, maar ook hetzelfde subnet in meerdere VLANs (gebridged of niet gebridged)
- binnen het bedrijf waar ik werk draaien we ook BGP op 6500's (ook eBGP naar Internet) . Maar de PE routers van een van de interneMPLS wolken zijn 7600 routers. Grotendeels hebben 6500 en 7600 dezelfde hardware (line cards en chassis, lang vergelijkbare en uitwisselbare software, maar het staat me bij dat Cisco dat wilde differentieren door bv feaures exclusive te maken voor het ene of het andere platform.

[Anoniem: 130989]

pablo_p schreef op donderdag 31 januari 2013 @ 13:08:
- binnen het bedrijf waar ik werk draaien we ook BGP op 6500's (ook eBGP naar Internet) . Maar de PE routers van een van de interneMPLS wolken zijn 7600 routers. Grotendeels hebben 6500 en 7600 dezelfde hardware (line cards en chassis, lang vergelijkbare en uitwisselbare software, maar het staat me bij dat Cisco dat wilde differentieren door bv feaures exclusive te maken voor het ene of het andere platform.

OK, intressant om te horen. Het komt blijkbaar vaker voor dan ik had gedacht/verwacht.

[DukeBox]

Anoniem: 130989 schreef op donderdag 31 januari 2013 @ 13:14:
OK, intressant om te horen. Het komt blijkbaar vaker voor dan ik had gedacht/verwacht.

Ja.. denk dat daarom CyBeR en ik ook meer op 1 lijn zitten.

Ik werkte zelf voornamelijk met procurve opgevingen bij 3 MKB met gemiddeld maar 15 Europese vestigingen (zo'n 1500 man EMEA) en dat is hoe dan ook al een markt waar veel meer met edge switches wordt opgelost dan met dedicated routers.. juist omdat de functionaliteit voor de (eenvoudigere) eisen al dekkend zijn.

Met L5 wordt idd vaak genoemd bij switches die bijv. load balancing doen (zoals de osi laag zelf al aangeeft, sessie aware switching).. maar eigenlijk was het een typefout

[pablo_p]

DukeBox schreef op donderdag 31 januari 2013 @ 14:33:
[...]
Met L5 wordt idd vaak genoemd bij switches die bijv. load balancing doen (zoals de osi laag zelf al aangeeft, sessie aware switching).. maar eigenlijk was het een typefout

Het makkelijkst is dan te spreken over multilayer switches

[CORVETTE]

Het is wel apart dat iedere switch anders met een overlap overweg gaat:

oude 3500 serie: accepteert commando niet eens, gelijk overlap een geen config wijziging
2960s: accepteert commando, maakt vlan aan, maar geen ip's erbij
4500: accepteert commando, maakt vlan aan, zet ip's erbij, maar gooit hem down.

Allemaal geven ze wel de melding: dat er een ip overlapping is.

Maar wat zou er gebeuren als ik op de 4500 ( daar gaat het om ), als ik dat vlan probeer te " no shut" ten ? Is er dan enige kans dat ik de boel plat zou gooien ? Is namelijk een live core switch.

[CyBeR]

VLAN interfaces zijn op cisco altijd down als er geen poorten up zijn in dat vlan.

[DukeBox]

^ en trunks

[CyBeR]

Typisch gezien gaat een trunk via een poort

[CORVETTE]

CyBeR schreef op donderdag 07 februari 2013 @ 12:43:
VLAN interfaces zijn op cisco altijd down als er geen poorten up zijn in dat vlan.

ah, thnx

Maar enig idee wat er zou gebeuren als ik poorten aan dat vlan zou hangen ?

[CyBeR]

Nope, sorry. Wat mij betreft zou 't moeten werken, maar mischien dat je dat beter even buiten kantooruren uitprobeert…