In a Metro Ethernet network, the possibility exists for a lot of NetBIOS broadcasts if your users are connecting directly to the ring rather than through a firewall. My first assumption was that most users would have a firewall, but this is really only guaranteed in the case of business-class users. When it comes to residential customers on Metro Ethernet, there is a high percentage of users plugging their connection directly into their computer.

Blocking NetBIOS is a heavy-handed tactic and might be unsuitable depending on your user base. For example, typical residential users have no need for NetBIOS interconnectivity. On the other hand, if a business-class user wants to connect two sites via a <acronym title="Virtual Local Area Network">VLAN</acronym> on your Metro Ethernet, NetBIOS is acceptable. Unfortunately, lower end Cisco Catalyst hardware cannot selectively apply an <acronym title="Access Control List">ACL</acronym> per VLAN. Instead, the ACL is applied to a port, and all traffic on that port is filtered. So, the rule of thumb here is take care when applying ACLs.

The usefulness of blocking NetBIOS on Metro Ethernet is somewhat architecture dependent. On a fiber-connected network employing Gigabit or greater speeds, blocking NetBIOS is probably overkill. In the case of radio-based Metro Ethernet, the value of preventing unnecessary packets from transmitting across a radio link cannot be understated. Since NetBIOS broadcasts can easily climb into the top ten protocols on a mostly residential Metro Ethernet, that's a lot of wasted packet transmissions.

The ACL below will be used to block incoming NetBIOS packets on the appropriate <acronym title="Transmission Control Protocol">TCP</acronym> and <acronym title="User Datagram Protocol">UDP</acronym> ports.

ip access-list extended NETBIOS
  deny tcp any any eq 135
  deny udp any any eq 135
  deny tcp any any range 137 139
  deny udp any any range 137 139
  deny tcp any any eq 445
  deny udp any any eq 445
  permit ip any any

We'll apply this access list to the appropriate port and save the configuration with the following commands.

Switch#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#interface FastEthernet0/21
Switch(config-if)#ip access-group NETBIOS in
Switch(config-if)#^Z
Switch#write
Building configuration...
[OK]
Switch#

Unfortunately, since these ACLs are processed in <acronym title="Application-Specific Integrated Circuit">ASIC</acronym>s, the show access-list command doesn't tell us how well the ACL is working. Instead, we have to use the show access-list hardware counters command. In this case, the pertinent data is the L3 ACL INPUT Statistics section. As long as the Forwarding To CPU counters stay low (preferably 0) that means our ACL is working within the capacity of the hardware. Here's a snippet of the output.

 L3 ACL INPUT Statistics
     Drop:                     All frame count: 399902875
     Drop:                     All bytes count: 2892954017
     Bridge Only:              All frame count: 0
     Bridge Only:              All bytes count: 0
     Forwarding To CPU:        All frame count: 0
     Forwarding To CPU:        All bytes count: 0
     Forwarded:                All frame count: 2571906483
     Forwarded:                All bytes count: 2123537188

As you can see, frames are being dropped, but the <acronym title="Central Processing Unit">CPU</acronym> is not having to handle them. This means the work is being done in hardware and our switch is not overtaxed.