Routeringsprobleem met XEN VM

[MadEgg]

Ik heb al maanden een (Debian) server met XEN virtualisatie in het datacentrum hangen.

De host heeft een IP-adres .161, ik heb nog wat IP-adressen voor VM's (allen Debian), waaronder eentje .162

Dit draaide tijdenlang prima, zonder enige klachten. Onlangs heb ik ook niets aan de configuratie veranderd.

Nu werd ik vanochtend gecontacteerd door de colocation-boer dat mijn VM op .162 geconfigureer is om .150 af te handelen, terwijl dat IP adres niet aan mij toegewezen is. Dit veroorzaakte enige problemen op het netwerk.

Echter, ik kan niets vinden wat hierop duidt. Hij is statisch geconfigureerd op .162 middels /etc/network/interfaces en als ik "ip addr" draai komt er ook niets anders uit. Ook de host en de overige VM's zijn allen statisch geconfigureerd op alleen het juiste IP-adres, en ik kan geen enkele referentie vinden aan het .150 IP-adres.

Echter, als ik vanaf de VM host een traceroute draai naar .150 dan wil hij dit inderdaad versturen via de .162 VM.

Hoe kan dit nu? Hoe komt 'traceroute' aan zijn route, en hoe kan ik uitzoeken waarom hij in godsnaam meent dat mijn .162 VM gebruikt zou moeten worden om .150 te bereiken?

Alle suggesties zijn welkom! Als er stukje configuratie nodig zijn dan hoor ik wel wat ik moet posten.

[update]
Nog een beetje extra info, al vermoed ik niet dat dat relevant is. Ik heb op alle VM's nog een tweede interface (eth1) geconfigureerd met een privé LAN, met IP-adressen in de range 192.168.202.x/24. Dit om intern verkeer te faciliteren buiten de firewalls en internet om. Verder zijn alle VM's ook op de internet (eth0) interface geconfigureerd met een statisch IPv6 adres. Ook dit heeft altijd zonder problemen gedraaid.

[ Voor 18% gewijzigd door MadEgg op 03-09-2015 11:30 ]

[Bart]

Kijk eens naar de route/arp tabellen op alle machines (incl. Xen host). Zeggen die misschien iets over het .150 adres?

[Hero of Time]

En wat is de routing tabel dan? Is die 162 niet toevallig een gateway adres uitgegeven door de hosting partij? Is er geen MAC adres conflict? Andere netwerk dingen die je kan delen?

[om3ega]

Zijn de 2e interfaces van de private LAN ook op een fysiek andere virtual switch gekoppeld ?

[MadEgg]

Op de XEN dom-0:

code:

root@notax:~# ip route
default via xx.xx.xx.129 dev xenbr0 
xx.xx.xx.128/26 dev xenbr0  proto kernel  scope link  src xx.xx.xx.161 
192.168.202.0/24 dev xenbr1  proto kernel  scope link  src 192.168.202.1

Dit ziet er in orde uit. Op de VM is dit nagenoeg hetzelfde:

code:

root@obelix:~$ ip route
default via xx.xx.xx.129 dev eth0 
xx.xx.xx.128/26 dev eth0  proto kernel  scope link  src xx.xx.xx.162
192.168.202.0/24 dev eth1  proto kernel  scope link  src 192.168.202.10

Enige verschil dat ik zie is het andere source IP en andere interface, maar dat zou je verwachten gezien de configuratie. "arp" geeft niet veel interessants; een lijstje van de virtuele mac-adressen van de VM's met bijbehorende IP adres. Bovendien komt dit ook overeen met de overige VM's welke geen problemen opleveren.

Ik heb inmiddels de xenbr0, die met internet verbonden is, losgekoppeld van de betreffende VM, zodat hij de boel in het datacentrum niet meer in het honderd stuurt en de overige VM's weer bereikbaar zijn. Dit lijkt effectief, maar nu weet ik dus nog niet waar het probleem in de config zit en hij moet uiteindelijk wel weer verbonden worden.

[ Voor 3% gewijzigd door MadEgg op 03-09-2015 11:45 ]

[MadEgg]

om3ega schreef op donderdag 03 september 2015 @ 11:40:
Zijn de 2e interfaces van de private LAN ook op een fysiek andere virtual switch gekoppeld ?

De 2e interfaces zijn niét aan een switch gekoppeld. Ze zijn wel gekoppeld aan xenbr1, welke op zijn beurt weer is gebridged met de eth1 op de Xen host, maar hier zit geen netwerkkabel in. Ze zijn puur en alleen voor intern verkeer bedoeld.

Hero of Time schreef op donderdag 03 september 2015 @ 11:35:
En wat is de routing tabel dan? Is die 162 niet toevallig een gateway adres uitgegeven door de hosting partij? Is er geen MAC adres conflict? Andere netwerk dingen die je kan delen?

Zie nu pas je tweede regel. MAC adres conflict zat ik ook aan te denken; ze zijn per slot van rekening gegenereerd voor de VM's, en, in ieder geval voor de betreffende VM, statisch opgenomen in de XEN VM-config file. Echter, als ik die zou willen aanpassen, waarin dan?

Bij navraag bleek overigens de betreffende VM (.162 dus) verkeer voor méér dan alleen .150 naar zich toe te trekken, ook andere IP-adressen werden geclaimed waardoor het netwerk ontwricht werd. Het gaat dus niet specifiek om één IP-adres maar om het hele subnet.


Update
Na flink graven lijkt het om de volgende regels in /etc/sysctl.conf te gaan:

code:

net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.default.arp_accept = 1
net.ipv4.conf.default.proxy_arp_pvlan = 1

Deze zijn toegevoegd omwille van het configureren van een ipsec VPN-server mbv Strongswan. Deze hebben blijkbaar echter tot gevolg dat niet alleen clients via de VPN-verbinding proberen te routeren via deze VM, maar dat dit ook op het subnet geadverteerd wordt. Waar ik die wijsheid vandaan had weet ik niet; de VPN-verbinding werkt ook zonder deze regels, dus heb het nu gewoon uitgezet.

[ Voor 67% gewijzigd door MadEgg op 03-09-2015 13:01 ]