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 title="User Datagram Protocol">UDP
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
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.