Hello Jon.

I know that it is considered the bible on LAN switching, probably I am a little confused.

Why that second book says "as a special case" then?

The bible says "it updates the VLAN information and creates updated messages to other neighbor Catalysts"

I had thought that the author said the advertisement was intercepted, processed and not forwarded in a first

moment, forwarded only the updated messages created in a second moment.

Everyway, this problem let me thinking about broadcast and multicast.

When I read that, in the respect of switch forwarding logic, broadcasts and multicasts are flooded, I have begun to

think about the arp request the router attached to the switch forward when I telnet the switch from a remote network.

That arp request is a broadcast but the target is the switch. When the switch processor see that the broadcast

is an arp request directed to him, I had thought that there is no need to forward that broadcast. So I have begun

thinking that also all broadcasts are not always forwarded, so the multicasts.

In real world, what the switch do with an arp request broadcast whose it is the target?

speculor_cisco wrote:

Everyway, this problem let me thinking about broadcast and multicast.
When I read that, in the respect of switch forwarding logic, broadcasts and multicasts are flooded, I have begun to 
think about the arp request the router attached to the switch forward when I telnet the switch from a remote network.
That arp request is a broadcast but the target is the switch. When the switch processor see that the broadcast
is an arp request directed to him, I had thought that there is no need to forward that broadcast. So I have begun
thinking that also all broadcasts are not always forwarded, so the multicasts.
In real world, what the switch do with an arp request broadcast whose it is the target?

When the routers arps out for the switch IP it is indeed a broadcast at layer 2. That broadcast is sent to all ports in the vlan. All devices in that vlan see the broadcast but only the switch responds because it has the correct IP. But that doesn't mean that all the other devices in that vlan don't see the broadcast because they do see it. They just don't respond because the target IP does not belong to them.

At L3 the target may be the switch but at L2 an arp requests target is all devices in that vlan.

Note that multicasts are slightly different in that if you have IGMP snooping or CGMP and have an IGMP querier the packets are only forwarded to those devices that have registered an interest in that multicast group. If you aren't running IGMP snooping/CGMP then a multicast is treated as a broadcast at L2.

Jon

Thanks for the answer.

So, if the switch is an access layer switch with many computers attached, the switch floods the

arp request to those computers knowing that the arp request is not intended for them.

I thought that the switch logic could be:

1. I have received a broadcast frame.

2. As this broadcast frame could interest me, let me look what type of message it is.

3. If I am the only interested to this broadcast, I do not forward the broadcast.

4. If I am not interested to this broadcast or I am not the only interested, I do forward the broadcast.

May be it was not worth.

Is it possible that only in management VLAN or VLAN 1 multicast and broadcast traffic need to be processed?

In "Best practices for Catalyst ..." I have found:

"The primary concern over the use of VLAN 1 for user data is that the Supervisor Engine NMP in general does

not need to be interrupted by much of the multicast and broadcast traffic that is generated by end-stations.

Older Catalyst 5500/5000 hardware, the Supervisor Engine I and Supervisor Engine II in particular, has limited

resources for dealing with this traffic, though the principle applies to all Supervisor Engines."

It seems that, only in particular vlans, multicast and broadcast must be processed, in user data vlans broadcast and

multicast can be forwarded without processing because they are not intended for the switch.

So, I could say:

1. The switch supports K vlans.

2. M vlans could travel multicast and broadcast frames that the switch must process.

3. N vlans do not travel multicast and broadcast frames that the switch must process, vlans called "user data vlans".

4. K = M + N.

5. If a multicast or broadcast frame arrives to a port belonging to the M vlans, the switch floods it and process it.

6. If a multicast or broadcast frame arrives to a port belonging to the N vlans, the switch floods it only.

I thought, if this scheme make sense, that in the point number 5 the switch, as it must process the frame, has the

possibility to decide if the frame must be flooded or not.

What do you think?

Thanks.

speculor_cisco wrote:
Thanks for the answer.
So, if the switch is an access layer switch with many computers attached, the switch floods the
arp request to those computers knowing that the arp request is not intended for them.
I thought that the switch logic could be:
1. I have received a broadcast frame.
2. As this broadcast frame could interest me, let me look what type of message it is.
3. If I am the only interested to this broadcast, I do not forward the broadcast.
4. If I am not interested to this broadcast or I am not the only interested, I do forward the broadcast.
May be it was not worth.
Is it possible that only in management VLAN or VLAN 1 multicast and broadcast traffic need to be processed?
In "Best practices for Catalyst ..." I have found:

So, I could say:
1. The switch supports K vlans.
2. M vlans could travel multicast and broadcast frames that the switch must process.
3. N vlans do not travel multicast and broadcast frames that the switch must process, vlans called "user data vlans".
4. K = M + N.
5. If a multicast or broadcast frame arrives to a port belonging to the M vlans, the switch floods it and process it.
6. If a multicast or broadcast frame arrives to a port belonging to the N vlans, the switch floods it only.
I thought, if this scheme make sense, that in the point number 5 the switch, as it must process the frame, has the
possibility to decide if the frame must be flooded or not.
What do you think?
Thanks.

But the switch doesn't know the arp is not for them because switches are L2 devices so the simply look at the mac-address, see it is a broadcast and flood it within the vlan. The switch doesn't care about IP addresses in terms of forwarding packets, it only cares about L2 mac-addresses. Note we are talking about L2 switching here, obviously a L3 switch can do IP lookups.

The management vlan could be any vlan so you cannot apply the logic above to vlan 1. Also there is nothing to stop you having clients in vlan 1 although it is not recommended.

The switch does indeed have it's own vlan interface for management purposes but as far as i know even an arp destined for this IP address would still be flooded because it is a broadcast address. Only after the flooding would the switch process the actual packet and realise it has the destination IP address. Note i have never tested this so i could be mistaken but i don't think i am.

I'm not sure i follow the M/N/K argument. A switch forwards broadcasts to all packets within the same vlan simple as that.

Jon

Everyway, after this useful discussion, I need to reflect and to read more about

the general logic behind layer 2 and layer 3 switching.

For now, thanks for your patience.

great discussion