09-14-2015 04:13 AM - edited 03-08-2019 01:45 AM
Hi All
Someone knows why Cisco switchs doesn't flood cdp/vtp packets on entire broadcast domain ?
In my understanding a switch should perform flooding of Multicast packets out all port but with cdp/vtp packet it doesn't happen.
Logically it is correct but I don't understand how device does it.
Igmp, Igmp snooping, Cgmp should refer to trasmission of layer 3 multicast and however.
If I search 0100.0ccc.cccc inside multicast cam I don't see anything but cdp, however, works.
With L2PT a switch can flood cdp packet but in transparent way and without sending its own cdp packets.
Is there a range of layer 2 multicast address that Cisco (or/and other vendors) doesn't flood trasparently ?
Thankyou in advance
Daniele
Solved! Go to Solution.
09-14-2015 04:53 AM
Hi Daniele,
Someone knows why Cisco switchs doesn't flood cdp/vtp packets on entire broadcast domain ?
This is because for Cisco devices, these protocols are neighbor-to-neighbor protocols and are not intended to be flatly received by all Cisco devices in a broadcast domain. The reason these messages are multicast is that there can be a non-Cisco device placed between two Cisco switches, and Cisco attempts to treat such interconnections simply as shared segments similar to hubs. As non-Cisco devices flood protocols such as CDP, VTP, DTP, or PVST+, these messages can get across such devices easily but will be delivered as if the Cisco devices were connected to a common hub.
In my understanding a switch should perform flooding of Multicast packets out all port but with cdp/vtp packet it doesn't happen.
That is correct - once again, this is because CDP and VTP are neighbor-to-neighbor protocols to Cisco devices. This is not a rare occurrence, by the way. Even with standard 802.1D STP, BPDUs are multicasted, but switches that speak STP will not flood them - instead, they will process them on a port-by-port basis and each switch will forward its own BPDU it has originated itself.
Logically it is correct but I don't understand how device does it.
It is a combination of filtering implemented in the switching matrix, and pointing the PDUs of these protocols to the CPU of the switch. Have a look at the output of the show mac address-table in your switch and check the first set of MAC address entries - learned on "all" VLANs, marked as STATIC, pointing to CPU as the forwarding port. This output is the list of group MAC addresses that are forwarded to the CPU, and that are at least considered for being un-flooded (some of them, e.g. the broadcast MAC address, are still flooded).
Best regards,
Peter
09-14-2015 04:53 AM
Hi Daniele,
Someone knows why Cisco switchs doesn't flood cdp/vtp packets on entire broadcast domain ?
This is because for Cisco devices, these protocols are neighbor-to-neighbor protocols and are not intended to be flatly received by all Cisco devices in a broadcast domain. The reason these messages are multicast is that there can be a non-Cisco device placed between two Cisco switches, and Cisco attempts to treat such interconnections simply as shared segments similar to hubs. As non-Cisco devices flood protocols such as CDP, VTP, DTP, or PVST+, these messages can get across such devices easily but will be delivered as if the Cisco devices were connected to a common hub.
In my understanding a switch should perform flooding of Multicast packets out all port but with cdp/vtp packet it doesn't happen.
That is correct - once again, this is because CDP and VTP are neighbor-to-neighbor protocols to Cisco devices. This is not a rare occurrence, by the way. Even with standard 802.1D STP, BPDUs are multicasted, but switches that speak STP will not flood them - instead, they will process them on a port-by-port basis and each switch will forward its own BPDU it has originated itself.
Logically it is correct but I don't understand how device does it.
It is a combination of filtering implemented in the switching matrix, and pointing the PDUs of these protocols to the CPU of the switch. Have a look at the output of the show mac address-table in your switch and check the first set of MAC address entries - learned on "all" VLANs, marked as STATIC, pointing to CPU as the forwarding port. This output is the list of group MAC addresses that are forwarded to the CPU, and that are at least considered for being un-flooded (some of them, e.g. the broadcast MAC address, are still flooded).
Best regards,
Peter
09-14-2015 06:13 AM
Thankyou very much, very complete answer !!
11-27-2019 04:41 PM
Hi Peter,
If the switch does not flood CDP, VTP, DTP, or PVST+ frames out all ports, can you please explain how the switch decides which ports to send CDP, VTP, DTP, or PVST+ frames out to?
CDP floods its advertisement frames out, but how does it know on which port(s) Cisco equipment lives? If you tell me that CDP floods its advertisements out of ports that have Cisco MAC addresses, we run into the issue of "nobody's talking to each other because they are not aware of each other's presence".
08-16-2022 01:36 PM - edited 08-16-2022 02:37 PM
A switch decides which ports to send PDU frames out of dependent upon how the software (IOS, IOS-XE, NX-OS, IOS-XR, etc) is programmed to facilitate the protocol as well as how it may be configured other than default. This may seem like an obvious statement but is my way to say that we have to think of each protocol and its PDUs independently and not think of them as much as a group of protocols which use some but not all similar methods.
Because "flooding" is a term which is used in different ways with different protocols, at least for the purposes of these link-local Layer 2 PDUs, I should first say that I like to think of all of these PDU frames in the following terms.
It may help to think of this in terms of what is the purpose of the protocol, who is the intended audience of each type of PDU, and is each exchange of information simply one device shouting out that it IS something or is connected to something versus whether the two connected devices only exchange information after a session is established between them. For example, with CDP we want to understand "who is my neighbor and what are its capabilities?" which is NOT the same as saying "who is everyone in my neighborhood who can possibly hear this message I'm shouting out a window (interface)?" Because the Cisco Discovery Protocol is intended to discover the adjacent device, CDP is meant to be announced by DeviceA to a directly-connected neighbor, DeviceB, for its own consumption. In reverse, it would be "neighborly" for DeviceB to also announce its addresses and capabilities, but I would encourage looking at these as two completely unrelated transmissions. By that, I mean that if DeviceB does not announce anything it only means DeviceA is simply unaware of what is out that A-to-B interface from a CDP perspective. Also, it isn't expected that DeviceB will forward out information about DeviceA to Devices C, D, or E, simply because that is not the purpose of CDP nor of LLDP. For this reason, I might not word the switch behavior of CDP as "flooding its advertisement frames out" and instead say it advertises only its own information out of every connected interface, by default. One more point and I'll leave CDP alone: devices which do not process CDP frames such as hubs, unmanaged switches, and even some managed non-Cisco switches will flood received CDP frames out to multiple attached interfaces but that is not a design criteria of CDP just a fact that those devices see these only as Ethernet frames needing to be forwarded and they have no way to determine where to forward, so they flood them everywhere.
In the case of DTP, it is to establish a trunk with a directly-attached device, so it is not meant to be forwarded beyond the next device, meaning it is meant for the neighbor rather than the neighborhood.
Because STP is to establish a total topology of a broadcast domain, it would serve no benefit for a device to blindly forward PDUs received on one interface out of any other interface and so, it is imperative that each device receives, processes, then originates a resulting new PDU to transmit out all but the interface towards the root bridge, aka the root port.
At a very minimum, because an Ethernet frame does not have any field for a time-to-live (TTL) value, at least for the Layer 2 PDUs, it is required that some device eventually takes a frame off of the segment so that it doesn't infinitely loop around. For some protocols, receipt of a L2 PDU by the same device which originated that PDU will be cause for the device to drop the PDU even if the default behavior would otherwise be to forward or flood it to other devices. This is under the assumption that if I am hearing back my own announcement, it needs to go no further. For most protocols, even without any explicit TTL visible within the PDU, the behavior by devices will be to effectively treat them as though there is a TTL=1, although it varies as to whether "one hop" means one device, one bridge or switch, or one L3 segment.
I hope this helps, albeit an old thread.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide