It's possible I've gleaned some correct information from your few clues about your situation.
Possible topology: Your highly-available firewalls are connected to Switch 1 (SW1). The firewalls expect other devices to send to one or the other firewall using a multicast address, in a similar fashion to the way hosts send to the HSRP address, (even though that's not a multicast address). Servers are connected to switch 2. The servers are supposed to send to the multicast address associated with the firewall. Is that close to right? Am I getting closer? It's also possible that I have figured out the problem you are trying to solve from your few clues about the problem, although not necessarily a solution. Possible problem: When the servers send to the multicast address, Switch 2 floods the packet out all ports because it doesn't know which port to use. Your original question was whether you could hard code a CAM entry for the multicast address on Switch 2 for the port that acts as a trunk to Switch 1. Your goal for doing this is to make the multicast only flow over to that port. I think that would work!? Did you try it? The other solutions that might work are IGMP snooping, CGMP, or just a better arrangement of VLANs so that the switch forwards more appropriately. You should also ask yourself whether this flooding is really a problem, however. Does it use much bandwidth? Probably not? (What are the servers sending to the firewall?) Does it disturb the recipients who incorrectly receive it? Probably not. If they are using good NICs, the NIC will know that the host didn't register to receive the multicast and trash it, without disturbing the CPU of the host. In a previous message, you send us to a URL that showed duplicate multicasts arriving because of a loop. Is that really what's happening? It's not what you seem to be saying in this message. If it is happening, then that is a serious problem. You need to avoid a loop by fixing either the physical or logical topology with properly formed LANs or VLANs. Priscilla Hitesh Pathak R wrote: > > Pls see inline text for answers. > > regds > Hitesh > > -----Original Message----- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 04, 2003 4:02 AM > To: [EMAIL PROTECTED] > Subject: Re: Catalyst 6xxx switches and 2 firewall in clust > [7:60235] > > > Can you help us understand the situation better? Thanks. > See some questions inline. > > l0stbyte wrote: > > > > Hitesh Pathak R wrote: > > > > > Dear Group, > > > > > > Need your help in setting up the following :- > > > > > > SETUP :- There are 2 core switches SW1 & Sw2 (connected back > > to back with > > > both > > > the SUP GE ports Fiber uplink (Channeld and trunk). On one > of > > the switch > > > (SW1) > > > I have 2 firewalls connected in cluster mode. For this > > clustered > > > firewall I > > > have bind the multicast mac address on the switch SW1 as the > > recommended > > > method by the firewall vendor by the command (set cam > > permanent ). > > On SW1, you have a permanent cam entry for the multicast > address used by the > firewall cluster? Why? How is that permanent entry used and why > is it > necessary? Sorry if this is a stupid question, but I think it > will help us > understand what you are trying to accomplish. > > Ans :- I don't have much idea about the firewall config but > what I was told by > the firewall guy that When you configure the dual firewall is > HA mode (High > availability) it generates a common MAC address for both the > firewall so that > both can be reached via single mac address (something similar > to HSRP ). The > actual mac address on that port is not getting learned by the > switch. Also one > static ARP entry is added on MSFC for mapping this MAC and the > virtual > firewall IP address. > > > > > > > Now the problem faced here is since they have only bind the > > mac > > > address to 2 > > > ports on SW1 (switch one ONLY) there seems to be some > > multicast packets > > > flooding on my second core switch SW2 for that multicast > > address. > > Switches flood multicasts by default. So it makes sense that > the multicast > is flowing over to SW2 also. > > > > > > > The customer wants to stop this broadcast from hapening on > > 2nd switch > > > SW2 and > > > hence wants to bind the same multicast mac address on the > 2nd > > Switch > > > with the > > > trunk ports going to SW1 from SW2. > > The multicast will come across the trunk, so you should be able > to put a > permanent cam entry mapping the multicast address to the trunk > port. But > what problem will that solve? Are you trying to stop the > multicast from > flowing out the other ports on SW2? How does a permanent cam > entry help with > that? > > ANS :- At present the servers connected to my 2nd core switch > are not able to > reach to that multicast mac address and so as the broadcast. I > even looked in > to the cam table on the 2nd switch to see if that shows the cam > entry but > couldn't find it. > > Maybe you should look into CGMP or IGMP snooping. They can stop > multicasts > on switches, if the applications send IGMP joins. > > Anyone else have any suggestions or understand his situation? > > Priscilla > > > > > > > Has anybody faced similar situation ?? Is this configuration > > > supported. Can I > > > bind the cam entry to my trunk port on the SW2 as well with > > the same > > > multicast > > > mac address?? > > > > > > Many thanks in advance. > > > > > > Thanks > > > Hitesh > > > DISCLAIMER: > > > Information contained and transmitted by this E-MAIL is > > proprietary to > > > Wipro > > > Limited and is intended for use only by the individual or > > entity to > > > which it > > > is addressed, and may contain information that is > privileged, > > confidential > > > or exempt from disclosure under applicable law. If this is a > > forwarded > > > message, the content of this E-MAIL may not have been sent > > with the > > > authority of the Company. If you are not the intended > > recipient, an > > > agent of > > > the intended recipient or a person responsible for > > delivering the > > > information to the named recipient, you are notified that > > any use, > > > distribution, transmission, printing, copying or > > dissemination of this > > > information in any way or in any manner is strictly > > prohibited. If you > > > have > > > received this communication in error, please delete this > mail > > & notify us > > > immediately at [EMAIL PROTECTED] > > is it a checkpoint FWs cluster? > DISCLAIMER: > Information contained and transmitted by this E-MAIL is > proprietary to Wipro Limited and is intended for use only by > the individual or entity to which it is addressed, and may > contain information that is privileged, confidential or exempt > from disclosure under applicable law. If this is a forwarded > message, the content of this E-MAIL may not have been sent with > the authority of the Company. If you are not the intended > recipient, an agent of the intended recipient or a person > responsible for delivering the information to the named > recipient, you are notified that any use, distribution, > transmission, printing, copying or dissemination of this > information in any way or in any manner is strictly prohibited. > If you have received this communication in error, please delete > this mail & notify us immediately at [EMAIL PROTECTED] > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60362&t=60235 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
