Multicast layer 2 flooding and cdp/vtp

[lnrdnl78d]

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

[Peter Paluch · Accepted solution]

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

[lnrdnl78d]

Thankyou very much, very complete answer !!

[Sam Brynes]

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".

[rofegley]

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.

• Device receives a PDU, then
  • Device only consumes the PDU information without forwarding anything to anyone
    • Receipt of CDP and LLDP PDUs, when LLDP is globally enabled in this latter case
  • Device consumes the PDU information and originates a new PDU to send on to other devices
    • STP
  • Device blindly forwards it out any/all other connected ports
    • Possibly VTP, although VTP may behave more like STP listed above?
  • Device drops the PDU without consuming it
    • Some protocols for which the device, or the interface, is not configured, although there are often exceptions
• Device originates a PDU, by
  • sending PDU only out a specific interface or a specific group of interfaces
    • Examples?
  • sending out all connected interfaces
    • Transmission of CDP PDUs except where disabled on an interface or disabled globally
    • STP PDUs, through every interface configured as a switchport and where the switchport participates in one or more VLANs which have STP enabled (on by default), although the contents will change as more is known about the topology especially as a root bridge is elected

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.