We have one financial application, Whose SERVER sends L2/L3 BCAST (VLAN05) to the CLIENT (VLAN03) to communicate. We have only few CLIENTS on that SUBNET (vlan03) who really needs these BCAST from SERVER (VLAN05) but it is being recieved by all other hosts on that subnet (VLAN03).
What is best BET for this?
I was thinking to go for MCAST for those SERVER and CLIENT. Does appplication on the SERVER MUST support MCASTing to talk to CLIENTS? I mean MCASTing is it based on appication OR it can be configurabel on the switch or router for that given application? FYI: I was told by APPLICATION provide that they do nto support MCAST. What does it mean? (They could not answer it)
CGMP/IGMP/Static CAM entries will solve your flooding issue. MCAST by most all switches are seen as BCAST traffic and flooded within a VLAN so if you want only the joined client ports to recieve this traffic you'll need to make some changes. Here is a link describing CGMP/IGMP/and also talks about Static Cam entries.
Sorry about that. Forgot to answer that one. Yes, an application, to be a MCAST source, will have a MCAST capability within the Application itself for transmission as an MCAST stream. This stream will be sent to a certain MCAST group where clients will join this group, or others, to recieve this traffic. Routers and switches cannot make unicast traffic into MCAST, as your email was asking.
Once again Thx a lot! *** Our Fin App does not support any MCAST, Server strictly/explictly sends L2 broadcast address (FF:FF:FF:FF:FF:FF) /L3 broadcast (255.255.255.255) to its CLIENTS while exchanging information. ***
I guess in this case your solution (advise) to use IGMP/CGMP CAM approach would not work! Right?
That is correct. For all 1's BCAST at L2 and L3 I would, instead, advise your application personnel to find a more efficient way of using the application you speak of. There would be no way to stop the flooding, without breaking something else, of this application using these addresses. These are not MCAST addresses but BCAST and at layer 3 to get through a router you'd need to enabled ip directed BCAST, which is not at all recommended best practice.
As you are in the loop...I had posted related question yesterday *** Could you Pl answer that quickly....So I can be sure What I'm doing. ====
Q::: DSTIP=255.255.255.255, Does it get to NATIVE and AUX VLAN?
Jan 6, 2003, 2:18pm PST
Background: *** We have configured NATIVE (APP-CLIENT) and AUX (IPPHONE) VLAN on the CAT4000 switch port. One financial application whose APP-SERVER connected to CAT6509, ONLY sends BCAST to its APP-CLIENTS.clients. (Note: App. does not suppot MCAST )
1. APP-SERVER in VLAN05 (192.168. 184.X) is connected to CAT6509
2. APP-CLIENTS are directly connected to the IP Phone and IP Phone is directly connected to theCAT4000 switch port. CAT4000 switch has native VLAN03 (10.10.1.0) and AUX VLAN99 (192.168.99.) for IP Phone.
3. CAT6509 is configured to forward BCAST from APP-SERVER (VLAN05) to APP-CLIENT (VLAN03) on CAT4000.
4. CAT6509 and CAT4003 has uplink GIG trunk between them.
5. As I mentioned, We have IP Phone who are in VLAN99.
6. CAT6509 is forwarding BCAST message with DSTIP=255.255.255.255
7. CAT6509 has L2 BCAST= FF:FF:FF:FF:FF:FF
1. Does my Phone get affected who is on the auxilary vlan99 of the switch port , who has a native vlan03 and CAT6509 is forwarding BCAST from APP-SERVER to APP-CLIENTS in VLAN03? As I mentioned, IP Phone and APP-CLIENT are on the different VLAN BUT are on the same Physical port. I mean both VLAN use totoal port BW for RX traffic.
2. It bothers me becuase I see FF:FF:FF:FF:FF:FF/255.255.255.255 as a DEST IP Addrress for APP-CLIENT.
3. IP Phone forwards BCAST message to the As APP-CLIENT who is directly connected to the IP Phone, Which I think would degrade performce on the
4. I have collected SPAN BUT how could i verified that BCAST is intended for APP-CLIENT in VLAN03 not for the IP Phone who is on VLAN99. As those packets has only L2/L3 BCAST address.
Your phones, if on NATIVE VLAN, would not get the BCAST if they were not sourced on the NATIVE VLAN provided your phones were not trunked. If they (BCAST) were sourced on the NATIVE VLAN then all would get this.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...