Scenario 5: Windows 2000 DDR Issue
| This scenario covers DDR and the possible issues with interesting traffic that triggers the router to dial out. In general, the DDR configurations, discussed in detail in Chapter 11, is straightforward. They are usually based on the assumption that the environment is designed and established, and includes certain hardware and software. All potential users, processes, and events are well known and the configuration is a reflection of policies, techniques, and rules. Two major conventional configuration settings are described in this scenario: the dialer-list command and the access control list (ACL). The syntax of the dialer-list command is dialer-list dialer-group protocol protocol {permit | deny | list access-list-number} You must consider what happens when a major change occurs in the environment, such as the addition of new hardware and technology. Typical cases include a new operating system (OS) or a new wireless access points being deployed in the enterprise. This is always a challenge; the DDR must be re-evaluated to meet the new requirement. This is the case (controversy) with a new Microsoft Windows 2000 platform and Cisco DDR. The problem is that, according to monitoring and billing information, if an idle Windows 2000 (W2K)-based computer is connected to the router, the traffic can increase by as much 60 percent or more, and the number and duration of calls also increases from a reasonable 3 to 4 hours/day to almost 23 to 24 hours/day. For usage-based ISDN charges, this can increase the monthly charges by 10 to 20 times or more. In this case, the major challenge is to transform the interesting traffic to uninteresting to the router in a way that guarantees the interoperability of the devices connected to the routers, and at the same time, not prevent the W2K-based platforms from operating. The process is iterative. You should follow four easy steps:
Now, follow the steps to determine if they provide the necessary fix for DDR. Step 1: Implement the Manufacturer's Recommendations and Determine if They Are EffectiveThe information provided by Microsoft about the problem and possible remedies can be found at http://support.microsoft.com/directory/overview.asp. Generally speaking, this problem is a legacy issue carried over from Windows NT. It is based on certain periodic exchanges between the workstation and the server. At the URL just given, you can find that Microsoft recognizes the significance of the problem and points to four major factors contributing in the issue:
A more careful review of the explanations shows that more issues contribute to the problem, including domain browsing, Windows Internet Name Service (WINS) replication, directory replication, user accounts database (SAM) replication, printer browsing, and so on. All periodic retransmissions can be broken down, as Table 13-7 shows.
In general, the recommendation is to check and change the following registry settings:
For Windows 2000, the following data type is a string value that specifies the number of times the system will retry NetBIOS name query broadcasts. The default is 3:
For Windows 2000, the following data type is a string value that specifies the period of time that the system will wait before timing out broadcast name queries. The minimum value is 100, and the default is 750:
For Windows 2000, the following data type is a string value that specifies how long NetBIOS names are cached. The minimum is 60,000 milliseconds (1 minute) and the default is 360,000 milliseconds (6 minutes):
For Windows 2000, the following data type is a string value that specifies the UDP port on the name server to send name queries or registrations. The default is 137:
The following value specifies the number of times the system will try to contact the WINS server for NetBIOS name resolution. The default is 3:
For Windows 98, the following data type is a string value that specifies how long the system waits before timing out a name server query. The minimum is 100 and the default is 750:
For Windows 2000, the following data type is a string value that specifies how often to send session keepalive packets on active sessions. The minimum is 60 seconds and the default is 3600 seconds (1 hour):
For Windows 2000, the following data type is a string value that specifies how many buffers of various types to preallocate, and the maximum that can be allocated, where 1 = small, 2 = medium, and 3 = large. The default is 1, but if the WINS proxy is enabled, the default is 3:
Step 2: Monitor and Sniff All Traffic and Try to Find Patterns and Characteristics of the TrafficThis part is the most important. It can sometimes take days or months, and hundreds of pages of sniffer information, logs, and analysis. Some examples follow. When analyzing the service and processes of Windows 2000, you can establish that a service automatically runs as soon as you start the computer. It is called remote procedure call (RPC) and provides the endpoint mapper and other miscellaneous RPC services. Sniffing the traffic shows the role of RPC in keeping the ISDN line up. The contribution of TCP/IDP port 111 (Cisco keyword sunrpc) is significant and generates more than 19 percent of the additional traffic. In general, your first contributor for this extra ISDN-traffic situation is RPC (TCP/UDP port 111). For the sniffing purposes, it's good to know some of the protocol numbers, shown in Table 13-8.
Also for sniffing (and not only sniffing purposes), it is useful to know the TCP/UDP port numbers. Ports are used in TCP (RFC 793) to name the ends of logical connections that carry long-term conversations. For providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. These port numbers are divided into three ranges:
Well-known ports are controlled and assigned by the Internet Assigned Numbers Authority (IANA). The IANA is now called American Registry for Internet Numbers (ARIN) and, on most systems, can be used only by the system (or root) processes or by programs executed by privileged users. Table 13-9 shows some of the well-known ports.
You already established that RPC is one of the contributors in this process you are trying to analyze. Continuing the same process of sniffing for every protocol and port, you find the following:
Your percentage numbers can differ based on characteristics of the traffic. Step 3: Use a Cisco Knowledge Base to Remedy any Identified ProblemsIt's time to implement the existing Cisco knowledge base. Based on the available information on Cisco.com for an ACL, you can create the following solution. For IOS routers, the ACL might include the following: access-list 101 deny icmp any any echo access-list 101 deny icmp any any echo-reply access-list 101 deny icmp any any host-unreachable access-list 101 deny udp any any eq sunrpc access-list 101 deny udp any any eq netbios-ns access-list 101 deny udp any any eq netbios-dgm access-list 101 deny udp any any eq ntp access-list 101 deny tcp any any eq sunrpc access-list 101 deny tcp any any eq 445 access-list 101 deny pim any any access-list 101 deny igmp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 dialer-list 1 protocol netbios deny The 77x version would include the following: set udp111 offset 2 from udphdr pattern 00 6f set udp137 offset 2 from udphdr pattern 00 89 set udp138 offset 2 from udphdr pattern 00 8a set udp123 offset 2 from udphdr pattern 00 7b set tcp111 offset 2 from tcphdr pattern 00 6f set tcp139 offset 2 from tcphdr pattern 00 8b set tcp445 offset 2 from tcphdr pattern 01 bd set ip filter icmp out ignore set ip filter out udp111 ignore set ip filter out udp137 ignore set ip filter out udp138 ignore set ip filter out udp123 ignore set ip filter out tcp111 ignore set ip filter out tcp445 ignore set ip multicast off set netbios name spoofing off set netbios filter on Or the shorter version of the same ACL for 77x router can be the following: set ip filter udp out de=0.0.0.0/0:111 ignore set ip filter udp out de=0.0.0.0/0:137 ignore set ip filter udp out de=0.0.0.0/0:138 ignore set ip filter udp out de=0.0.0.0/0:123 ignore set ip filter tcp out de=0.0.0.0/0:111 ignore set ip filter tcp out de=0.0.0.0/0:445 ignore set ip fiter icmp out ignore set netbios name spoofing off set ip multicast of set bridging of Step 4: Select a Solution and Test ItAt this step, you must test your solution. The objective is to prove that you are able to make the extra traffic uninteresting and prevent the router from dialing out. The recommended debug settings are 804-isdn#debug arp ARP packet debugging is on 804-isdn#debug dialer Dial on demand events debugging is on 804-isdn#debug ip udp UDP packet debugging is on 804-isdn#debug ip tcp transactions TCP special event debugging is on The expected result from the debugging the process is displayed in Example 13-19. Example 13-19. Debugging Results804-isdn# Aug 1 06:30:25.886: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 88 changed to up *Aug 1 06:30:25.910: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 97 changed to up ! The moment the ISDN line is established, the router is triggering a call ! based on multicast request. *Aug 1 06:30:28.514: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.1), 28 bytes, outgoing uninteresting (list 101) ! The traffic is blocked with ACL 101 *Aug 1 06:30:28.518: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:30:43.278: Di1 DDR: ip (s=161.70.209.82, d=161.68.235.228), 96 bytes, outgoing uninteresting (list 101) *Aug 1 06:30:44.778: Di1 DDR: ip (s=161.70.209.82, d=161.68.235.228), 96 bytes, outgoing uninteresting (list 101) *Aug 1 06:30:46.278: Di1 DDR: ip (s=161.70.209.82, d=161.68.235.228), 96 bytes, outgoing uninteresting (list 101) ! The traffic is blocked to 2 WINS servers with ACL 101 *Aug 1 06:30:51.490: Di1 DDR: cdp, 295 bytes, outgoing uninteresting (no list matched) *Aug 1 06:30:51.494: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:30:55.502: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:30:55.502: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:31:25.502: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:31:25.502: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:31:51.562: Di1 DDR: cdp, 295 bytes, outgoing uninteresting (no list matched) *Aug 1 06:31:51.566: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:31:55.398: Di1 DDR: ip (s=161.70.209.82, d=161.68.222.255), 116 bytes, outgoing uninteresting (list 101) *Aug 1 06:31:55.574: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:31:55.574: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:32:00.406: Di1 DDR: ip (s=161.70.209.82, d=161.68.222.255), 116 bytes, outgoing uninteresting (list 101) *Aug 1 06:32:05.414: Di1 DDR: ip (s=161.70.209.82, d=161.68.222.255), 116 bytes, outgoing uninteresting (list 101) *Aug 1 06:32:51.634: Di1 DDR: cdp, 295 bytes, outgoing uninteresting (no list matched) *Aug 1 06:32:51.638: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected *Aug 1 06:32:55.646: Di1 DDR: ip (s=161.70.209.81, d=230.0.0.13), 30 bytes, outgoing uninteresting (list 101) *Aug 1 06:32:55.650: Di1 DDR: sending broadcast to ip 162.30.253.254 -- failed, not connected . From the previous limited segment, you can see that you are blocking the multicast and preventing the W2K computer with an IP = 161.70.209.82 to trigger a call to the WINS servers of your enterprise. You might consider turning on all the debugging and monitoring the process in more detail and for a longer period of time. The comparison between the Microsoft provided solution and the Cisco ACL-based solution shows the former one is able to reduce the extra traffic to 50 percent in some instances. However, the Cisco ACL-based solution blocks more than 99 percent of the extra traffic. The recommended hours for testing the solution are at least 72 hours. It's worth trying the same solution using different hardware, a different set and number of computers, and a different environment to make sure the solution is successful. If this step does not give you the result you are looking for, you need to start from the beginning and iterate the process again. |
EAN: 2147483647
Pages: 235