This section contains several MPLS troubleshoot procedures.
Verify That Routing Protocol Runs
Issue the show ip protocols command in order to display the parameters and current state of the active routing protocol process:
Pomerol# show ip protocols
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 10.10.10.3
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4 Routing for Networks:
10.1.1.0 0.0.0.255 area 9
10.10.10.0 0.0.0.255 area 9
Routing Information Sources:
Gateway Distance Last Update
10.10.10.2 110 10:41:55
10.10.10.3 110 10:41:55
10.10.10.1 110 10:41:55
10.10.10.6 110 10:41:55
10.10.10.4 110 10:41:55
10.10.10.5 110 10:41:55
Distance: (default is 110)Ensure that the protocol routes for the MPLS network and all neighbors are present. You can also issue the show ip route command in order to verify the routing table:
Pomerol# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - ISIS level-1, L2 - ISIS level-2, ia - ISIS inter area
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is 10.200.28.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 13 subnets, 3 masks
C 10.1.1.8/30 is directly connected, Serial0/1.2
O 10.1.1.12/30 [110/390] via 10.1.1.5, 15:26:38, Serial0/1.1
O 10.10.10.2/32 [110/196] via 10.1.1.10, 15:26:38, Serial0/1.2
C 10.10.10.3/32 is directly connected, Loopback0
O 10.1.1.0/30 [110/390] via 10.1.1.5, 15:26:38, Serial0/1.1
[110/390] via 10.1.1.10, 15:26:38, Serial0/1.2
O 10.10.10.1/32 [110/196] via 10.1.1.5, 15:26:38, Serial0/1.1
O 10.10.10.6/32 [110/98] via 10.1.1.22, 15:26:38, Serial0/1.3
O 10.10.10.4/32 [110/391] via 10.1.1.5, 15:26:38, Serial0/1.1
C 10.1.1.4/30 is directly connected, Serial0/1.1
C 10.1.1.20/30 is directly connected, Serial0/1.3If the routers or routes are not present, investigate the routing protocol process. Refer to the OSPF Support Page in order to investigate the routing protocol process.
Verify CEF Switching
Issue the show ip cef summary command in order to display specific entries in the Forwarding Information Base (FIB) with IP address information as a basis. This output shows Normal status:
Pomerol# show ip cef summary
IP CEF with switching (Table Version 131), flags=0x0, bits=8
32 routes, 0 reresolve, 0 unresolved (0 old, 0 new)
32 leaves, 18 nodes, 23004 bytes, 125 inserts, 93 invalidations
1 load sharing elements, 336 bytes, 1 references
universal per-destination load sharing algorithm, id B642EBCF
1 CEF resets, 6 revisions of existing leaves
6 in-place modifications
refcounts: 4909 leaf, 4864 nodeIssue the show ip cef and show ip cef interface commands in order to verify CEF status. If CEF has not been enabled, nothing appears:
Pomerol# show ip cef
%CEF not running
Prefix Next Hop InterfaceRefer to the Cisco Express Forwarding Overview if you continue to have problems with the enablement of CEF.
Verify MPLS
Issue the show mpls interfaces command in order to ensure that MPLS is globally enabled. This command also verifies that a Label Distribution Protocol (LDP) runs on the requested interfaces:
Pomerol# show mpls interfaces
Interface IP Tunnel Operational
(...)
Serial0/1.1 Yes (tdp) Yes Yes
Serial0/1.2 Yes Yes No
Serial0/1.3 Yes (tdp) Yes Yes
(...)
Ping the Neighbors
An unlabeled connection must be up between each pair of router neighbors. The routing protocol and the LDP use the unlabeled connection to build the routing table and the label forwarding information base (LFIB).
Pomerol# ping 10.10.10.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 msVerify Label Distribution
Issue the show tag-switching tdp discovery command in order to display the discovered neighbors:
Pomerol# show tag-switching tdp discovery
Local TDP Identifier:
10.10.10.3:0
Discovery Sources:
Interfaces:
Serial0/1.1 (tdp): xmit/recv
TDP Id: 10.10.10.1:0
Serial0/1.2 (tdp): xmit/recv
TDP Id: 10.10.10.2:0
Serial0/1.3 (tdp): xmit/recv
TDP Id: 10.10.10.6:0In the show tag-switching tdp discovery command output, the use of TDP binds labels with routes. If any of the presumed neighbors is not present and you cannot ping the presumed neighbor, a connectivity problem exists and the LDP cannot run. If LDP runs correctly, it assigns one label per forwarding equivalent class.
Note: If the router ID for the LDP cannot be reached from the global routing table, the neighbor relationship fails to establish.
Verify Label Bindings
Issue the show tag-switching tdp bindings command in order to ensure the assignment of labels to each destination. You can use commands such as the show tag-switching forwarding-table {ip address | prefix} detail command in order to verify the different routes and the labels associated with the routes.
The output that this section shows contains label bindings for 10.10.10.x/32 networks, which are the interfaces of each label switch router (LSR):
Note: There are multiple labels for each LSR. Each label corresponds to a different path.
Pomerol# show tag-switching tdp bindings
(...)
tib entry: 10.10.10.1/32, rev 31
local binding: tag: 18
remote binding: tsr: 10.10.10.1:0, tag: imp-null
remote binding: tsr: 10.10.10.2:0, tag: 18
remote binding: tsr: 10.10.10.6:0, tag: 21
tib entry: 10.10.10.2/32, rev 22
local binding: tag: 17
remote binding: tsr: 10.10.10.2:0, tag: imp-null
remote binding: tsr: 10.10.10.1:0, tag: 19
remote binding: tsr: 10.10.10.6:0, tag: 22
tib entry: 10.10.10.3/32, rev 2
local binding: tag: imp-null
remote binding: tsr: 10.10.10.2:0, tag: 17
remote binding: tsr: 10.10.10.1:0, tag: 20
remote binding: tsr: 10.10.10.6:0, tag: 23
tib entry: 10.10.10.4/32, rev 40
local binding: tag: 20
remote binding: tsr: 10.10.10.1:0, tag: 16
remote binding: tsr: 10.10.10.2:0, tag: 20
remote binding: tsr: 10.10.10.6:0, tag: 24
tib entry: 10.10.10.5/32, rev 44
local binding: tag: 22
remote binding: tsr: 10.10.10.1:0, tag: 17
remote binding: tsr: 10.10.10.2:0, tag: 22
remote binding: tsr: 10.10.10.6:0, tag: 25
tib entry: 10.10.10.6/32, rev 48
local binding: tag: 23
remote binding: tsr: 10.10.10.6:0, tag: imp-null
remote binding: tsr: 10.10.10.1:0, tag: 22
remote binding: tsr: 10.10.10.2:0, tag: 24
(...)
Pomerol# show tag-switching forwarding-table 10.10.10.4 detail
Local Outgoing Prefix Bytes
tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interface
20 16 10.10.10.4/32 0 Se0/1.1 point2point
MAC/Encaps=4/8, MTU=1500, Tag Stack{16}
48D18847 00010000
No output feature configured
Per-packet load-sharingVerify That Labels Are Set
Use the debug mpls packet command or the MPLS-aware traceroute command functionality in order to make sure that the labels are set.
Pesaro# traceroute 10.10.10.4
Type escape sequence to abort.
Tracing the route to 10.10.10.4
1 10.1.1.21 [MPLS: Label 20 Exp 0] 272 msec 268 msec 300 msec
2 10.1.1.5 [MPLS: Label 16 Exp 0] 228 msec 228 msec 228 msec
3 10.1.1.14 92 msec * 92 msec
Saturday, April 12, 2008
Friday, April 11, 2008
Fix the four biggest problems with VPN connections
Takeaway: When they work, VPNs are great. When they don't, you can go crazy trying to figure out what's wrong. Here are four of the biggest trouble areas with VPN connections and how you can fix them.
VPNs have gone from obscurity to being a common method of linking private networks together across the Internet. Although VPNs initially became popular because they free companies from the expense of connecting networks with dedicated leased lines, part of the reason that VPNs have become so accepted is that they tend to be very reliable. Even so, VPN connections do occasionally experience problems. Here are several techniques you can use to troubleshoot VPN connections.
What’s the problem?
There are four types of problems that tend to occur with VPN connections. These include:
1.The VPN connection being rejected.
2.The acceptance of an unauthorized connection.
3.The inability to reach locations that lie beyond the VPN server.
4.The inability to establish a tunnel.
The VPN connection is rejected
Having a VPN client’s connection rejected is perhaps the most common VPN problem. Part of the reason this problem is so common is that there are a lot of issues that can cause a connection to be rejected. If your VPN server is rejecting client connections, the first thing you need to do is to check to make sure the Routing And Remote Access service is running. You can check this by opening the server’s Control Panel and clicking on the Administrative Tools icon, followed by the Services icon.
Once you've verified that the necessary services are running, try pinging the VPN server by IP address from the VPN client. You should ping by IP address initially so that you can verify that basic TCP/IP connectivity exists. If the ping is successful, then ping the server again, but this time ping by the server’s fully qualified domain name (FQDN) rather than by its address. If this ping fails where the IP address ping succeeded, you have a DNS problem, because the client is unable to resolve the server’s name to an IP address.
Check on the authentication process
Once you've established that there is a valid TCP/IP connection between the VPN client and server, and that name resolution is working correctly, the next thing to check is the authentication process. As you may know, there are a lot of different authentication methods available to a VPN connection. Both the VPN client and the VPN server must have at least one authentication method in common.
You can check to see which authentication methods the VPN server is configured to use by entering the MMC command at the Run prompt. When you do, Windows will open an empty Microsoft Management Console session. Now, select the Add / Remove Snap In command from the Console menu. When you see the Add / Remove Snap In properties sheet, click the Add button on the Standalone tab. This will reveal a list of the available snap-ins. Select Routing And Remote Access from the list and click the Add button, followed by the Close and OK buttons.
Now, the Routing And Remote Access snap-in should be added to the console. Right-click on the listing for your VPN server and select the Properties command from the resulting shortcut menu. This will display the server’s properties sheet. Select the Security tab and click the Authentication Methods button. This will cause Windows to display a dialog box with all of the available authentication methods. You can enable or disable authentication methods by selecting or deselecting the appropriate check boxes.
The method for checking the authentication method on the client end varies depending on the client’s operating system. For a Windows XP system, right-click on the VPN connection and select the Properties command from the resulting shortcut menu. This will reveal the connection’s properties sheet. Now, select the properties sheet’s Security tab, select the Advanced radio button, and click the Settings button to reveal the available authentication methods.
I usually prefer to use Windows Authentication in VPN environments, but RADIUS is also a popular choice. If you are using RADIUS Authentication, you must verify that the client supports RADIUS and that the VPN server has no trouble communicating with the RADIUS server.
More things to check
If the authentication methods appear to be set correctly, the next step is to check the technique by which the client is trying to connect to the VPN server. If the client is dialing in to the server, rather than connecting through the Internet, it could be that the remote user has no dial-in privileges. You can check the privileges either by looking at the Dial In tab on the user’s properties sheet in Active Directory Users And Computers, or by looking at the domain’s remote access policy. This would also be a good time to verify that the user actually knows how to establish the VPN connection and that the user is using the correct username and password.
This may sound obvious, but if your domain is running in Windows 2000 Native Mode, your VPN server needs to be a member of the domain. If the VPN server hasn’t joined the domain, it will be unable to authenticate logins.
You also need to take a look at IP addresses. Each Web-based VPN connection actually uses two different IP addresses for the VPN client computer. The first IP address is the one that was assigned by the client’s ISP. This is the IP address that’s used to establish the initial TCP/IP connection to the VPN server over the Internet. However, once the client attaches to the VPN server, the VPN server assigns the client a secondary IP address. This IP address has the same subnet as the local network and thus allows the client to communicate with the local network.
At the time you set up the VPN server, you must either specify that the server will use a DHCP server to assign addresses to clients, or you can create a bank of IP addresses to assign to clients directly from the VPN server. In either case, if the server runs out of valid IP addresses, it will be unable to assign an address to the client and the connection will be refused.
For environments in which a DHCP server is used, one of the more common setup errors is specifying an incorrect NIC. If you right-click on the VPN server in the Routing And Remote Access console and select the Properties command from the resulting shortcut menu, you’ll see the server’s properties sheet. The properties sheet’s IP tab contains radio buttons that allow you to select whether a static address pool or a DHCP server will be used. If you select the DHCP server option, you must select the appropriate network adapter from the drop-down list at the bottom of the tab. You must select a network adapter that has a TCP/IP path to the DHCP server.
Acceptance of unauthorized connections
Now that I’ve discussed reasons why a connection might be refused, let’s take a look at the opposite problem in which unauthorized connections are accepted. This problem is much less common than not getting connected at all, but is much more serious because of the potential security issues.
If you look at a user’s properties sheet in the Active Directory Users And Computers console, you’ll notice that the Dial In tab contains an option to control access through the remote access policy. If this option is selected and the effective remote access policy is set to allow remote access, the user will be able to attach to the VPN. Although I have been unable to re-create the situation personally, I have heard rumors that a bug exists in Windows 2000 that causes the connection to be accepted even if the effective remote access policy is set to deny a user’s connection, and that it’s best to allow or deny connections directly through the Active Directory Users And Computers console.
Inability to reach locations beyond the VPN server
Another common VPN problem is that a connection is successfully established, but that the remote user is unable to access the network lying beyond the VPN server. By far, the most common cause of this problem is that permission hasn’t been granted for the user to access the entire network. If you have ever worked with Windows NT 4.0, you may recall a setting in RAS that allowed you to control whether a user had access to one computer or to the entire network. This particular setting doesn’t exist in Windows 2000, but there is another setting that does the same thing.
To allow a user to access the entire network, go to the Routing And Remote Access console and right-click on the VPN server that’s having the problem. Select the Properties command from the resulting shortcut menu to display the server’s properties sheet, and then select the properties sheet’s IP tab. At the top of the IP tab is an Enable IP Routing check box. If this check box is enabled, VPN and RAS users will be able to get to the rest of the network. If the check box is not selected, these users will be able to access only the VPN server, but nothing beyond.
The problem could also be related to other routing issues. For example, if a user is dialing directly in to the VPN server, it’s usually best to configure a static route between the client and the server. You can configure a static route by going to the Dial In tab of the user’s properties sheet in Active Directory Users And Computers, and selecting the Apply A Static Route check box. This will cause Windows to display the Static Routes dialog box. Click the Add Route button and then enter the destination IP address and network mask in the space provided. The metric should be left at 1.
If you're using a DHCP server to assign IP addresses to clients, there are a couple of other problems that could cause users not to be able to go beyond the VPN server. One such problem is that of duplicate IP addresses. If the DHCP server assigns the user an IP address that is already in use elsewhere on the network, Windows will detect the conflict and prevent the user from accessing the rest of the network.
Another common problem is the user not receiving an address at all. Most of the time, if the DHCP server can’t assign the user an IP address, the connection won’t make it this far. However, there are situations in which an address assignment fails, so Windows automatically assigns the user an address from the 169.254.x.x range. If the client is assigned an address in this range, but this address range isn’t present in the system’s routing tables, the user will be unable to navigate the network beyond the VPN server.
Difficulty establishing a tunnel
If everything seems to be working well, but you can’t seem to establish a tunnel between the client and the server, there are two main possibilities of what could be causing the problem. The first possibility is that one or more of the routers involved is performing IP packet filtering. IP packet filtering could prevent IP tunnel traffic. I recommend checking the client, the server, and any machines in between for IP packet filters. You can do this by clicking the Advanced button on each machine’s TCP/IP Properties sheet, selecting the Options tab from the Advanced TCP/IP Settings Properties sheet, selecting TCP/IP Filtering, and clicking the Properties button.
The other possibility is that a proxy server is standing between the client and the VPN server. A proxy server performs NAT translation on all traffic flowing between the client and the Internet. This means that packets appear to be coming from the proxy server rather than from the client itself. In some cases, this interaction could prevent a tunnel from being established, especially if the VPN server is expecting the client to have a specific IP address. You must also keep in mind that a lot of older or low-end proxy servers (or NAT firewalls) don’t support the L2TP, IPSec, or PPTP protocols that are often used for VPN connections.
VPNs have gone from obscurity to being a common method of linking private networks together across the Internet. Although VPNs initially became popular because they free companies from the expense of connecting networks with dedicated leased lines, part of the reason that VPNs have become so accepted is that they tend to be very reliable. Even so, VPN connections do occasionally experience problems. Here are several techniques you can use to troubleshoot VPN connections.
What’s the problem?
There are four types of problems that tend to occur with VPN connections. These include:
1.The VPN connection being rejected.
2.The acceptance of an unauthorized connection.
3.The inability to reach locations that lie beyond the VPN server.
4.The inability to establish a tunnel.
The VPN connection is rejected
Having a VPN client’s connection rejected is perhaps the most common VPN problem. Part of the reason this problem is so common is that there are a lot of issues that can cause a connection to be rejected. If your VPN server is rejecting client connections, the first thing you need to do is to check to make sure the Routing And Remote Access service is running. You can check this by opening the server’s Control Panel and clicking on the Administrative Tools icon, followed by the Services icon.
Once you've verified that the necessary services are running, try pinging the VPN server by IP address from the VPN client. You should ping by IP address initially so that you can verify that basic TCP/IP connectivity exists. If the ping is successful, then ping the server again, but this time ping by the server’s fully qualified domain name (FQDN) rather than by its address. If this ping fails where the IP address ping succeeded, you have a DNS problem, because the client is unable to resolve the server’s name to an IP address.
Check on the authentication process
Once you've established that there is a valid TCP/IP connection between the VPN client and server, and that name resolution is working correctly, the next thing to check is the authentication process. As you may know, there are a lot of different authentication methods available to a VPN connection. Both the VPN client and the VPN server must have at least one authentication method in common.
You can check to see which authentication methods the VPN server is configured to use by entering the MMC command at the Run prompt. When you do, Windows will open an empty Microsoft Management Console session. Now, select the Add / Remove Snap In command from the Console menu. When you see the Add / Remove Snap In properties sheet, click the Add button on the Standalone tab. This will reveal a list of the available snap-ins. Select Routing And Remote Access from the list and click the Add button, followed by the Close and OK buttons.
Now, the Routing And Remote Access snap-in should be added to the console. Right-click on the listing for your VPN server and select the Properties command from the resulting shortcut menu. This will display the server’s properties sheet. Select the Security tab and click the Authentication Methods button. This will cause Windows to display a dialog box with all of the available authentication methods. You can enable or disable authentication methods by selecting or deselecting the appropriate check boxes.
The method for checking the authentication method on the client end varies depending on the client’s operating system. For a Windows XP system, right-click on the VPN connection and select the Properties command from the resulting shortcut menu. This will reveal the connection’s properties sheet. Now, select the properties sheet’s Security tab, select the Advanced radio button, and click the Settings button to reveal the available authentication methods.
I usually prefer to use Windows Authentication in VPN environments, but RADIUS is also a popular choice. If you are using RADIUS Authentication, you must verify that the client supports RADIUS and that the VPN server has no trouble communicating with the RADIUS server.
More things to check
If the authentication methods appear to be set correctly, the next step is to check the technique by which the client is trying to connect to the VPN server. If the client is dialing in to the server, rather than connecting through the Internet, it could be that the remote user has no dial-in privileges. You can check the privileges either by looking at the Dial In tab on the user’s properties sheet in Active Directory Users And Computers, or by looking at the domain’s remote access policy. This would also be a good time to verify that the user actually knows how to establish the VPN connection and that the user is using the correct username and password.
This may sound obvious, but if your domain is running in Windows 2000 Native Mode, your VPN server needs to be a member of the domain. If the VPN server hasn’t joined the domain, it will be unable to authenticate logins.
You also need to take a look at IP addresses. Each Web-based VPN connection actually uses two different IP addresses for the VPN client computer. The first IP address is the one that was assigned by the client’s ISP. This is the IP address that’s used to establish the initial TCP/IP connection to the VPN server over the Internet. However, once the client attaches to the VPN server, the VPN server assigns the client a secondary IP address. This IP address has the same subnet as the local network and thus allows the client to communicate with the local network.
At the time you set up the VPN server, you must either specify that the server will use a DHCP server to assign addresses to clients, or you can create a bank of IP addresses to assign to clients directly from the VPN server. In either case, if the server runs out of valid IP addresses, it will be unable to assign an address to the client and the connection will be refused.
For environments in which a DHCP server is used, one of the more common setup errors is specifying an incorrect NIC. If you right-click on the VPN server in the Routing And Remote Access console and select the Properties command from the resulting shortcut menu, you’ll see the server’s properties sheet. The properties sheet’s IP tab contains radio buttons that allow you to select whether a static address pool or a DHCP server will be used. If you select the DHCP server option, you must select the appropriate network adapter from the drop-down list at the bottom of the tab. You must select a network adapter that has a TCP/IP path to the DHCP server.
Acceptance of unauthorized connections
Now that I’ve discussed reasons why a connection might be refused, let’s take a look at the opposite problem in which unauthorized connections are accepted. This problem is much less common than not getting connected at all, but is much more serious because of the potential security issues.
If you look at a user’s properties sheet in the Active Directory Users And Computers console, you’ll notice that the Dial In tab contains an option to control access through the remote access policy. If this option is selected and the effective remote access policy is set to allow remote access, the user will be able to attach to the VPN. Although I have been unable to re-create the situation personally, I have heard rumors that a bug exists in Windows 2000 that causes the connection to be accepted even if the effective remote access policy is set to deny a user’s connection, and that it’s best to allow or deny connections directly through the Active Directory Users And Computers console.
Inability to reach locations beyond the VPN server
Another common VPN problem is that a connection is successfully established, but that the remote user is unable to access the network lying beyond the VPN server. By far, the most common cause of this problem is that permission hasn’t been granted for the user to access the entire network. If you have ever worked with Windows NT 4.0, you may recall a setting in RAS that allowed you to control whether a user had access to one computer or to the entire network. This particular setting doesn’t exist in Windows 2000, but there is another setting that does the same thing.
To allow a user to access the entire network, go to the Routing And Remote Access console and right-click on the VPN server that’s having the problem. Select the Properties command from the resulting shortcut menu to display the server’s properties sheet, and then select the properties sheet’s IP tab. At the top of the IP tab is an Enable IP Routing check box. If this check box is enabled, VPN and RAS users will be able to get to the rest of the network. If the check box is not selected, these users will be able to access only the VPN server, but nothing beyond.
The problem could also be related to other routing issues. For example, if a user is dialing directly in to the VPN server, it’s usually best to configure a static route between the client and the server. You can configure a static route by going to the Dial In tab of the user’s properties sheet in Active Directory Users And Computers, and selecting the Apply A Static Route check box. This will cause Windows to display the Static Routes dialog box. Click the Add Route button and then enter the destination IP address and network mask in the space provided. The metric should be left at 1.
If you're using a DHCP server to assign IP addresses to clients, there are a couple of other problems that could cause users not to be able to go beyond the VPN server. One such problem is that of duplicate IP addresses. If the DHCP server assigns the user an IP address that is already in use elsewhere on the network, Windows will detect the conflict and prevent the user from accessing the rest of the network.
Another common problem is the user not receiving an address at all. Most of the time, if the DHCP server can’t assign the user an IP address, the connection won’t make it this far. However, there are situations in which an address assignment fails, so Windows automatically assigns the user an address from the 169.254.x.x range. If the client is assigned an address in this range, but this address range isn’t present in the system’s routing tables, the user will be unable to navigate the network beyond the VPN server.
Difficulty establishing a tunnel
If everything seems to be working well, but you can’t seem to establish a tunnel between the client and the server, there are two main possibilities of what could be causing the problem. The first possibility is that one or more of the routers involved is performing IP packet filtering. IP packet filtering could prevent IP tunnel traffic. I recommend checking the client, the server, and any machines in between for IP packet filters. You can do this by clicking the Advanced button on each machine’s TCP/IP Properties sheet, selecting the Options tab from the Advanced TCP/IP Settings Properties sheet, selecting TCP/IP Filtering, and clicking the Properties button.
The other possibility is that a proxy server is standing between the client and the VPN server. A proxy server performs NAT translation on all traffic flowing between the client and the Internet. This means that packets appear to be coming from the proxy server rather than from the client itself. In some cases, this interaction could prevent a tunnel from being established, especially if the VPN server is expecting the client to have a specific IP address. You must also keep in mind that a lot of older or low-end proxy servers (or NAT firewalls) don’t support the L2TP, IPSec, or PPTP protocols that are often used for VPN connections.
Troubleshoot multicast
Troubleshooting Strategies
When you troubleshoot multicast networks, it is good to consider the signaling protocol used in the network and packet flow. The signaling protocol is used to setup and tear down the multicast sessions (such as PIM dense mode, PIM sparse mode, and DVMRP), and packet flow is the actual sending, replicating, and receiving of the multicast packets between the source and receiver, based on the forwarding table created by the signaling process.
Check Source Packet Flow
Complete these steps to determine if the source is actually sourcing the packets and inserting the correct packet fields:
Check the interface counters on the host. First, check the interface counters (if you are on a UNIX system, use the netstat command) on the source host to see if it is sending packets. If it is not, check for misconfiguration or bugs in the host stack and application.
Use the show ip igmp groups interface-name command to check the upstream router to see if it received a join membership report at the interface directly connected to source.
Check the TTL value in the application sourcing packets; it should be greater than 1. If the application sends packets with a TTL value less than 1, you should see the traffic dropped at the first upstream router. To verify, use the show ip traffic command and look for an increase in the value of the "bad hop count" counter. Any packet with a TTL value of 1, or less than the TTL threshold set by the interface with the ip multicast ttl-threshold command, is dropped and the "bad hop-count" counter is increased by one. Use the show ip igmp interface interface-name command to see the interface TTL threshold value.
Use the show ip mroute count and show ip mroute active commands to check the first upstream router or switch to see if it sees multicast packets from the source. The command output shows the traffic flow statistics for each (S,G) pair. If you do not observe any traffic, check receiver signaling.
Use the debug ip mpacket command on the nearest upstream router, with the detail or acl argument for granularity. Use this command with caution when there is heavy multicast traffic on the network. Only if necessary, use the debug ip mpacket command on the route. Use the detail argument to show packet headers in the debug output, and access lists to check for traffic from specific sources. Remember that this command can have a serious performance impact on other traffic, so use it with caution.
Check Network Signaling
This is the most complex and important piece of troubleshooting in any network. It depends on the network signaling protocol used, such as PIM sparse mode, PIM dense mode, and DVMRP. We recommend the multi-step approach described in this section.
Troubleshooting PIM Sparse Mode
Complete these steps to troubleshoot PIM sparse mode.
Check that IP multicast routing is enabled on all multicast routers.
Use the show ip pim neighbor command to check the expiration timer and mode to ensure sucessful PIM neighbor establishment, and look for any possible connectivity and timer issues that might inhibit the establishment of PIM neighbors. If necessary, use the ip pim [version] [dense-mode] [sparse-mode] [sparse-dense-mode] interface level subcommand to set the correct mode and version to successfully establish the PIM neighbors.
Use the show ip pim rp mapping command to ensure the correct RP-Group mapping and to check the expiration timer if auto-RP is configured. Use the debug ip pim auto-rp command to help figure out any auto-RP failures. If you do not see any PIM Group-to-RP Mappings, check the Auto-RP configuration, or configure static Group-RP mappings with the ip pim rp-address ip address of RP [access-list] [named-accesslist] [override] command.
Use the show ip rpf ip address of source command to check the RPF failure for the source address. PIM dense mode and PIM sparse mode send Prune messages back to the source if traffic arrives on a non-RPF point-to-point interface. The debug ip pim command helps identify possible reasons for a failure in a PIM network—it compares the typical output with what you see. Use this output to identify the three discrete stages in PIM sparse mode: joining, registering, and SPT-switchover. The show ip mroute command allows you to watch the null entries in the Outgoing Interface lists and pruned entries in the mroute table.
Check Network Packet Flow
Use these commands to check the flow of multicast packets across the network:
multicast trace hop-by-hop using the mtrace command
mstat
ping
show ip mroute count
show ip mroute active
debug ip mpacket
Check Receiver Signaling
Complete these steps to check receiver signaling:
Use the show ip igmp groups command at the first upstream router connected to the receiver to check that the interface has joined the group.
Use the ping command to check the reachability of the host and the first upstream router.
Use the show ip igmp interface command to check the IGMP version of the interface.
Remember that a router configured with IGMP version 1 considers IGMP version 2 packets received from the host as invalid. These IGMP packets do not join the group until the router receives an IGMP version 1 packet from the host.
Use the debug ip igmp command to further troubleshoot receiver signaling.
Check Receiver Packet Flow
Complete these steps to check the receiver packet flow.
Use the netstat command on a UNIX system to check the receiver interface statistics.
Check that the TCP/IP stack was installed and configured properly.
Check that the Multicast receiver client application was installed and configured properly.
Watch for duplicate multicast packets on a multiaccess segment.
show Commands
The commands in this section help you gather useful information when troubleshooting a multicast problem. Refer to the IP Multicast Command Reference Guide for more extensive information on these show commands.
If your show command responses are sluggish, the most probable reason is that router currently performs an IP domain lookup for IP addresses in the show command. You can disable IP domain lookup You can use the the no ip domain-lookup command, under the router global configuration mode, to disable IP domain lookup. This stops the IP domain lookup and increases the show command output speed.
show ip igmp groups
This command shows which multicast groups are directly connected to the router, and which are learned via Internet Group Management Protocol (IGMP). You can use this command to verify that a source or receiver has actually joined the target group on the router interface. The "Last Reporter" column shows only one IGMP host, which indicates that it has sent either an unsolicited IGMP Join or IGMP Report in response to a IGMP Query from the PIM router for that particular group. You should only see one "Last Reporter" per Group Address.
R1# show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.255.0.1 Ethernet1 00:10:54 00:01:10 192.168.9.1
224.0.1.40 Ethernet0 01:36:27 00:02:45 192.168.10.2
224.0.1.40 Ethernet1 01:48:15 never 192.168.9.3
show ip igmp interface
Use this command to display multicast-related information about an interface, and to verify that IGMP is enabled, the correct version is running, the timers, Time To Live (TTL) threshold value, and IGMP querier router are properly set. IGMP does not need to be configured on an interface. It is enabled by default when you configure ip pim dense-modesparse-modesparse-dense-mode .
R1# show ip igmp interface
Ethernet1 is up, line protocol is up
Internet address is 192.168.9.3/24
IGMP is enabled on interface
Current IGMP version is 2
CGMP is disabled on interface
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 22 joins, 18 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 192.168.9.5
IGMP querying router is 192.168.9.3 (this system)
Multicast groups joined (number of users):
224.0.1.40(1)
show ip pim neighbor
Use this command to list the Protocol Independent Multicast (PIM) neighbors discovered by the Cisco IOS® Software.
R1# show ip pim neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.10.10.1 Ethernet0/0 02:19:41/00:01:38 v2 1 / DR B S
Details of each field are explained below.
Neighbor Address - Specifies a PIM neighbor's IP address
Interface - An interface where a PIM neighbor was discovered
Uptime - The total uptime of neighbor
Expires - The time before a neighbor is timed out and until next PIM hello is received
Ver - The version of PIM on neighbor's interface
DR Prio - The possible values are 0 to 4294967294 or "N"
This is a new column which tracks the priority of a PIM interface for DR election. The feature to configure a DR based on highest priority versus highest IP address was introduced in Cisco IOS versions 12.1(2)T and 12.2 and Cisco IOS images with Bidir-PIM. You can use the ip pim dr-priority <0-4294967294> interface command to set the DR priority. The default DR priority is set to 1. For interoperability, if a PIM neighbor is running an older Cisco IOS version which does not support the DR priority feature, the "DR Prior" column shows as "N". If the neighbor is the only router showing "N" for the interface, it becomes the DR regardless of which router actually has the highest IP address. If there are serveral PIM neighbors with "N" listed under this column, the tie breaker is the highest IP address among them.
Mode - Information regarding the DR and other PIM capabilities.
This column lists the DR in addition to any capabilities supported by the PIM neighbor:
DR - The PIM neighbor is Designated Router
B - Bidirectional PIM (Bidir-PIM) capable
S - State refresh capable (applies only for dense mode)
When you troubleshoot, use this command to verify that all neighbors are up and that they use the proper mode, version, and expiration timer. You can also check the router configuration, or use the show ip pim interface command to verify the mode (PIM sparse or dense mode). Use the debug ip pim command to observe the pim-query message exchange.
show ip pim interface
Use this command to display information about interfaces configured for PIM. In addition, you can use this command to verify that the correct PIM mode (dense or sparse) is configured on the interface, the neighbor count is correct, and the designated router (DR) is correct (which is critical for PIM sparse mode). Multi-access segments (such as Ethernet, Token Ring, FDDI) elect a DR based on highest IP address. Point-to-Point links do not display DR information.
R1# show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
192.168.10.1 Ethernet0 v2/Sparse-Dense 1 30 192.168.10.2
192.168.9.3 Ethernet1 v2/Sparse-Dense 1 30 192.168.9.5
show ip mroute summary
Use this command to display the summarized contents of the IP multicast routing table. You can also use it to verify the active multicast group(s) and which multicast senders are active by looking at the timers and flags.
R1## show ip mroute summary
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.0.1), 01:57:07/00:02:59, RP 192.168.7.2, flags: SJCF
(133.33.33.32, 239.255.0.1), 01:56:23/00:02:59, flags: CJT
(192.168.9.1, 239.255.0.1), 01:57:07/00:03:27, flags: CFT
(*, 224.0.1.40), 1d00h/00:00:00, RP 192.168.7.2, flags: SJPCL
show ip mroute
Use this command to display the full contents of the IP multicast routing table. When you troubleshoot, use this command to verify:
The (S,G) and (*,G) state entries from the flags.
The incoming interface is correct. If it is not, check the unicast routing table.
The outgoing interface(s) is correct. If it is incorrectly pruned, check the state in the downstream router.
R1# show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.0.1), 01:55:27/00:02:59, RP 192.168.7.2, flags: SJCF
Incoming interface: Ethernet0, RPF nbr 192.168.10.2
Outgoing interface list:
Ethernet1, Forward/Sparse, 01:55:27/00:02:52
(133.33.33.32, 239.255.0.1), 01:54:43/00:02:59, flags: CJT
Incoming interface: Ethernet0, RPF nbr 192.168.10.2
Outgoing interface list:
Ethernet1, Forward/Sparse, 01:54:43/00:02:52
(192.168.9.1, 239.255.0.1), 01:55:30/00:03:26, flags: CFT
Incoming interface: Ethernet1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Sparse, 01:55:30/00:03:12
(*, 224.0.1.40), 1d00h/00:00:00, RP 192.168.7.2, flags: SJPCL
Incoming interface: Ethernet0, RPF nbr 192.168.10.2
Outgoing interface list: Null
show ip mroute active
Use this command to display the active traffic sources and groups above the threshold. When you troubleshoot, use it to verify active source groups, the traffic rate for each source group (S,G) pair (you must have switched to Shortest Path Tree (SPT)), and to check if the target group multicast traffic is being received. If the traffic is not being received, look for active traffic starting from the source towards the receiver.
R1# show ip mroute active
Active IP Multicast Sources - sending >= 4 kbps
Group: 239.255.0.1, (?)
Source: 133.33.33.32 (?)
Rate: 10 pps/115 kbps(1sec), 235 kbps(last 23 secs), 87 kbps(life avg)
show ip rpf
Use this command to display how IP multicast routing does Reverse Path Forwarding (RPF). When you troubleshoot, use it to verify that the RPF information is correct. If it is not, check the unicast routing table for the source address. Also use the ping and trace commands on the source address to verify that unicast routing works. You may need to use Distance Vector Multicast Routing Protocol (DVMRP) routes or static mroutes to fix any unicast-multicast inconsistencies.
R1# show ip rpf 133.33.33.32
RPF information for ? (133.33.33.32)
RPF interface: Ethernet0
RPF neighbor: ? (192.168.10.2)
RPF route/mask: 133.33.0.0/16
RPF type: unicast (eigrp 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
show ip mcache
This command can verify the IP multicast fast switching cache and debug fast switching bugs.
R1# show ip mcache
IP Multicast Fast-Switching Cache
(133.33.33.32/32, 239.255.0.1), Ethernet0, Last used: 00:00:00
Ethernet1 MAC Header: 01005E7F000100000C13DBA90800
(192.168.9.1/32, 239.255.0.1), Ethernet1, Last used: 00:00:00
Ethernet0 MAC Header: 01005E7F000100000C13DBA80800
show ip mroute count
Use this command to verify that multicast traffic is received and to check on its flow rates and drops. If no traffic is received, work from the source to the receiver until you find where the traffic stops. You can also use this command to verify that traffic is being forwarded. If it is not, use the show ip mroute command to look for "Null Outgoing interface list" and RPF failures.
R1# show ip mroute count
IP Multicast Statistics
routes using 2406 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.0.1, Source count: 2, Group pkt count: 11709
RP-tree: Forwarding: 3/0/431/0, Other: 3/0/0
Source: 133.33.33.32/32, Forwarding: 11225/6/1401/62, Other: 11225/0/0
Source: 192.168.9.1/32, Forwarding: 481/0/85/0, Other: 490/0/9
Group: 224.0.1.40, Source count: 0, Group pkt count:
show ip route
Use this command to check the unicast routing table and fix the RPF failures in the mroute table.
R2# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
D 192.168.9.0/24 [90/307200] via 192.168.10.1, 00:59:45, Ethernet0
C 192.168.10.0/24 is directly connected, Ethernet0
D 192.168.4.0/24 [90/11040000] via 192.168.7.1, 23:21:00, Serial0
D 192.168.5.0/24 [90/11023872] via 192.168.7.1, 23:21:02, Serial0
C 192.168.7.0/24 is directly connected, Serial0
D 133.33.0.0/16 [90/2195456] via 192.168.7.1, 1d23h, Serial0
D 192.168.1.0/24 [90/11552000] via 192.168.7.1, 22:41:27, Serial0
show ip pim rp mapping
Use this command to check the RP assignment by multicast group range, and to verify that the source of RP learning (static or auto-RP) and the mapping are correct. If you find an error, check the local router configuration or auto-RP configuration.
R1# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.1.40/32
RP 192.168.7.2 (?), v1
Info source: local, via Auto-RP
Uptime: 2d00h, expires: never
Group(s): 224.0.0.0/4, Static
RP: 192.168.7.2 (?)
clear ip igmp group
To delete entries from the IGMP cache, use the clear ip igmp group EXEC command. clear ip igmp group [group-name group-address type number]
group-name
(Optional) Name of the multicast group, as defined in the DNS hosts table or with the ip host command.
group-address
(Optional) Address of the multicast group. This is a multicast IP address in four-part, dotted notation.
type number
(Optional) Interface type and number.
clear ip mroute
To delete entries from the IP multicast routing table, use the clear ip mroute EXEC command. clear ip mroute {* group [source]}
*
Deletes all entries from the IP multicast routing table.
group
Can be either one of the following:
· Name of the multicast group, as defined in the DNS hosts table or with the ip host command.
· IP address of the multicast group. This is a multicast IP address in four-part, dotted notation.
source
(Optional) If you specify a group name or address, you can also specify a name or address of a multicast source that is transmitting to the group. A source does not need to be a member of the group.
When you troubleshoot multicast networks, it is good to consider the signaling protocol used in the network and packet flow. The signaling protocol is used to setup and tear down the multicast sessions (such as PIM dense mode, PIM sparse mode, and DVMRP), and packet flow is the actual sending, replicating, and receiving of the multicast packets between the source and receiver, based on the forwarding table created by the signaling process.
Check Source Packet Flow
Complete these steps to determine if the source is actually sourcing the packets and inserting the correct packet fields:
Check the interface counters on the host. First, check the interface counters (if you are on a UNIX system, use the netstat command) on the source host to see if it is sending packets. If it is not, check for misconfiguration or bugs in the host stack and application.
Use the show ip igmp groups interface-name command to check the upstream router to see if it received a join membership report at the interface directly connected to source.
Check the TTL value in the application sourcing packets; it should be greater than 1. If the application sends packets with a TTL value less than 1, you should see the traffic dropped at the first upstream router. To verify, use the show ip traffic command and look for an increase in the value of the "bad hop count" counter. Any packet with a TTL value of 1, or less than the TTL threshold set by the interface with the ip multicast ttl-threshold command, is dropped and the "bad hop-count" counter is increased by one. Use the show ip igmp interface interface-name command to see the interface TTL threshold value.
Use the show ip mroute count and show ip mroute active commands to check the first upstream router or switch to see if it sees multicast packets from the source. The command output shows the traffic flow statistics for each (S,G) pair. If you do not observe any traffic, check receiver signaling.
Use the debug ip mpacket command on the nearest upstream router, with the detail or acl argument for granularity. Use this command with caution when there is heavy multicast traffic on the network. Only if necessary, use the debug ip mpacket command on the route. Use the detail argument to show packet headers in the debug output, and access lists to check for traffic from specific sources. Remember that this command can have a serious performance impact on other traffic, so use it with caution.
Check Network Signaling
This is the most complex and important piece of troubleshooting in any network. It depends on the network signaling protocol used, such as PIM sparse mode, PIM dense mode, and DVMRP. We recommend the multi-step approach described in this section.
Troubleshooting PIM Sparse Mode
Complete these steps to troubleshoot PIM sparse mode.
Check that IP multicast routing is enabled on all multicast routers.
Use the show ip pim neighbor command to check the expiration timer and mode to ensure sucessful PIM neighbor establishment, and look for any possible connectivity and timer issues that might inhibit the establishment of PIM neighbors. If necessary, use the ip pim [version] [dense-mode] [sparse-mode] [sparse-dense-mode] interface level subcommand to set the correct mode and version to successfully establish the PIM neighbors.
Use the show ip pim rp mapping command to ensure the correct RP-Group mapping and to check the expiration timer if auto-RP is configured. Use the debug ip pim auto-rp command to help figure out any auto-RP failures. If you do not see any PIM Group-to-RP Mappings, check the Auto-RP configuration, or configure static Group-RP mappings with the ip pim rp-address ip address of RP [access-list] [named-accesslist] [override] command.
Use the show ip rpf ip address of source command to check the RPF failure for the source address. PIM dense mode and PIM sparse mode send Prune messages back to the source if traffic arrives on a non-RPF point-to-point interface. The debug ip pim command helps identify possible reasons for a failure in a PIM network—it compares the typical output with what you see. Use this output to identify the three discrete stages in PIM sparse mode: joining, registering, and SPT-switchover. The show ip mroute command allows you to watch the null entries in the Outgoing Interface lists and pruned entries in the mroute table.
Check Network Packet Flow
Use these commands to check the flow of multicast packets across the network:
multicast trace hop-by-hop using the mtrace command
mstat
ping
show ip mroute count
show ip mroute active
debug ip mpacket
Check Receiver Signaling
Complete these steps to check receiver signaling:
Use the show ip igmp groups command at the first upstream router connected to the receiver to check that the interface has joined the group.
Use the ping command to check the reachability of the host and the first upstream router.
Use the show ip igmp interface command to check the IGMP version of the interface.
Remember that a router configured with IGMP version 1 considers IGMP version 2 packets received from the host as invalid. These IGMP packets do not join the group until the router receives an IGMP version 1 packet from the host.
Use the debug ip igmp command to further troubleshoot receiver signaling.
Check Receiver Packet Flow
Complete these steps to check the receiver packet flow.
Use the netstat command on a UNIX system to check the receiver interface statistics.
Check that the TCP/IP stack was installed and configured properly.
Check that the Multicast receiver client application was installed and configured properly.
Watch for duplicate multicast packets on a multiaccess segment.
show Commands
The commands in this section help you gather useful information when troubleshooting a multicast problem. Refer to the IP Multicast Command Reference Guide for more extensive information on these show commands.
If your show command responses are sluggish, the most probable reason is that router currently performs an IP domain lookup for IP addresses in the show command. You can disable IP domain lookup You can use the the no ip domain-lookup command, under the router global configuration mode, to disable IP domain lookup. This stops the IP domain lookup and increases the show command output speed.
show ip igmp groups
This command shows which multicast groups are directly connected to the router, and which are learned via Internet Group Management Protocol (IGMP). You can use this command to verify that a source or receiver has actually joined the target group on the router interface. The "Last Reporter" column shows only one IGMP host, which indicates that it has sent either an unsolicited IGMP Join or IGMP Report in response to a IGMP Query from the PIM router for that particular group. You should only see one "Last Reporter" per Group Address.
R1# show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.255.0.1 Ethernet1 00:10:54 00:01:10 192.168.9.1
224.0.1.40 Ethernet0 01:36:27 00:02:45 192.168.10.2
224.0.1.40 Ethernet1 01:48:15 never 192.168.9.3
show ip igmp interface
Use this command to display multicast-related information about an interface, and to verify that IGMP is enabled, the correct version is running, the timers, Time To Live (TTL) threshold value, and IGMP querier router are properly set. IGMP does not need to be configured on an interface. It is enabled by default when you configure ip pim dense-modesparse-modesparse-dense-mode .
R1# show ip igmp interface
Ethernet1 is up, line protocol is up
Internet address is 192.168.9.3/24
IGMP is enabled on interface
Current IGMP version is 2
CGMP is disabled on interface
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 22 joins, 18 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 192.168.9.5
IGMP querying router is 192.168.9.3 (this system)
Multicast groups joined (number of users):
224.0.1.40(1)
show ip pim neighbor
Use this command to list the Protocol Independent Multicast (PIM) neighbors discovered by the Cisco IOS® Software.
R1# show ip pim neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.10.10.1 Ethernet0/0 02:19:41/00:01:38 v2 1 / DR B S
Details of each field are explained below.
Neighbor Address - Specifies a PIM neighbor's IP address
Interface - An interface where a PIM neighbor was discovered
Uptime - The total uptime of neighbor
Expires - The time before a neighbor is timed out and until next PIM hello is received
Ver - The version of PIM on neighbor's interface
DR Prio - The possible values are 0 to 4294967294 or "N"
This is a new column which tracks the priority of a PIM interface for DR election. The feature to configure a DR based on highest priority versus highest IP address was introduced in Cisco IOS versions 12.1(2)T and 12.2 and Cisco IOS images with Bidir-PIM. You can use the ip pim dr-priority <0-4294967294> interface command to set the DR priority. The default DR priority is set to 1. For interoperability, if a PIM neighbor is running an older Cisco IOS version which does not support the DR priority feature, the "DR Prior" column shows as "N". If the neighbor is the only router showing "N" for the interface, it becomes the DR regardless of which router actually has the highest IP address. If there are serveral PIM neighbors with "N" listed under this column, the tie breaker is the highest IP address among them.
Mode - Information regarding the DR and other PIM capabilities.
This column lists the DR in addition to any capabilities supported by the PIM neighbor:
DR - The PIM neighbor is Designated Router
B - Bidirectional PIM (Bidir-PIM) capable
S - State refresh capable (applies only for dense mode)
When you troubleshoot, use this command to verify that all neighbors are up and that they use the proper mode, version, and expiration timer. You can also check the router configuration, or use the show ip pim interface command to verify the mode (PIM sparse or dense mode). Use the debug ip pim command to observe the pim-query message exchange.
show ip pim interface
Use this command to display information about interfaces configured for PIM. In addition, you can use this command to verify that the correct PIM mode (dense or sparse) is configured on the interface, the neighbor count is correct, and the designated router (DR) is correct (which is critical for PIM sparse mode). Multi-access segments (such as Ethernet, Token Ring, FDDI) elect a DR based on highest IP address. Point-to-Point links do not display DR information.
R1# show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
192.168.10.1 Ethernet0 v2/Sparse-Dense 1 30 192.168.10.2
192.168.9.3 Ethernet1 v2/Sparse-Dense 1 30 192.168.9.5
show ip mroute summary
Use this command to display the summarized contents of the IP multicast routing table. You can also use it to verify the active multicast group(s) and which multicast senders are active by looking at the timers and flags.
R1## show ip mroute summary
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.0.1), 01:57:07/00:02:59, RP 192.168.7.2, flags: SJCF
(133.33.33.32, 239.255.0.1), 01:56:23/00:02:59, flags: CJT
(192.168.9.1, 239.255.0.1), 01:57:07/00:03:27, flags: CFT
(*, 224.0.1.40), 1d00h/00:00:00, RP 192.168.7.2, flags: SJPCL
show ip mroute
Use this command to display the full contents of the IP multicast routing table. When you troubleshoot, use this command to verify:
The (S,G) and (*,G) state entries from the flags.
The incoming interface is correct. If it is not, check the unicast routing table.
The outgoing interface(s) is correct. If it is incorrectly pruned, check the state in the downstream router.
R1# show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.0.1), 01:55:27/00:02:59, RP 192.168.7.2, flags: SJCF
Incoming interface: Ethernet0, RPF nbr 192.168.10.2
Outgoing interface list:
Ethernet1, Forward/Sparse, 01:55:27/00:02:52
(133.33.33.32, 239.255.0.1), 01:54:43/00:02:59, flags: CJT
Incoming interface: Ethernet0, RPF nbr 192.168.10.2
Outgoing interface list:
Ethernet1, Forward/Sparse, 01:54:43/00:02:52
(192.168.9.1, 239.255.0.1), 01:55:30/00:03:26, flags: CFT
Incoming interface: Ethernet1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Sparse, 01:55:30/00:03:12
(*, 224.0.1.40), 1d00h/00:00:00, RP 192.168.7.2, flags: SJPCL
Incoming interface: Ethernet0, RPF nbr 192.168.10.2
Outgoing interface list: Null
show ip mroute active
Use this command to display the active traffic sources and groups above the threshold. When you troubleshoot, use it to verify active source groups, the traffic rate for each source group (S,G) pair (you must have switched to Shortest Path Tree (SPT)), and to check if the target group multicast traffic is being received. If the traffic is not being received, look for active traffic starting from the source towards the receiver.
R1# show ip mroute active
Active IP Multicast Sources - sending >= 4 kbps
Group: 239.255.0.1, (?)
Source: 133.33.33.32 (?)
Rate: 10 pps/115 kbps(1sec), 235 kbps(last 23 secs), 87 kbps(life avg)
show ip rpf
Use this command to display how IP multicast routing does Reverse Path Forwarding (RPF). When you troubleshoot, use it to verify that the RPF information is correct. If it is not, check the unicast routing table for the source address. Also use the ping and trace commands on the source address to verify that unicast routing works. You may need to use Distance Vector Multicast Routing Protocol (DVMRP) routes or static mroutes to fix any unicast-multicast inconsistencies.
R1# show ip rpf 133.33.33.32
RPF information for ? (133.33.33.32)
RPF interface: Ethernet0
RPF neighbor: ? (192.168.10.2)
RPF route/mask: 133.33.0.0/16
RPF type: unicast (eigrp 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
show ip mcache
This command can verify the IP multicast fast switching cache and debug fast switching bugs.
R1# show ip mcache
IP Multicast Fast-Switching Cache
(133.33.33.32/32, 239.255.0.1), Ethernet0, Last used: 00:00:00
Ethernet1 MAC Header: 01005E7F000100000C13DBA90800
(192.168.9.1/32, 239.255.0.1), Ethernet1, Last used: 00:00:00
Ethernet0 MAC Header: 01005E7F000100000C13DBA80800
show ip mroute count
Use this command to verify that multicast traffic is received and to check on its flow rates and drops. If no traffic is received, work from the source to the receiver until you find where the traffic stops. You can also use this command to verify that traffic is being forwarded. If it is not, use the show ip mroute command to look for "Null Outgoing interface list" and RPF failures.
R1# show ip mroute count
IP Multicast Statistics
routes using 2406 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.0.1, Source count: 2, Group pkt count: 11709
RP-tree: Forwarding: 3/0/431/0, Other: 3/0/0
Source: 133.33.33.32/32, Forwarding: 11225/6/1401/62, Other: 11225/0/0
Source: 192.168.9.1/32, Forwarding: 481/0/85/0, Other: 490/0/9
Group: 224.0.1.40, Source count: 0, Group pkt count:
show ip route
Use this command to check the unicast routing table and fix the RPF failures in the mroute table.
R2# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
D 192.168.9.0/24 [90/307200] via 192.168.10.1, 00:59:45, Ethernet0
C 192.168.10.0/24 is directly connected, Ethernet0
D 192.168.4.0/24 [90/11040000] via 192.168.7.1, 23:21:00, Serial0
D 192.168.5.0/24 [90/11023872] via 192.168.7.1, 23:21:02, Serial0
C 192.168.7.0/24 is directly connected, Serial0
D 133.33.0.0/16 [90/2195456] via 192.168.7.1, 1d23h, Serial0
D 192.168.1.0/24 [90/11552000] via 192.168.7.1, 22:41:27, Serial0
show ip pim rp mapping
Use this command to check the RP assignment by multicast group range, and to verify that the source of RP learning (static or auto-RP) and the mapping are correct. If you find an error, check the local router configuration or auto-RP configuration.
R1# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.1.40/32
RP 192.168.7.2 (?), v1
Info source: local, via Auto-RP
Uptime: 2d00h, expires: never
Group(s): 224.0.0.0/4, Static
RP: 192.168.7.2 (?)
clear ip igmp group
To delete entries from the IGMP cache, use the clear ip igmp group EXEC command. clear ip igmp group [group-name group-address type number]
group-name
(Optional) Name of the multicast group, as defined in the DNS hosts table or with the ip host command.
group-address
(Optional) Address of the multicast group. This is a multicast IP address in four-part, dotted notation.
type number
(Optional) Interface type and number.
clear ip mroute
To delete entries from the IP multicast routing table, use the clear ip mroute EXEC command. clear ip mroute {* group [source]}
*
Deletes all entries from the IP multicast routing table.
group
Can be either one of the following:
· Name of the multicast group, as defined in the DNS hosts table or with the ip host command.
· IP address of the multicast group. This is a multicast IP address in four-part, dotted notation.
source
(Optional) If you specify a group name or address, you can also specify a name or address of a multicast source that is transmitting to the group. A source does not need to be a member of the group.
Thursday, April 10, 2008
Multicast
Background
Internet Protocol (IP) multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of corporate recipients and homes. Applications that take advantage of multicast include videoconferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news.
IP Multicast delivers source traffic to multiple receivers without adding any additional burden on the source or the receivers while using the least network bandwidth of any competing technology. Multicast packets are replicated in the network by Cisco routers enabled with Protocol Independent Multicast (PIM) and other supporting multicast protocols resulting in the most efficient delivery of data to multiple receivers possible. All alternatives require the source to send more than one copy of the data. Some even require the source to send an individual copy to each receiver. If there are thousands of receivers, even low-bandwidth applications benefit from using Cisco IP Multicast. High-bandwidth applications, such as MPEG video, may require a large portion of the available network bandwidth for a single stream. In these applications, the only way to send to more than one receiver simultaneously is by using IP Multicast. Figure 43-1 demonstrates how data from one source is delivered to several interested recipients using IP multicast.
Multicast Group Concept
Multicast is based on the concept of a group. An arbitrary group of receivers expresses an interest in receiving a particular data stream. This group does not have any physical or geographical boundaries—the hosts can be located anywhere on the Internet. Hosts that are interested in receiving data flowing to a particular group must join the group using IGMP. Hosts must be a member of the group to receive the data stream.
IP Multicast Addresses
Multicast addresses specify an arbitrary group of IP hosts that have joined the group and want to receive traffic sent to this group.
IP Class D Addresses
The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. It has assigned the old Class D address space to be used for IP multicast. This means that all IP multicast group addresses will fall in the range of 224.0.0.0 to 239.255.255.255.
Note This address range is only for the group address or destination address of IP multicast traffic. The source address for multicast datagrams is always the unicast source address.
Reserved Link Local Addresses
The IANA has reserved addresses in the 224.0.0.0 through 224.0.0.255 to be used by network protocols on a local network segment. Packets with these addresses should never be forwarded by a router; they remain local on a particular LAN segment. They are always transmitted with a time-to-live (TTL) of 1.
Network protocols use these addresses for automatic router discovery and to communicate important routing information. For example, OSPF uses 224.0.0.5 and 224.0.0.6 to exchange link state information. Table 43-1 lists some of the well-known addresses.
Globally Scoped Address
The range of addresses from 224.0.1.0 through 238.255.255.255 are called globally scoped addresses. They can be used to multicast data between organizations and across the Internet.
Some of these addresses have been reserved for use by multicast applications through IANA. For example, 224.0.1.1 has been reserved for Network Time Protocol (NTP).
More information about reserved multicast addresses can be found at http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
Limited Scope Addresses
The range of addresses from 239.0.0.0 through 239.255.255.255 contains limited scope addresses or administratively scoped addresses. These are defined by RFC 2365 to be constrained to a local group or organization. Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so those local multicast boundaries can be defined. This also allows for address reuse among these smaller domains.
Glop Addressing
RFC 2770 proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses by organizations that already have an AS number reserved. The AS number of the domain is embedded into the second and third octets of the 233.0.0.0/8 range.
For example, the AS 62010 is written in hex as F23A. Separating out the two octets F2 and 3A, we get 242 and 58 in decimal. This would give us a subnet of 233.242.58.0 that would be globally reserved for AS 62010 to use.
Layer 2 Multicast Addresses
Normally, network interface cards (NICs) on a LAN segment will receive only packets destined for their burned-in MAC address or the broadcast MAC address. Some means had to be devised so that multiple hosts could receive the same packet and still be capable of differentiating among multicast groups.
Fortunately, the IEEE LAN specifications made provisions for the transmission of broadcast and/or multicast packets. In the 802.3 standard, bit 0 of the first octet is used to indicate a broadcast and/or multicast frame. Figure 43-2 shows the location of the broadcast/multicast bit in an Ethernet frame.
This bit indicates that the frame is destined for an arbitrary group of hosts or all hosts on the network (in the case of the broadcast address, 0xFFFF.FFFF.FFFF).
IP multicast makes use of this capability to transmit IP packets to a group of hosts on a LAN segment.
Ethernet MAC Address Mapping
The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal. Half of this block is allocated for multicast addresses. This creates the range of available Ethernet MAC addresses to be 0100.5e00.0000 through 0100.5e7f.ffff.
This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast group address into these available 23 bits in the Ethernet address (shown in Figure 43-3).
Internet Group Management Protocol
IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet.
IGMP Version 2 works basically the same as Version 1. The main difference is that there is a leave group message. The hosts now can actively communicate to the local multicast router their intention to leave the group. The router then sends out a group-specific query and determines whether there are any remaining hosts interested in receiving the traffic. If there are no replies, the router times out the group and stops forwarding the traffic. This can greatly reduce the leave latency compared to IGMP Version 1. Unwanted and unnecessary traffic can be stopped much sooner.
Multicast in the Layer 2 Switching Environment
The default behavior for a Layer 2 switch is to forward all multicast traffic to every port that belongs to the destination LAN on the switch. This would defeat the purpose of the switch, which is to limit traffic to the ports that need to receive the data.
Two methods exist by which to deal with multicast in a Layer 2 switching environment efficiently—Cisco Group Management Protocol (CGMP) and IGMP snooping.
Cisco Group Management Protocol
CGMP is a Cisco-developed protocol that allows Catalyst switches to leverage IGMP information on Cisco routers to make Layer 2 forwarding decisions. CGMP must be configured both on the multicast routers and on the Layer 2 switches. The net result is that with CGMP, IP multicast traffic is delivered only to those Catalyst switch ports that are interested in the traffic. All other ports that have not explicitly requested the traffic will not receive it.
The basic concept of CGMP is shown in Figure 43-7. When a host joins a multicast group (part A), it multicasts an unsolicited IGMP membership report message to the target group (224.1.2.3, in this example). The IGMP report is passed through the switch to the router for the normal IGMP processing. The router (which must have CGMP enabled on this interface) receives this IGMP report and processes it as it normally would, but in addition it creates a CGMP join message and sends it to the switch.
The switch receives this CGMP join message and then adds the port to its content addressable memory (CAM) table for that multicast group. Subsequent traffic directed to this multicast group will be forwarded out the port for that host. The router port is also added to the entry for the multicast group. Multicast routers must listen to all multicast traffic for every group because the IGMP control messages are also sent as multicast traffic. With CGMP, the switch must listen only to CGMP join and CGMP leave messages from the router. The rest of the multicast traffic is forwarded using its CAM table exactly the way the switch was designed.
Protocol-Independent Multicast
Protocol-independent multicast (PIM) gets its name from the fact that it is IP routing protocol-independent. PIM can leverage whichever unicast routing protocols are used to populate the unicast routing table, including EIGRP, OSPF, BGP, or static routes. PIM uses this unicast routing information to perform the multicast forwarding function, so it is IP protocol-independent. Although PIM is called a multicast routing protocol, it actually uses the unicast routing table to perform the reverse path forwarding (RPF) check function instead of building up a completely independent multicast routing table. PIM does not send and receive multicast routing updates between routers like other routing protocols do.
PIM Dense Mode
PIM Dense Mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network. This is a brute-force method for delivering data to the receivers, but in certain applications, this might be an efficient mechanism if there are active receivers on every subnet in the network.
PIM-DM initially floods multicast traffic throughout the network. Routers that do not have any downstream neighbors prune back the unwanted traffic. This process repeats every 3 minutes.
The flood and prune mechanism is how the routers accumulate their state information—by receiving the data stream. These data streams contain the source and group information so that downstream routers can build up their multicast forwarding tables. PIM-DM can support only source trees—(S,G) entries. It cannot be used to build a shared distribution tree.
PIM Sparse Mode
PIM Sparse Mode (PIM-SM) uses a pull model to deliver multicast traffic. Only networks that have active receivers that have explicitly requested the data will be forwarded the traffic. PIM-SM is defined in RFC 2362.
PIM-SM uses a shared tree to distribute the information about active sources. Depending on the configuration options, the traffic can remain on the shared tree or switch over to an optimized source distribution tree. The latter is the default behavior for PIM-SM on Cisco routers. The traffic starts to flow down the shared tree, and then routers along the path determine whether there is a better path to the source. If a better, more direct path exists, the designated router (the router closest to the receiver) will send a join message toward the source and then reroute the traffic along this path.
PIM-SM has the concept of an RP, since it uses shared trees—at least initially. The RP must be administratively configured in the network. Sources register with the RP, and then data is forwarded down the shared tree to the receivers. If the shared tree is not an optimal path between the source and the receiver, the routers dynamically create a source tree and stop traffic from flowing down the shared tree. This is the default behavior in IOS. Network administrators can force traffic to stay on the shared tree by using a configuration option (lp pim spt-threshold infinity).
PIM-SM scales well to a network of any size, including those with WAN links. The explicit join mechanism prevents unwanted traffic from flooding the WAN links.
Sparse-Dense Mode
Cisco has implemented an alternative to choosing just dense mode or just sparse mode on a router interface new IP. This was necessitated by a change in the paradigm for forwarding multicast traffic via PIM that became apparent during its development. It turned out that it was more efficient to choose sparse or dense on a per group basis rather than a per router interface basis. Sparse-dense mode facilitates this ability.
Network administrators can also configure sparse-dense mode. This configuration option allows individual groups to be run in either sparse or dense mode, depending on whether RP information is available for that group. If the router learns RP information for a particular group, it will be treated as sparse mode; otherwise, that group will be treated as dense mode.
Multiprotocol Border Gateway Protocol
Multiprotocol Border Gateway Protocol (MBGP) gives a method for providers to distinguish which route prefixes they will use for performing multicast RPF checks. The RPF check is the fundamental mechanism that routers use to determine the paths that multicast forwarding trees will follow and successfully deliver multicast content from sources to receivers.
MBGP is described in RFC 2283, Multiprotocol Extensions for BGP-4. Since MBGP is an extension of BGP, it brings along all the administrative machinery that providers and customers like in their interdomain routing environment. Including all the inter-AS tools to filter and control routing (e.g., route maps). Therefore, by using MBGP, any network utilizing internal or external BGP can apply the multiple policy control knobs familiar in BGP to specify routing (and thereby forwarding) policy for multicast.
Two path attributes, MP_REACH_NLRI and MP_UNREACH_NLRI have been introduced in BGP4+. These new attributes create a simple way to carry two sets of routing information—one for unicast routing and one for multicast routing. The routes associated with multicast routing are used to build the multicast distribution trees.
The main advantage of MBGP is that an internet can support noncongruent unicast and multicast topologies. When the unicast and multicast topologies are congruent, MBGP can support different policies for each. MBGP provides a scalable policy based interdomain routing protocol.
Multicast Source Discovery Protocol
In the PIM Sparse mode model, multicast sources and receivers must register with their local Rendezvous Point (RP). Actually, the closest router to the sources or receivers registers with the RP but the point is that the RP knows about all the sources and receivers for any particular group. RPs in other domains have no way of knowing about sources located in other domains. MSDP is an elegant way to solve this problem. MSDP is a mechanism that connects PIM-SM domains and allows RPs to share information about active sources. When RPs in remote domains know about active sources they can pass on that information to their local receivers and multicast data can be forwarded between the domains. A nice feature of MSDP is that it allows each domain to maintain an independent RP which does not rely on other domains, but it does enable RPs to forward traffic between domains.
The RP in each domain establishes an MSDP peering session using a TCP connection with the RPs in other domains or with border routers leading to the other domains. When the RP learns about a new multicast source within its own domain (through the normal PIM register mechanism), the RP encapsulates the first data packet in a Source Active (SA) message and sends the SA to all MSDP peers. The SA is forwarded by each receiving peer using a modified RPF check, until it reaches every MSDP router in the interconnected networks—theoretically the entire multicast internet. If the receiving MSDP peer is an RP, and the RP has a (*,G) entry for the group in the SA (there is an interested receiver), the RP will create (S,G) state for the source and join to the shortest path tree for the state of the source. The encapsulated data is decapsulated and forwarded down that RP's shared tree. When the packet is received by a receiver's last hop router, the last-hop may also join the shortest path tree to the source. The source's RP periodically sends SAs, which include all sources within that RP's own domain.
---FAQ ---
Review Questions
Q—What is the range of available IP multicast addresses?
A—224.0.0.0 to 239.255.255.255.
Q—What is the purpose of IGMP?
A—IGMP is used between the hosts and their local multicast router to join and leave multicast groups.
Q—What is an advantage of IGMPv2 over IGMPv1?
A—IGMPv2 has a leave group message that can greatly reduce the latency of unwanted traffic on a LAN.
Q—What is a potential disadvantage of IGMP snooping over CGMP on a low-end Layer 2 switch?
A—IGMP snooping requires the switch to examine every multicast packet for an IGMP control message. On a low-end switch, this might have a severe performance impact.
Q—What is an advantage of shortest path (or source) trees compared to shared trees?
A—Source trees guarantee an optimal path between each source and each receiver, which will minimize network latency.
Q—What is an advantage of using shared trees?
A—Shared trees require very little state to be kept in the routers, which requires less memory.
Q—What information does the router use to do an RPF check?
A—The unicast routing table.
Q—Why is protocol-independent multicast called "independent"?
A—PIM works with any underlying IP unicast routing protocol—RIP, EIGRP, OSPF, BGP or static routes.
Q—What is the main advantage of MBGP?
A—Providers can have noncongruent unicast and multicast routing topologies.
Q—How do RPs learn about sources from other RPs with MSDP?
A—RPs are configured to be MSDP peers with other RPs. Each RP forwards source active (SA) messages to each other.
Q—What is the purpose of the anycast RP?
A—Load balancing and fault tolerance.
The multicast info can be found here, for details diagrams
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm
Internet Protocol (IP) multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of corporate recipients and homes. Applications that take advantage of multicast include videoconferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news.
IP Multicast delivers source traffic to multiple receivers without adding any additional burden on the source or the receivers while using the least network bandwidth of any competing technology. Multicast packets are replicated in the network by Cisco routers enabled with Protocol Independent Multicast (PIM) and other supporting multicast protocols resulting in the most efficient delivery of data to multiple receivers possible. All alternatives require the source to send more than one copy of the data. Some even require the source to send an individual copy to each receiver. If there are thousands of receivers, even low-bandwidth applications benefit from using Cisco IP Multicast. High-bandwidth applications, such as MPEG video, may require a large portion of the available network bandwidth for a single stream. In these applications, the only way to send to more than one receiver simultaneously is by using IP Multicast. Figure 43-1 demonstrates how data from one source is delivered to several interested recipients using IP multicast.
Multicast Group Concept
Multicast is based on the concept of a group. An arbitrary group of receivers expresses an interest in receiving a particular data stream. This group does not have any physical or geographical boundaries—the hosts can be located anywhere on the Internet. Hosts that are interested in receiving data flowing to a particular group must join the group using IGMP. Hosts must be a member of the group to receive the data stream.
IP Multicast Addresses
Multicast addresses specify an arbitrary group of IP hosts that have joined the group and want to receive traffic sent to this group.
IP Class D Addresses
The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. It has assigned the old Class D address space to be used for IP multicast. This means that all IP multicast group addresses will fall in the range of 224.0.0.0 to 239.255.255.255.
Note This address range is only for the group address or destination address of IP multicast traffic. The source address for multicast datagrams is always the unicast source address.
Reserved Link Local Addresses
The IANA has reserved addresses in the 224.0.0.0 through 224.0.0.255 to be used by network protocols on a local network segment. Packets with these addresses should never be forwarded by a router; they remain local on a particular LAN segment. They are always transmitted with a time-to-live (TTL) of 1.
Network protocols use these addresses for automatic router discovery and to communicate important routing information. For example, OSPF uses 224.0.0.5 and 224.0.0.6 to exchange link state information. Table 43-1 lists some of the well-known addresses.
Globally Scoped Address
The range of addresses from 224.0.1.0 through 238.255.255.255 are called globally scoped addresses. They can be used to multicast data between organizations and across the Internet.
Some of these addresses have been reserved for use by multicast applications through IANA. For example, 224.0.1.1 has been reserved for Network Time Protocol (NTP).
More information about reserved multicast addresses can be found at http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
Limited Scope Addresses
The range of addresses from 239.0.0.0 through 239.255.255.255 contains limited scope addresses or administratively scoped addresses. These are defined by RFC 2365 to be constrained to a local group or organization. Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so those local multicast boundaries can be defined. This also allows for address reuse among these smaller domains.
Glop Addressing
RFC 2770 proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses by organizations that already have an AS number reserved. The AS number of the domain is embedded into the second and third octets of the 233.0.0.0/8 range.
For example, the AS 62010 is written in hex as F23A. Separating out the two octets F2 and 3A, we get 242 and 58 in decimal. This would give us a subnet of 233.242.58.0 that would be globally reserved for AS 62010 to use.
Layer 2 Multicast Addresses
Normally, network interface cards (NICs) on a LAN segment will receive only packets destined for their burned-in MAC address or the broadcast MAC address. Some means had to be devised so that multiple hosts could receive the same packet and still be capable of differentiating among multicast groups.
Fortunately, the IEEE LAN specifications made provisions for the transmission of broadcast and/or multicast packets. In the 802.3 standard, bit 0 of the first octet is used to indicate a broadcast and/or multicast frame. Figure 43-2 shows the location of the broadcast/multicast bit in an Ethernet frame.
This bit indicates that the frame is destined for an arbitrary group of hosts or all hosts on the network (in the case of the broadcast address, 0xFFFF.FFFF.FFFF).
IP multicast makes use of this capability to transmit IP packets to a group of hosts on a LAN segment.
Ethernet MAC Address Mapping
The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal. Half of this block is allocated for multicast addresses. This creates the range of available Ethernet MAC addresses to be 0100.5e00.0000 through 0100.5e7f.ffff.
This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast group address into these available 23 bits in the Ethernet address (shown in Figure 43-3).
Internet Group Management Protocol
IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet.
IGMP Version 2 works basically the same as Version 1. The main difference is that there is a leave group message. The hosts now can actively communicate to the local multicast router their intention to leave the group. The router then sends out a group-specific query and determines whether there are any remaining hosts interested in receiving the traffic. If there are no replies, the router times out the group and stops forwarding the traffic. This can greatly reduce the leave latency compared to IGMP Version 1. Unwanted and unnecessary traffic can be stopped much sooner.
Multicast in the Layer 2 Switching Environment
The default behavior for a Layer 2 switch is to forward all multicast traffic to every port that belongs to the destination LAN on the switch. This would defeat the purpose of the switch, which is to limit traffic to the ports that need to receive the data.
Two methods exist by which to deal with multicast in a Layer 2 switching environment efficiently—Cisco Group Management Protocol (CGMP) and IGMP snooping.
Cisco Group Management Protocol
CGMP is a Cisco-developed protocol that allows Catalyst switches to leverage IGMP information on Cisco routers to make Layer 2 forwarding decisions. CGMP must be configured both on the multicast routers and on the Layer 2 switches. The net result is that with CGMP, IP multicast traffic is delivered only to those Catalyst switch ports that are interested in the traffic. All other ports that have not explicitly requested the traffic will not receive it.
The basic concept of CGMP is shown in Figure 43-7. When a host joins a multicast group (part A), it multicasts an unsolicited IGMP membership report message to the target group (224.1.2.3, in this example). The IGMP report is passed through the switch to the router for the normal IGMP processing. The router (which must have CGMP enabled on this interface) receives this IGMP report and processes it as it normally would, but in addition it creates a CGMP join message and sends it to the switch.
The switch receives this CGMP join message and then adds the port to its content addressable memory (CAM) table for that multicast group. Subsequent traffic directed to this multicast group will be forwarded out the port for that host. The router port is also added to the entry for the multicast group. Multicast routers must listen to all multicast traffic for every group because the IGMP control messages are also sent as multicast traffic. With CGMP, the switch must listen only to CGMP join and CGMP leave messages from the router. The rest of the multicast traffic is forwarded using its CAM table exactly the way the switch was designed.
Protocol-Independent Multicast
Protocol-independent multicast (PIM) gets its name from the fact that it is IP routing protocol-independent. PIM can leverage whichever unicast routing protocols are used to populate the unicast routing table, including EIGRP, OSPF, BGP, or static routes. PIM uses this unicast routing information to perform the multicast forwarding function, so it is IP protocol-independent. Although PIM is called a multicast routing protocol, it actually uses the unicast routing table to perform the reverse path forwarding (RPF) check function instead of building up a completely independent multicast routing table. PIM does not send and receive multicast routing updates between routers like other routing protocols do.
PIM Dense Mode
PIM Dense Mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network. This is a brute-force method for delivering data to the receivers, but in certain applications, this might be an efficient mechanism if there are active receivers on every subnet in the network.
PIM-DM initially floods multicast traffic throughout the network. Routers that do not have any downstream neighbors prune back the unwanted traffic. This process repeats every 3 minutes.
The flood and prune mechanism is how the routers accumulate their state information—by receiving the data stream. These data streams contain the source and group information so that downstream routers can build up their multicast forwarding tables. PIM-DM can support only source trees—(S,G) entries. It cannot be used to build a shared distribution tree.
PIM Sparse Mode
PIM Sparse Mode (PIM-SM) uses a pull model to deliver multicast traffic. Only networks that have active receivers that have explicitly requested the data will be forwarded the traffic. PIM-SM is defined in RFC 2362.
PIM-SM uses a shared tree to distribute the information about active sources. Depending on the configuration options, the traffic can remain on the shared tree or switch over to an optimized source distribution tree. The latter is the default behavior for PIM-SM on Cisco routers. The traffic starts to flow down the shared tree, and then routers along the path determine whether there is a better path to the source. If a better, more direct path exists, the designated router (the router closest to the receiver) will send a join message toward the source and then reroute the traffic along this path.
PIM-SM has the concept of an RP, since it uses shared trees—at least initially. The RP must be administratively configured in the network. Sources register with the RP, and then data is forwarded down the shared tree to the receivers. If the shared tree is not an optimal path between the source and the receiver, the routers dynamically create a source tree and stop traffic from flowing down the shared tree. This is the default behavior in IOS. Network administrators can force traffic to stay on the shared tree by using a configuration option (lp pim spt-threshold infinity).
PIM-SM scales well to a network of any size, including those with WAN links. The explicit join mechanism prevents unwanted traffic from flooding the WAN links.
Sparse-Dense Mode
Cisco has implemented an alternative to choosing just dense mode or just sparse mode on a router interface new IP. This was necessitated by a change in the paradigm for forwarding multicast traffic via PIM that became apparent during its development. It turned out that it was more efficient to choose sparse or dense on a per group basis rather than a per router interface basis. Sparse-dense mode facilitates this ability.
Network administrators can also configure sparse-dense mode. This configuration option allows individual groups to be run in either sparse or dense mode, depending on whether RP information is available for that group. If the router learns RP information for a particular group, it will be treated as sparse mode; otherwise, that group will be treated as dense mode.
Multiprotocol Border Gateway Protocol
Multiprotocol Border Gateway Protocol (MBGP) gives a method for providers to distinguish which route prefixes they will use for performing multicast RPF checks. The RPF check is the fundamental mechanism that routers use to determine the paths that multicast forwarding trees will follow and successfully deliver multicast content from sources to receivers.
MBGP is described in RFC 2283, Multiprotocol Extensions for BGP-4. Since MBGP is an extension of BGP, it brings along all the administrative machinery that providers and customers like in their interdomain routing environment. Including all the inter-AS tools to filter and control routing (e.g., route maps). Therefore, by using MBGP, any network utilizing internal or external BGP can apply the multiple policy control knobs familiar in BGP to specify routing (and thereby forwarding) policy for multicast.
Two path attributes, MP_REACH_NLRI and MP_UNREACH_NLRI have been introduced in BGP4+. These new attributes create a simple way to carry two sets of routing information—one for unicast routing and one for multicast routing. The routes associated with multicast routing are used to build the multicast distribution trees.
The main advantage of MBGP is that an internet can support noncongruent unicast and multicast topologies. When the unicast and multicast topologies are congruent, MBGP can support different policies for each. MBGP provides a scalable policy based interdomain routing protocol.
Multicast Source Discovery Protocol
In the PIM Sparse mode model, multicast sources and receivers must register with their local Rendezvous Point (RP). Actually, the closest router to the sources or receivers registers with the RP but the point is that the RP knows about all the sources and receivers for any particular group. RPs in other domains have no way of knowing about sources located in other domains. MSDP is an elegant way to solve this problem. MSDP is a mechanism that connects PIM-SM domains and allows RPs to share information about active sources. When RPs in remote domains know about active sources they can pass on that information to their local receivers and multicast data can be forwarded between the domains. A nice feature of MSDP is that it allows each domain to maintain an independent RP which does not rely on other domains, but it does enable RPs to forward traffic between domains.
The RP in each domain establishes an MSDP peering session using a TCP connection with the RPs in other domains or with border routers leading to the other domains. When the RP learns about a new multicast source within its own domain (through the normal PIM register mechanism), the RP encapsulates the first data packet in a Source Active (SA) message and sends the SA to all MSDP peers. The SA is forwarded by each receiving peer using a modified RPF check, until it reaches every MSDP router in the interconnected networks—theoretically the entire multicast internet. If the receiving MSDP peer is an RP, and the RP has a (*,G) entry for the group in the SA (there is an interested receiver), the RP will create (S,G) state for the source and join to the shortest path tree for the state of the source. The encapsulated data is decapsulated and forwarded down that RP's shared tree. When the packet is received by a receiver's last hop router, the last-hop may also join the shortest path tree to the source. The source's RP periodically sends SAs, which include all sources within that RP's own domain.
---FAQ ---
Review Questions
Q—What is the range of available IP multicast addresses?
A—224.0.0.0 to 239.255.255.255.
Q—What is the purpose of IGMP?
A—IGMP is used between the hosts and their local multicast router to join and leave multicast groups.
Q—What is an advantage of IGMPv2 over IGMPv1?
A—IGMPv2 has a leave group message that can greatly reduce the latency of unwanted traffic on a LAN.
Q—What is a potential disadvantage of IGMP snooping over CGMP on a low-end Layer 2 switch?
A—IGMP snooping requires the switch to examine every multicast packet for an IGMP control message. On a low-end switch, this might have a severe performance impact.
Q—What is an advantage of shortest path (or source) trees compared to shared trees?
A—Source trees guarantee an optimal path between each source and each receiver, which will minimize network latency.
Q—What is an advantage of using shared trees?
A—Shared trees require very little state to be kept in the routers, which requires less memory.
Q—What information does the router use to do an RPF check?
A—The unicast routing table.
Q—Why is protocol-independent multicast called "independent"?
A—PIM works with any underlying IP unicast routing protocol—RIP, EIGRP, OSPF, BGP or static routes.
Q—What is the main advantage of MBGP?
A—Providers can have noncongruent unicast and multicast routing topologies.
Q—How do RPs learn about sources from other RPs with MSDP?
A—RPs are configured to be MSDP peers with other RPs. Each RP forwards source active (SA) messages to each other.
Q—What is the purpose of the anycast RP?
A—Load balancing and fault tolerance.
The multicast info can be found here, for details diagrams
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm
Wednesday, April 9, 2008
Juniper WXC - WAN Acceleration
What is the WXC product line? The WXC (for WAN acceleration with caching) 500 and WXC 250 are the two Juniper Networks WAN application acceleration platforms that support the Network Sequence Caching™ technology, a reduction algorithm that stores data patterns on hard disks to dramatically increase their compression dictionary size. By using hard disks (as opposed to onboard memory), the sequence caching feature extends the Juniper pattern-matching capability from hundreds of megabytes (available with the WX product family) to hundreds of gigabytes.
Why is there a two for one tunnel penalty when connecting WX and WXC devices?
The WX is a memory only based compression device and uses more memory per tunnel when doing compression. The WXC has a disk it can leverage and therefore does not require as much memory per tunnel.
When you connect a WX to a WXC device the WXC has to allocate more memory to form that connection than it would when connecting to another WXC. The actual memory consumed on the WXC is less than what is required for two tunnels in most cases, but in order to provide tunnel scaling numbers that are deterministic we count this as two tunnels in WXOS 5.4 and above.
When WX enables OSPF feature, it does not generate any LSA at all. It is just listening to other LSAs going back and forth through WX. So, from routing perspective, it should not be a problem.Now about the WX scalability question: WX/WXC (except WX15) can hold up to 8192 routes in local route table.So, the quantity perspective, 1300 route is not an issue.
Head 2 head RiverBed 1520 or Juniper WXC
We are on the process of making decision on Riverbed or Juniper wxc wan accelerator. We were wondering if you guys can give us some suggestion. We have 4mbps link between our two sides and we are using following applications and file systemWindows and Linux File, FTP, HTTP, HTTPS, MS SQL, MY SQL, Oracle, Exchange 2003, some time Novel, VOIP, Video Conference etcWe have around 300 workstations and 700 users on our remote site.In our price range we could get riverbed SteelHead 1520 and juniper wxc500. Both these products has advantages over others. we will really appreciate if any one of you could give us your experience.
Why is there a two for one tunnel penalty when connecting WX and WXC devices?
The WX is a memory only based compression device and uses more memory per tunnel when doing compression. The WXC has a disk it can leverage and therefore does not require as much memory per tunnel.
When you connect a WX to a WXC device the WXC has to allocate more memory to form that connection than it would when connecting to another WXC. The actual memory consumed on the WXC is less than what is required for two tunnels in most cases, but in order to provide tunnel scaling numbers that are deterministic we count this as two tunnels in WXOS 5.4 and above.
When WX enables OSPF feature, it does not generate any LSA at all. It is just listening to other LSAs going back and forth through WX. So, from routing perspective, it should not be a problem.Now about the WX scalability question: WX/WXC (except WX15) can hold up to 8192 routes in local route table.So, the quantity perspective, 1300 route is not an issue.
Head 2 head RiverBed 1520 or Juniper WXC
We are on the process of making decision on Riverbed or Juniper wxc wan accelerator. We were wondering if you guys can give us some suggestion. We have 4mbps link between our two sides and we are using following applications and file systemWindows and Linux File, FTP, HTTP, HTTPS, MS SQL, MY SQL, Oracle, Exchange 2003, some time Novel, VOIP, Video Conference etcWe have around 300 workstations and 700 users on our remote site.In our price range we could get riverbed SteelHead 1520 and juniper wxc500. Both these products has advantages over others. we will really appreciate if any one of you could give us your experience.
Tuesday, April 8, 2008
Pathetic Gunner with utter respect from the Reds
The reds shot them down.....gunner gonna concentrate on the EPL this weekend with only 5 matches to go and they are 6 points adrift from leader... So here is what the manager got to say...
``It was a great night and a fantastic game with six goals,'' Liverpool manager Benitez told reporters. ``Everyone is really happy.''
Five-time European champion Liverpool, last season's runner-up, will now face Chelsea in the last four of Europe's elite club competition for the third time in four years. Chelsea secured its spot with a 2-0 win against Fenerbahce last night that sealed a 3-2 win overall.
The semifinal openers are scheduled April 22-23 with the return games a week later. Liverpool edged Chelsea 1-0 over two matches in the 2005 semifinals before advancing in a penalty shootout last season after their quarterfinal finished 1-1.
`Tough Tie'
``I will think about Chelsea and the semifinal later,'' Benitez said. ``I know it will be a tough, tough tie.''
While Liverpool maintained its chances of collecting a trophy this season, Arsenal must now overhaul a six-point deficit to Manchester United in the Premier League to win a title.
the reds super fanatic fan...selangor
``It was a great night and a fantastic game with six goals,'' Liverpool manager Benitez told reporters. ``Everyone is really happy.''
Five-time European champion Liverpool, last season's runner-up, will now face Chelsea in the last four of Europe's elite club competition for the third time in four years. Chelsea secured its spot with a 2-0 win against Fenerbahce last night that sealed a 3-2 win overall.
The semifinal openers are scheduled April 22-23 with the return games a week later. Liverpool edged Chelsea 1-0 over two matches in the 2005 semifinals before advancing in a penalty shootout last season after their quarterfinal finished 1-1.
`Tough Tie'
``I will think about Chelsea and the semifinal later,'' Benitez said. ``I know it will be a tough, tough tie.''
While Liverpool maintained its chances of collecting a trophy this season, Arsenal must now overhaul a six-point deficit to Manchester United in the Premier League to win a title.
the reds super fanatic fan...selangor
Subscribe to:
Posts (Atom)
beach
cottesloe beach restaurant
City of Perth
view from King's park
Houston TX
San antonio
