vraagje over VLAN-> CentOS 5.2 & dell powerconnect switch

[Erik]

Voor een afstudeeropdracht willen mijn collega en ik verschillende VLANS aanmaken op een testserver.

De situatie is simpel:


Laptop---------Switch---------Server

Op de server hebben we verschillende VLANS aangemaakt, 1 met ID 4, 1 met ID 5.
Beide VLANS hebben hetzelfde subnet toegewezen gekregen (statisch).

Dit zijn de instellingen:
Eth0.4:

code:

[root@xenserver network-scripts]# cat ifcfg-eth0.4
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth0.4
BOOTPROTO=static
HWADDR=00:1E:C9:CE:3B:4C
ONBOOT=yes
VLAN=yes
IPADDR=10.0.4.201
NETMASK=255.255.255.0
BROADADR=10.0.4.255

Eth0.5:

code:

[root@xenserver network-scripts]# cat ifcfg-eth0.5
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth0.5
BOOTPROTO=static
HWADDR=00:1E:C9:CE:3B:4C
ONBOOT=yes
VLAN=yes
IPADDR=10.0.4.202
NETMASK=255.255.255.0
BROADCAST=10.0.4.255

De vraag is nu hoe wij de switch zó kunnen configureren dat de laptop wél de eth0.4 kan pingen/bereiken
en NIET de eth0.5.

De instellingen die wij kunnen wijzigen in de switch zijn de volgende:

membership:

(klikbaar)

vlan portsettings:


Wij hebben met onze bedrijfsbegeleiders overlegd, en die weten het verder ook niet. We zijn hier nu
al een week of twee mee aan de gang, en erg veel verder komen we niet.

Uiteraard hebben we met google gezocht. Daar vonden we onder andere deze officiele documentatie:
http://supportapj.dell.co...html/carriero.htm#1346043


Over de algemene instellingen wordt daar het volgende vermeld

Show VLAN — Lists and displays specific VLAN information according to VLAN ID or VLAN name.
VLAN Name (0-32 Characters) — The user-defined VLAN name.
Status — The VLAN type. Possible values are:
Dynamic — The VLAN was dynamically created through GVRP.
Static — The VLAN is user-defined.
Default — The VLAN is the default VLAN.
Authentication Not Required— Enables or disables unauthorized users from accessing a VLAN.
Remove VLAN — When selected, removes the VLAN from the VLAN Membership Table.

dit over de port settings tabel:

The VLAN Port Membership Table contains a Port Table for assigning ports to VLANs. Ports are assigned to a VLAN by toggling through the Port Control settings. Ports can have the following values:

T= The interface is a member of a VLAN. All packets forwarded by the interface are tagged. The packets contain VLAN information.
U= The interface is a VLAN member. Packets forwarded by the interface are untagged.
F= The interface is denied membership to a VLAN.
Blank= The interface is not a VLAN member. Packets associated with the interface are not forwarded.

Heeft iemand suggesties over hoe we dus het volgende kunnen bereiken?


wel werkend:
LAPTOP-------switch------------eth0.4

niet werkend
LAPTOP------switch-------------eth0.5

Onze bedrijfsbegeleider suggereerde dat het wellicht met routing binnen de server te maken zou kunnen hebben. Dat de daadwerkelijke toegang tot eth0.5 dus via eth0.4 gebeurt, en dat we daarom eth0.5 kunnen pingen ondanks dat we in VLAN 4 zitten. Echter, wij staan open voor alle mogelijke ideeën en oplossingen!

[Erik]

Mijn excuses als dit niet in professional networking had gemoeten, overigens.

[TrailBlazer]

Je kan nooit 2 interfaces in hetzelfde subnet hebben op een machine.

[jvanhambelgium]

Bon, zet de "end user" port (port 3 precies) als "Access Port" in deze VLAN-4
Port 1 ziet er mij de "trunk" port aan richting server ?

Nu moet je een beetje oppassen met de IP's die gebruikt. Je hebt dus 2 VLAN's die overlap hebben...
Je server kan mischien wel eens verwarring hebben met het terug encapsulere van een reply...en mischien pak ie "standaard" de eerste sub-interface dus 0.4 die dus wel werkt!

Moet de IP-range dezelfde zijn ?
Je zal merken dat als je op de server de interface 0.5

IPADDR=10.0.5.202
NETMASK=255.255.255.0

Dat je probleem opgelost is MAAR indien je interface 0.5 wil kunnen pingen zal de server wel als default gateway opgegeven moeten zijn op de test-laptop anders ga je dit nooit kunnen pingen!

Je gebruik van de VLAN met overlappende ranges is niet alledaags ;-) Zeker niet als er ook routing tussen moet kunnen ;-)

[jvanhambelgium]

Je server KAN eventueel de layer-3 routing tussen VLAN's doen (inter-vlan), die Dell switch gaat dat niet voor je doen, da's puur de ethernet-L2 port-based-vlan's...

Maar ik ben zeker dat als je effe ethernet 0.5 op de server een ander IP'tje geeft je vanaf dan perfect 0.4 kunt pingen en 0.5 niet meer. Wat je dus wil bekomen;

[Erik]

jvanhambelgium schreef op vrijdag 31 oktober 2008 @ 11:39:
Bon, zet de "end user" port (port 3 precies) als "Access Port" in deze VLAN-4
Port 1 ziet er mij de "trunk" port aan richting server ?

Zo hebben wij het momenteel inderdaad gedaan.

Nu moet je een beetje oppassen met de IP's die gebruikt. Je hebt dus 2 VLAN's die overlap hebben...
Je server kan mischien wel eens verwarring hebben met het terug encapsulere van een reply...en mischien pak ie "standaard" de eerste sub-interface dus 0.4 die dus wel werkt!

Hmm. Dat is inderdaad een risico, maar in principe mogen pakketjes vanuit vlan 5 in principe niet eens doorgegeven worden aan de eth0.5.

Moet de IP-range dezelfde zijn ?
Je zal merken dat als je op de server de interface 0.5

IPADDR=10.0.5.202
NETMASK=255.255.255.0

Dat je probleem opgelost is MAAR indien je interface 0.5 wil kunnen pingen zal de server wel als default gateway opgegeven moeten zijn op de test-laptop anders ga je dit nooit kunnen pingen!

Je gebruik van de VLAN met overlappende ranges is niet alledaags ;-) Zeker niet als er ook routing tussen moet kunnen ;-)

Dit lost inderdaad het probleem op, echter in de eindsituatie willen we virtualisatie gaan toepassen m.b.v. die vlans. De inkomende verbindingen hebben allemaal dezelfde ip-range, alleen de vlan tag is anders.

Dat is de reden dat de VLAN's allemaal dezelfde ip-range moeten hebben, maar onderling hoeft routing niet te werken!

[ Voor 7% gewijzigd door Erik op 31-10-2008 12:01 ]

[Erik]

TrailBlazer schreef op vrijdag 31 oktober 2008 @ 11:38:
Je kan nooit 2 interfaces in hetzelfde subnet hebben op een machine.

Ook niet als die beiden in een ander VLAN zitten?

[Erik]

jvanhambelgium schreef op vrijdag 31 oktober 2008 @ 11:45:
Je server KAN eventueel de layer-3 routing tussen VLAN's doen (inter-vlan), die Dell switch gaat dat niet voor je doen, da's puur de ethernet-L2 port-based-vlan's...

Dat begrijpen we, echter de VLANS hoeven onderling niet te communiceren.

edit:
sorry voor de driedubbelpost!

[ Voor 5% gewijzigd door Erik op 31-10-2008 12:03 ]

[TrailBlazer]

Erik schreef op vrijdag 31 oktober 2008 @ 12:01:
[...]

Ook niet als die beiden in een ander VLAN zitten?

Nee want de server weet toch nooit in welk vlan bijvoorbeeld IP 10.0.4.200 zit.

[Erik]

TrailBlazer schreef op vrijdag 31 oktober 2008 @ 12:08:
[...]

Nee want de server weet toch nooit in welk vlan bijvoorbeeld IP 10.0.4.200 zit.

Waarom niet? alle packages die binnenkomen hebben een vlan tag, en alle uitgaande verkeer wordt specifiek op 1 virtuele interface er uit gestuurd. De eth0.4 is bijvoorbeeld gekoppeld aan een eth0 van een virtuele machine. Die machine weet niet beter dan dat de eth0.4 van de hostmachine zijn eth0 is.

Omdat deze vanaf interface eth0.4 komt en een vlan tag voor vlan4 heeft, zou de switch vervolgens moeten weten waarheen de pakketjes moeten.

Corrigeer me aub als ik het nu verkeerd heb. Vlans zijn voor ons nieuw!

[TrailBlazer]

Kijk nu heb je het opeens over virtuele machine en daar had je het net nog niet over. Op een machine fysiek of logisch kan het niet. Volgens mij is gewoon het netwerkplaatje wat je wil bereiken gewoon niet goed. Teken is wat je wil bereiken.

[Erik]

code:

LAPTOP      ---- switch ---- (fysieke CentOS server met XEN virtualisatie-software)     eth0.4 ----- is verbonden met de eth0 van virtuele server1
(10.0.4.221)                                                                               (10.0.4.201)
                                                                                           eth0.5 ----- is verbonden met de eth0 van virtuele server2
                                                                                        (10.0.4.202)

Nu was het dus de bedoeling dat de LAPTOP, die in vlan 4 zit, dus alleen de servers in vlan 4 achter eth0.4 kon zien, maar hij kan dus nu ook alles zien
achter eth0.5, vlan 5 dus, zien.

Alleen zitten we nu nog in de testomgeving, en hebben we nog geen draaiende virtuele servers. Omdat we de vlans nog niet aan de gang kregen.

Is het 'plaatje' een beetje duidelijk wat onze bedoeling is met vlans etc? Anders kan ik er nog een wel iets gedetailleerde omschrijving geven?

[TrailBlazer]

Moet je wel een ip adres op je subinterfaces zetten in je host systeem. Het lijkt mij dat dit enkel nodig is in je virtuele systeem.

[jvanhambelgium]

De moment dat je de virtuele system in gebruikt hebt moet het normaal reeds werken !!
De Xen host zal de tags strippen en de frames/packets afleveren binnen de juiste VM die dan gekoppeld is aan de juiste VLAN, in uw geval zal je een ping kunnen doen naar 10.0.4.201 en niets anders.
Ik denk ook del dat de Xenhost zelf geen IP-adressen mag hebben, buiten een ander management IP-adres natuurlijk.

De laptop zit in een switchport en krijgt tag 4 als ie op de trunk (port 1) gaat richting Xen.
Xen stript de tag 4 eraf en forward de L2-frame naar de VM die hier gekoppeld zit en daar zal het ergens uit de TCP/IP stack gebolt komen).

HEB je al VM's opgezet of draaien er nog geen op deze moment en is deze "ip configuratie" eerder een Xenhost config file zelve ?


De Xen "host" ziet normaal (volgens mij dus...) zelf geen IP passeren (of maakt hier geen beslissingen op) dus je kan perfect verschillende VM's dezelfde IP-ranges laten gebruiken, doch kan je nooit onderling communiceren tussen deze VM's op deze manier zonder NAT te gebruiken.

[Erik]

jvanhambelgium schreef op vrijdag 31 oktober 2008 @ 15:22:
De moment dat je de virtuele system in gebruikt hebt moet het normaal reeds werken !!
De Xen host zal de tags strippen en de frames/packets afleveren binnen de juiste VM die dan gekoppeld is aan de juiste VLAN, in uw geval zal je een ping kunnen doen naar 10.0.4.201 en niets anders.
Ik denk ook del dat de Xenhost zelf geen IP-adressen mag hebben, buiten een ander management IP-adres natuurlijk.

De laptop zit in een switchport en krijgt tag 4 als ie op de trunk (port 1) gaat richting Xen.
Xen stript de tag 4 eraf en forward de L2-frame naar de VM die hier gekoppeld zit en daar zal het ergens uit de TCP/IP stack gebolt komen).

HEB je al VM's opgezet of draaien er nog geen op deze moment en is deze "ip configuratie" eerder een Xenhost config file zelve ?


De Xen "host" ziet normaal (volgens mij dus...) zelf geen IP passeren (of maakt hier geen beslissingen op) dus je kan perfect verschillende VM's dezelfde IP-ranges laten gebruiken, doch kan je nooit onderling communiceren tussen deze VM's op deze manier zonder NAT te gebruiken.

Bedankt voor dit heldere verhaal! Maandag gaan we er weer mee aan de slag!

[PerfectPC]

jvanhambelgium schreef op vrijdag 31 oktober 2008 @ 15:22:
De moment dat je de virtuele system in gebruikt hebt moet het normaal reeds werken !!
De Xen host zal de tags strippen en de frames/packets afleveren binnen de juiste VM die dan gekoppeld is aan de juiste VLAN, in uw geval zal je een ping kunnen doen naar 10.0.4.201 en niets anders.
Ik denk ook del dat de Xenhost zelf geen IP-adressen mag hebben, buiten een ander management IP-adres natuurlijk.

De laptop zit in een switchport en krijgt tag 4 als ie op de trunk (port 1) gaat richting Xen.
Xen stript de tag 4 eraf en forward de L2-frame naar de VM die hier gekoppeld zit en daar zal het ergens uit de TCP/IP stack gebolt komen).

HEB je al VM's opgezet of draaien er nog geen op deze moment en is deze "ip configuratie" eerder een Xenhost config file zelve ?


De Xen "host" ziet normaal (volgens mij dus...) zelf geen IP passeren (of maakt hier geen beslissingen op) dus je kan perfect verschillende VM's dezelfde IP-ranges laten gebruiken, doch kan je nooit onderling communiceren tussen deze VM's op deze manier zonder NAT te gebruiken.

mooie uitleg maar totaal naast de questie...
als je 2 interfaces hebt in eenzelfde subnet zal je altijd een preferenced interface hebben om verkeer naar dat subnet uit te sturen. welke interface dat is kan je nakijkenin de route tabel van je host (server in dit geval).
die route tabel houdt ook in geen geval rekening met vlan tag's, die komen er nl pas bij op je L2 laag in de NIC, je OS is hier helemaal niet van bewust op L3...
je kan dit dan ook maar op 1 manier oplossen: door in je route tabel op je host een statische route te maken naar je beide clients.

[Erik]

Het is overigens voor elkaar. Inderdaad wijzen we nu op de hostserver geen ip-addressen meer toe aan de verschillende vlans.

Daarnaast hebben we een custom xen networking script die bij het starten van een machine automatisch een bridge creëert die overeen komt met het nummer van het vlan. Deze bridge wordt gekoppeld aan de betreffende vlan. De bridge wordt als adapter opgenomen in de XEN config.

Iedereen bedankt voor het meedenken!

[TrailBlazer]

PerfectPC schreef op zondag 02 november 2008 @ 02:05:
[...]

mooie uitleg maar totaal naast de questie...
als je 2 interfaces hebt in eenzelfde subnet zal je altijd een preferenced interface hebben om verkeer naar dat subnet uit te sturen. welke interface dat is kan je nakijkenin de route tabel van je host (server in dit geval).
die route tabel houdt ook in geen geval rekening met vlan tag's, die komen er nl pas bij op je L2 laag in de NIC, je OS is hier helemaal niet van bewust op L3...
je kan dit dan ook maar op 1 manier oplossen: door in je route tabel op je host een statische route te maken naar je beide clients.

klinkt allemaal leuk maar een Cisco router weigert dat gewoon te configureren als je het probeert. Een juniper doet ongetwijfeld hetzelfde. Overlappende subnets op een device werkt gewoon niet.

[bazkar]

Overlappende IP plannen met VLAN's kunnen wel, zolang er idd maar geen adressen op de router gezet worden en deze router het verkeer tussen de VLANs niet hoeft te routeren.
Het is prima mogelijk om 4 VLANs op te zetten met beide als IP plan 10.0.0.0/24, met ieder bv. hun eigen DHCP server. Maar slechts 1 van die 4 VLAN's mag dan maar een adres op de router hebben. Dit VLAN wordt gerouteerd. De overigen werken wel (je krijgt prima een IP adres als je in dat VLAN hangt), maar kunnen onderling niet communiceren (en ook niet met het VLAN dat wel gerouteerd wordt).

[Verwijderd]

TrailBlazer schreef op zondag 09 november 2008 @ 15:14:
[...]

klinkt allemaal leuk maar een Cisco router weigert dat gewoon te configureren als je het probeert. Een juniper doet ongetwijfeld hetzelfde. Overlappende subnets op een device werkt gewoon niet.

Tenzij je uiteraard met VRF's werkt , maar dat is volgens mij niet wat TS wilt.