Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I shall attempt to explain an issue I have encountered -

I have a VM running on esx 4.1 with an interface connected to VLAN800 via an access port on a cisco 3750. It runs linux - kernel 2.6.24, and has about 5 to 10 Mbit of chatter on 10.10.0.0/16 and various multicast addresses to look after.

I needed to isolate certain devices from certain other devices on the network, with all of them having to talk to that one VM. No, the address space can't be separated, nor can the networks be easily vlan'd apart. The software on the VM listens to one interface only. Private vlans appear to be the way to go.

So as a test, I built a bridge on the VM that globs together the vlans as needed. All good, everything works as expected. But occasionally (sigh) there's some latency that trips up a couple of profinet devices on the network because, you know, you're not really supposed to trunk real-time protocols around the place willy-nilly.

I shift it to our test/backup server - works nicely, but I don't want it to be running on the test server as we muck around with that a lot.

So I says to myself, "I'll put it on a new VM for testing and tweaking." I download a small linux distro with kernel 3.3, and install as a new VM with a the vlans as separate interfaces for testing.

  • I power up the testing VM - ok.
  • I bring up all the separate interfaces - ok. I can ping the production VM, see all sorts of traffic going past with tshark, etc.
  • I build a bridge and put the primary vlan on it - the production VM running 2.6 immediately loses its multicast traffic - Unicast is fine. (?)
  • I shut down the bridge - still no multicast traffic (!?)
  • I power-cycle the production VM(!?!?) - multicast traffic returns.
  • I trunk everything into the testing VM and create vlan interfaces under linux instead - same result, as soon as I start the bridge.... no multicast on the production VM.

Ok, so I take a break and leave things alone. I decide to play with a couple of ubiquiti bullet radios - I'm testing various firmware as a side project. I flash a radio with Open-wrt-12.09. I enable a trunk on a port on a cisco on our network so I can muck around with multiple vlans and SSIDs

  • I power up the radio and connect - ok.
  • I create a vlan interface from the trunk.... the same vlan as the production VM wayyyyy over there, three cisco routers away. Ok.
  • I bridge the vlan interface to the wifi interface and immediately get a phone call. The production VM has (suprise!) lost its multicast traffic. Again, nothing comes back until I power-cycle the VM.

What the hell is going on?

share|improve this question
1  
I know what's going on. You're losing the ability to multicast when you power up a specific VM. Sounds weird, but that's what happening. Only thing I can think of is an IP address conflict - is the VM maybe configured with the same IP as a piece of network gear (either physical or virtual), maybe? –  HopelessN00b Sep 18 '12 at 3:03
    
It's not just that VM. The bullet wifi radio is a separate, real-world piece of hardware a couple of router hops away on the trunk and it kills that VM as well.... it's a bit mystifying. I can't really go around killing that production VM too often to try and debug it, I'll have to see if I can replicate it with another VM. –  David Griffith Sep 18 '12 at 5:44
    
Nasty. I still say it sounds a lot like you've got a VM that's creating an IP conflict with a piece of network gear, (or is the bridging myabe causing a routing loop, or something similar?) but I'd say it's time to bust out wireshark (or your favorite) and do some real-time packet capturing to try to figure out what's going on. –  HopelessN00b Sep 18 '12 at 10:45
add comment

1 Answer

Further investigation on a test setup shows that its not related to the VM or ESx - what appeared to be the VM losing multicast was actually the WinXP clients losing multicast - restarting the VM 'fixed' the clients. I'll raise a separate question as it appears to be an interaction with the bridging code in linux 3.3 vs XP's response to igmp queries.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.