Virtueel IP "propagaten"

[Robert]

Heb een beetje een vaag probleem met de propagation van virtuele IP adresseen

Situatieschets:

Een aantal fysieke Xen servers met meerdere domU's. Op een aantal DomU's is een extra (virtueel) IP toegevoegd op de interface.

Als ik nu echter dat virtuele IP verwijder van de interface en op een andere server bijvoorbeeld toevoeg kan het enkele uren duren voordat de pakketjes daadwerkelijk de juist kant op vliegen. Mijn best inschatting is dat dit komt omdat het virtuele IP niets verzend naar de lokale switch en die dus de wijziging niet door heeft, tot hij een keer zijn IP<->MAC tabel ververst.

Wat wel direct werkt is als ik het IP adres als primair IP instel op de interface, dan wijst dat IP gewoon direct naar de juiste server. Dat is natuurlijk een niet zo handige oplossing, zeker omdat ik dingen soms geautomatiseerd wil over kunnen zetten.

Weet iemand hier een goede oplossing voor waardoor het IP direct naar de juiste server verwijst?

[WHiZZi]

Ik zou als ik jou was eens inlezen in Arp, want dat gaat hier fout (blijkbaar gaat je switch niet op snelle basis controleren welk macadres het IP adres heeft).

Er is een tooltje wat ik altijd gebruikte hiervoor, Arprelease. Het moet ook kunnen met het standaard arp-tooltje wat met standaard unix-based systems mee komt, maar ik durf niet te zeggen hoe dat moet (en arprelease $interface $ip_address is gewoon handig)

Wat je ook nog kan doen, is een virtueel interface maken (ifconfig ethX:0 address x.x.x.x netmask y.y.y.y up ), volgens mij wordt hier wel automagisch een ARP flush gedaan (you should try).

[Robert]

WHiZZi schreef op woensdag 29 juli 2009 @ 07:45:
Ik zou als ik jou was eens inlezen in Arp, want dat gaat hier fout (blijkbaar gaat je switch niet op snelle basis controleren welk macadres het IP adres heeft).

Er is een tooltje wat ik altijd gebruikte hiervoor, Arprelease. Het moet ook kunnen met het standaard arp-tooltje wat met standaard unix-based systems mee komt, maar ik durf niet te zeggen hoe dat moet (en arprelease $interface $ip_address is gewoon handig)

Wat je ook nog kan doen, is een virtueel interface maken (ifconfig ethX:0 address x.x.x.x netmask y.y.y.y up ), volgens mij wordt hier wel automagisch een ARP flush gedaan (you should try).

Het gaat om IP's die ik inderdaad toevoeg op de manier zoals je beschrijft (dus extra IP op interface). Ik zal eens kijken of ik met arp er wat beweging in krijg, lijkt me inderdaad in de goede richting zitten. Hoewel het toch raar blijft dat de switch (3com superstack) niet wat sneller refreshed dan eens per paar uur.

[Verwijderd]

Het is inderdaad ARP dat misgaat. Hoewel ik met vroege versies van Xen tegen het probleem aan liep dat iedere domU hetzelfde MAC address had.

Wat je wil doen is dat zodra een je een ip ergens up brengt, die (virtuele) machine een gratuitous ARP uit laten sturen zodat je switch het ip met een nieuw mac address associeert.

Als je domU's toch identieke mac's hebben dan kun je deze gewoon met ifconfig veranderen en zou je probleem meteen opgelost moeten zijn.

Alternatief als je een switch met management hebt kun je de arp timeout gewoon op 1 minuut zetten oid. Dit kan op een klein netwerk weinig kwaat.

[ Voor 13% gewijzigd door Verwijderd op 03-08-2009 11:47 ]

[Kippenijzer]

DomU's zelfde MAC is nogal kwalijk, gewoon allemaal een random (wel Xen Range) MAC adres statisch toekennen met een mac=<> in je vif regel in je config file voor iederen DomU. Debian Lenny doet dit tegenwoordig gelukkig standaard.

Verder is het trouwens 99% niet je fysieke switch, maar de bridge van je Dom0 die de ARP te lang onthoud .

[ Voor 19% gewijzigd door Kippenijzer op 31-07-2009 14:33 ]

[_JGC_]

1x je gateway pingen zou op zich voldoende moeten zijn om je MAC adres over het netwerk kenbaar te maken. Vaak duurt het even voor een MAC adres achter een bridge kenbaar wordt op het netwerk.

[TrailBlazer]

L2 switches weten helemaal niks van arp en ip addressen. Daarom zijn het L2 switches.

[gertvdijk]

Zoals Kippenijzer al zegt, als je gewoon de distroversie pakt en Xentools installeert gaat alles automagisch. Heel relaxed kan ik uit eigen ervaring zeggen.

[CyBeR]

TrailBlazer schreef op vrijdag 31 juli 2009 @ 21:38:
L2 switches weten helemaal niks van arp en ip addressen. Daarom zijn het L2 switches.

Ahem.

code:

ProCurve Switch 4204vl# sh dhcp-snooping binding 
  MacAddress    IP              VLAN Interface Time Left
  ------------- --------------- ---- --------- ---------
  0013d4-10bddd 10.0.1.124      100  B19       500      
  0016cb-a24174 10.0.1.69       100  B13       5232     
..

(Dit wordt ook gebruikt voor ARP protection, maar dat staat bij mij niet aan).

[ Voor 7% gewijzigd door CyBeR op 02-08-2009 15:18 ]

[TrailBlazer]

Ik had het ook specifiek over deze context. DHCP snooping is natuurlijk een heel ander iets.

[CyBeR]

TrailBlazer schreef op zondag 02 augustus 2009 @ 18:00:
Ik had het ook specifiek over deze context. DHCP snooping is natuurlijk een heel ander iets.

Klopt, maar ARP snooping kan in dit geval nog best in de weg zitten

[blokje1]

TrailBlazer schreef op vrijdag 31 juli 2009 @ 21:38:
L2 switches weten helemaal niks van arp en ip addressen. Daarom zijn het L2 switches.

Ahum:

quote: http://en.wikipedia.org/wiki/LAN_switching#Layer_2_switching

Layer 2 switching is hardware based, which means it uses the media access control address (MAC address) from the host's network interface cards (NICs) to decide where to forward frames.

Layer 2 switches weten dus wel MAC adressen.

[TrailBlazer]

CyBeR schreef op zondag 02 augustus 2009 @ 18:09:
[...]


Klopt, maar ARP snooping kan in dit geval nog best in de weg zitten

Iets zegt me dat de TS geen switch heeft waar deze feature is enabled. Het beste kan de TS natuurlijk even een ping sturen vanaf het virtuele ip adres naar de default gateway. Dan heeft de switch het ook meteen weer geleerd.

blokje1 schreef op zondag 02 augustus 2009 @ 21:02:
[...]


Ahum:

[...]


Layer 2 switches weten dus wel MAC adressen.

Ontken ik dat dan Ik zeg toch dat ze niks weten van ARP en IP addressen. ARP is een L3 protocol om een L2 adres te bepalen.
MAC adressen worden door een switch geleerd aan de hand van binnen komende pakketten. Als een switch niet weet achter welke poort een bepaald mac adres zit dan wordt dat pakket geflood over alle poorten behalve de poort waarom het pakket is binnengekomen.

[ Voor 44% gewijzigd door TrailBlazer op 02-08-2009 21:15 ]