cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2200
Views
0
Helpful
0
Replies

Cisco 6500 Switch - Multicast NLB for CAS Array in an Exchange 2010 DAG enviroment

mitchen
Level 2
Level 2

This is a classic case of things not being planned out properly but anyhow:

Our server guys implemented a new Microsoft Exchange server environment recently.  We then noticed a surge in traffic to all switch ports which us network guys investigated.  Seems the Exchange servers were set-up in NLB Unicast mode and as a result NLB traffic was flooded to all switch ports.

So, after a quick brainstorm, we decided Multicast NLB was the way to go - the server guys changed to Multicast mode and we configured our Cisco 6506 switch accordingly:

Static ARP:

arp [virtual ip] [multicast MAC address] ARPA alias            

Static MAC-Address-entries:

mac-address-table static [multicast MAC address] vlan 10 int Gig2/5 Gig3/10 disable-snooping

So far, so good?  Now, email seems to be working ok so there is no major panic.... yet!

But what we have noticed is that, although a continuous ping to the virtual IP is fine with no timeouts whatsoever, continuous pings to the IPs of the individual NLB members show a large number of timeouts (one of the addresses seems to be worse than the other, not sure if any signicance in that?)

Apparently, this wasn't the case in unicast mode - there were no timeouts to those addresses?

Anyway, can anyone advise a) whether our switch set-up is indeed correct (I believe it is from the documentation I've read) and, if so, any pointers as to what could be causing the timeouts to the NLB members and whether this is something that should be a worry?  (As I say, email appears to be working so far but whether we are likely to experience issues or whether there are issues that just haven't been noticed yet it's too early to say - I'd rather get to the bottom of this before it becomes a problem though!)

The one thing I did notice was that the switch shows the same MAC address for both NLB members, whereas I had expected them to have their own unique MAC address (and then, of course, the "multicast MAC address" for the virtual IP - which I do see, as expected) when operating in this mode.

Any advice on this would be appreciated (the moral of this story is that this should all have been planned and tested properly in advance rather than reacting after the event!)

Thanks.

0 Replies 0
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco