This post is more than 5 years old
8 Posts
0
3772
December 14th, 2016 06:00
MS NLB, Dell 8024f and my multicast nightmare
I'll keep this short as there isn't a lot to it.
I have an ESX cluster (8 servers) connected to a 8024f. There are 2 vlans that the ESX cluster operates on, I am able to connect to both of them from my desktop. The switch has a very basic config, mostly trunk all ports to ESX and 4 ports ether-channeled to the core Cisco. I have been tasked with getting MS NLB multicast working, but I've had a %$&& of a time doing it. For the most part I've enabled multicast but I'm not having any luck so I went further to also enable IGMP ... then I made it a querier. At the end of the day I didn't get anywhere except one screen (MFDB IGMP Snooping table) that seems to tell me that on my one VLAN there are 2 dynamic "Network Assist" mac address for two different ports (labeled under "Table" and those same mac addresses are listed under "Forbidden ports"
What am I doing wrong? Funny thing is this was working (I admit with a lot less of a config before today) a week ago until one of the VMware engineers tweaked with an interface
Update- I wrote all this yesterday but it seems that it was never posted. Sense then I decided to remove all the commands from the switch that I entered in for this and start from scratch. I will be creating a port on the switch and assigning my laptop to it. If I can connect to the cluster then I’ll know that the problem is at the core Cisco switch… and I’ll be asking that question here as well. I made no special changes to the core when connecting this switch for multicast, considering the core is already running multicast I didn’t think I had to
console#show run
!Current Configuration:
!System Description "Powerconnect 8024F, 4.2.0.4, VxWorks 6.6"
!System Software Version 4.2.0.4
!Cut-through mode is configured as disabled
!
configure
vlan database
vlan 46-47,442
ip igmp snooping 442
ip igmp snooping querier 442
ip igmp snooping querier 442 address 10.168.47.5
ip igmp snooping querier election participate 442
vlan routing 442 1
vlan routing 47 3
exit
stack
member 1 2 ! PC8024F
exit
logging file debugging
ip routing
ip default-gateway 10.168.47.1
ip route 0.0.0.0 0.0.0.0 10.168.47.1 253
interface vlan 47
exit
interface vlan 442
ip address 10.168.47.5 255.255.255.0
ip igmp
exit
mac address-table multicast forward-all vlan 442
ip igmp snooping
ipv6 mld snooping
ip igmp snooping querier
ip igmp snooping querier address 10.168.47.5
ip multicast
ip igmp
ip pim dense
!
interface Te1/0/1
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/2
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/3
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/4
duplex full
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/5
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/6
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/7
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/8
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/9
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/10
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/11
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/12
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/13
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/14
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/15
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/16
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/17
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/18
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/19
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/20
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/21
channel-group 1 mode on
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/22
ip igmp snooping
switchport mode trunk
exit
!
interface Te1/0/23
channel-group 1 mode on
switchport mode trunk
exit
!
interface Te1/0/24
switchport access vlan 442
exit
!
interface port-channel 1
switchport mode trunk
exit
decaturfamilytx
8 Posts
0
December 14th, 2016 06:00
-Update
I added my laptop on port 24, assigned it an IP in both VLANs and I get the same result, the cluster works in VLAN 442 but not in 47. I can only assume that it won't work in any other vlan aside from 442. So I'm still not able to route multicast packets
decaturfamilytx
8 Posts
0
December 14th, 2016 08:00
-Update
I discovered another issue that might be related. I decided to isolate the cluster and my laptop so I could work on this problem without talking to the core, thinking if I could resolve it here then perhaps I could move to the core for the solution. So I added the following to the config (some of it is dub)
ip routing
int vlan 47
ip address 10.214.47.25 /24
int vlan 442
ip address 10.168.47.5 /24
no ip route 0.0.0.0 0.0.0.0 10.168.47.1
I then assigned both the cluster and the laptop a default gateway pointing to their respected vlan IP. No vlan routing.
The "sho ip route" shows the two directly connected networks. I wonder if the problem isn't with the virtual switch????
decaturfamilytx
8 Posts
0
December 14th, 2016 12:00
Wow!! It doesn't support MS NLB Multicast? Is there another solution then? I can't rightfully go to the directors and say "Sorry your going to have to scrap that 10k switch you bought for this environment"
And I can't use Unicast as it causes problems with VMware vmotion
decaturfamilytx
8 Posts
0
December 14th, 2016 13:00
<----- is absolutely blown away that this switch doesn't work with MS NLB multi ...... but!?!?! How did it work for the couple weeks I had it configured as IGRP Multi??
And I've made quite a bit of changes to that config so the interfaces are setup correctly... I wouldn't worry about it, getting this NLB running in Multicast is the big problem
Simlinc
1 Rookie
•
17 Posts
0
December 15th, 2016 05:00
I feel your pain. We had a similar issue in our environment working fine for some time.
You may have had similar to us in that the online system underlying mac address was learnt in the switch infrastructure and not the clustered/ multicast mac address. So we were never actually using the multicast configuration.
Hope that makes sense.
decaturfamilytx
8 Posts
0
December 15th, 2016 06:00
I ended up reporting all this to the directors yesterday and it looks like they've decided to scrap the cluster. Sadly it doesn't look good on me as I told them it would work, I set it up and it did for awhile and then now I've got to tell them it doesn't. LOL Such as life I suppose
But thank you for getting me this info