Chapter 14. Understanding IP Access Lists
| < Free Open Study > |
Filtering Traffic in Bridged EnvironmentsIn this section, we discuss the various methods for filtering in a bridged environment. If you are not familiar with access lists you might want to skip ahead to Chapter 14, "Understanding IP Access Lists." Even though that chapter deals strictly with IP access lists, the concepts, rules, and tips apply to all access lists. Filtering for bridges and data-link switches occurs at the data link layer. Cisco provides three primary types of filters for the data link layer:
Filtering SAPsFor SNAP encapsulated frames, an access list filters based on the 2-byte TYPE field given after the DSAP/SAP/OUI fields of the frame. For IEEE 802.2 frames , access lists filter on the DSAP/SSAP fields. The syntax for an access list to filter based on SAPs is as follows : Router(config)# access-list [ 200-299 ] [ deny permit ] [ 0x0-0xFFFF ] < 0x0-0xFFFF > The first value is the protocol type code, and the second value is the protocol type-code mask. The valid range for access lists that filter based on the protocol type field or SAP is 200 to 299. The access list is entered in hexadecimal format, where the hexadecimal address is followed by a wildcard mask. The wildcard mask is applied to the address, where a 1 bit means "don't care" and a 0 bit is a "care" bit. An all 0's masks means that you must match the address bit for bit, to yield a TRUE result for the access list. For more information on access-list formats and the wildcard mask, skip ahead to Chapter 14. SNA SAPsSNA uses multiple SAPs. Fortunately, they can be filtered with a single SAP of 0x0D0D. The primary SAPs that SNA uses are as follows:
All five SAPs can be filtered with the single "wildcard" SAP of 0x0D0D, which will include all SAP types. The access list to allow only SNA SAPs would resemble the following: Router(config)# access-list 200 permit 0x0d0d 0x0000 NetBIOS SAPsNetBIOS traffic uses the following SAP values:
The hexadecimal address and the appropriate wildcard mask for these two SAPS is 0xf0f0 0x0101. The access list to allow only NetBIOS SAPs resembles the following: Router(config)# access-list 200 permit 0xf0f0 0x0101 Filtering simply the NetBIOS commands is sufficient to control all NetBios traffic as well. Router(config)# access-list 200 permit 0xF0F0 IPX SAPsIPX using 802.2 encapsulation uses the following SAP value:
The access list to allow only IPX SAPs resembles the following: Router(config)# access-list 200 permit 0xe0e0 0x0000 Or, simply: Router(config)# access-list 200 permit 0xe0e0 Filtering and Blocking all SAPsAll access lists, the 200 series included, have an implicit deny any at the end of the list. The implicit deny does not show up in the configuration when it is displayed. The access list to allow all SAPs resembles the following: Router(config)# access-list 200 permit 0x0000 0xffff Conversely, the access list to deny all SAPs would look like the following: Router(config)# access-list 200 deny 0x0000 0xffff CAUTION Extreme care should be used whenever integrating IPX networks with DLSw. By default, Cisco routers will bridge IPX traffic. That means that DLSw also will pass IPX packets, unless ipx routing is enabled on the DLSw router. However, a router might be configured only for IP serving a primary DLSw peer for the SNA network, or an "SNA/DLSw peering router." If IPX also is running on the backbone of this network, "SNA peering routing" doesn't carry any IPX traffic; IPX routing isn't configured for this router. If the SNA/DLSw peering router has any interfaces that receive IPX traffic, it will not route IPX, but it will bridge it across all the DLSw peers. Soon IPX networks will be showing up all over, and the serial links can come to a screeching halt, all because they are bridging an entire IPX domain. Fortunately, this can be easily corrected by enabling IPX on the SNA/DLSw peering router or by filtering the IPX SAP, if the proper Cisco IOS Software isn't available. MAC FilteringThe access list range of 700 allows filtering based on MAC address. The syntax for a 700 series list is as follows: Router(config)# access-list [ 700-799 ] [ deny permit ] [ MAC_address ] < MAC_address_mask > Most often, this access list is entered with just a single MAC address. This is primarily because MAC addresses are not inclusive, unless you define them yourself. For example, to configure an access list to allow only MAC address 0060.5cf3.5da4, you would use the following syntax: access-list 701 permit 0060.5cf3.5da4 NetBIOS Name FilteringTo filter NetBIOS based on the name, use the following syntax: Router(config)# netbios access-list host access_list_name [ deny permit ] pattern For example, to filter a NetBIOS name of HARLY, you would use the following syntax: netbios access-list host denyharly deny HARLY The following should be kept in mind when using NetBIOS access lists:
Practical Example: Filtering in a Bridged EnvironmentAll of these access lists can be applied in a number of ways. All of the aforementioned filters mentioned can be applied to the physical interface, a DLSw peer, or a source-route bridge. The syntax needed to apply these filters to a source-route bridge or DLSw peer is listed in the previous sections. Figure 13-44 presents a DLSw network with routers solo and chewbacca. You want to apply an LSAP filter so that only SNA SAPs will cross the DLSw link between the two routers. To accomplish this, configure an access list in the 200s range, permitting SAP 0x0d0d, like the following: Figure 13-44. DLSw LSAP Filters access-list 201 permit 0x0000 0x0D0D Attach the filter to the remote-peer statement of each router, using the lsap-output-list argument. |
| < Free Open Study > |
EAN: 2147483647
Pages: 283