Feed Mobile Hotspot Wrong Location to Change Ip Address Python
This document describes common problems and solutions for IP multicast.
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
When you troubleshoot multicast routing, the primary concern is the source address. Multicast has a concept of Reverse Path Forwarding (RPF) check. When a multicast packet arrives on an interface, the RPF process checks to ensure that this incoming interface is the outgoing interface used by unicast routing in order to reach the source of the multicast packet. This RPF check process prevents loops. Multicast routing does not forward a packet unless the source of the packet passes a RPF check. Once a packet passes this RPF check, multicast routing forwards the packet based only upon the destination address.
Like unicast routing, multicast routing has several available protocols, such as Protocol Independent Multicast dense mode (PIM-DM), PIM sparse mode (PIM-SM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast Border Gateway Protocol (MBGP), and Multicast Source Discovery Protocol (MSDP). The case studies in this document walk you through the process to troubleshoot various problems. You will see which commands are used in order to quickly pinpoint the problem and learn how to resolve it. The case studies listed here are generic across the protocols, except where noted.
This section provides a solution to the common problem of an IP multicast RPF failure. This network diagram is used as an example.
In this figure, multicast packets come into E0/0 of Router 75a from a server whose IP address is 1.1.1.1 and sends to group 224.1.1.1. This is known as an (S,G) or (1.1.1.1, 224.1.1.1).
Diagnose the Problem
Hosts directly connected to Router 75a receive the multicast feed, but hosts directly connected to Router 72a do not. First, enter the show ip mroute 224.1.1.1 command in order to see what is going on with Router 75a. This command examines the multicast route (mroute) for the group address 224.1.1.1:
75a#show ip mroute 224.1.1.1 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
Since the router runs PIM dense mode (you know it is dense mode because of the D flag), ignore the *,G entry and focus on the S,G entry. This entry tells you that the multicast packets are sourced from a server whose address is 1.1.1.1, which sends to a multicast group of 224.1.1.1. The packets come into the Ethernet0/0 interface and are forwarded out the Ethernet0/1 interface. This is a perfect scenario.
Enter the show ip pim neighbor command in order to see whether Router 72a shows the upstream router (75a) as a PIM neighbor:
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2
From the show ip pim neighbor command output, the PIM neighborship looks good.
Enter the show ip mroute command in order to see whether Router 72a has good mroute:
ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 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 - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:10:42/00:00:00 Ethernet3/2, Forward/Dense, 00:10:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags: Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:01:10/00:00:00 Ethernet3/2, Forward/Dense, 00:00:16/00:00:00 ip22-72a# You can see from the show ip mroute 224.1.1.1 command that the incoming interface is Ethernet2/0, while Etheret3/1 is expected.
Enter the show ip mroute 224.1.1.1 count command in order to see if any multicast traffic for this group arrives to the Router 72a and what happens next:
ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2032 bytes of memory 2 groups, 0.50 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: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471 Source: 1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0 ip22-72a# You can see from the Other counts that traffic gets dropped due to RPF failure: total 471 drops, due to RPF failure – 471…
Enter the show ip rpf <source> command in order to see if there is an RPF error:
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 1.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
Cisco IOS® calculates the RPF interface in this way. Possible sources of RPF information are Unicast Routing Table, MBGP routing table, DVMRP routing table, and Static Mroute table. When you calculate the RPF interface, primarily administrative distance is used in order to determine exactly which source of information the RPF calculation is based on. The specific rules are:
-
All preceding sources of RPF data are searched for a match on the source IP address. When you use Shared Trees, the RP address is used instead of the source address.
-
If more than one matching route is found, the route with the lowest administrative distance is used.
-
If the administrative distances are equal, then this order of preference is used:
-
Static mroutes
-
DVMRP routes
-
MBGP routes
-
Unicast routes
-
-
If multiple entries for a route occur within the same route table, the longest match route is used.
The show ip rpf 1.1.1.1 command output shows the RPF interface being E2/0, but the incoming interface should be E3/1.
Enter the show ip route 1.1.1.1 command in order to see why the RPF interface is different from what was expected.
ip22-72a#show ip route 1.1.1.1 Routing entry for 1.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1
You can see from this show ip route 1.1.1.1 command output that there is a static /32 route, which makes the wrong interface to be chosen as RPF interface.
Enter some further debug commands:
ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface
The packets come in on E3/1, which is correct. However, they are dropped because that is not the interface the unicast routing table uses for the RPF check.
Note: Debugging packets is dangerous. Packet debugging triggers process switching of the multicast packets, which is CPU intensive. Also, packet debugging can produce huge output which can hang the router completely due to slow output to the console port. Before you debug packets, special care must be taken in order to disable logging output to the console, and enable logging to the memory buffer. In order to achieve this, configure no logging console and logging buffered debugging . The results of the debug can be seen with the show logging command.
Possible Fixes
You can either change the unicast routing table in order to satisfy this requirement or you can add a static mroute to force multicast to RPF out a particular interface, regardless of what the unicast routing table states. Add a static mroute:
ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1
This static mroute states that to get to the address 1.1.1.1 for RPF, use 2.1.1.1 as the next hop which is out interface E3/1.
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (2.1.1.1) RPF route/mask: 1.1.1.1/32 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables
The output of show ip mroute and debug ip mpacket looks good, the number of sent packets in the show ip mroute count increases, and HostA receives packets.
ip22-72a#show ip mroute 224.1.1.1 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 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: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 1.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 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: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 1.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward
This section provides a solution to the common problem of IP multicast packets that are not forwarded because the Time To Live (TTL) value is decremented to zero. This is a common problem, as there are many multicast appplications. These multicast applications are designed primarily for the LAN usage, and thus set the TTL to a low value or even 1. Use this network diagram as an example. .
Diagnose the Problem
In the previous figure, Router A does not forward packets from source(S) to Router B's directly connected Receiver. Look at the output of the show ip mroute command on Router A in order to see the multicast routing state:
ROUTERA#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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00
You can ignore the 224.0.1.40 in the output since all routers join this Auto-RP Discovery group. But there is no source listed for 224.1.1.1. In addition to "*, 224.1.1.1" you should see "1.1.1.1, 224.1.1.1".
Enter the show ip rpf command in order to see if it is a RPF issue:
ROUTERA#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 1.1.1.0/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables
From the output, you see that it is not an RPF issue. The RPF check correctly points out E0/0 to get to the source's IP address.
Check whether PIM is configured on the interfaces with the show ip pim interface command:
ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 1.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 1.1.1.2 2.1.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 2.1.1.2
The output looks good, so this is not the problem. Check whether the router recognizes any active traffic with the show ip mroute active command:
ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps
Based on the output, the router does not recognize any active traffic.
ROUTERA#debug ip mpacket IP multicast packets debugging is on
Perhaps the Receiver is not sending any Internet Group Management Protocol (IGMP) reports (joins) for group 224.1.1.1. You can check it with the show ip igmp group command:
ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 2.1.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 3.1.1.2
224.1.1.1 has been joined on E1/2, which is fine.
PIM dense mode is a flood and prune protocol, so there are no joins, but there are grafts. Since Router B has not received a flood from Router A, it does not know where to send a graft.
You can check to see if it is a TTL issue with the sniffer capture and also seen with show ip traffic command:
ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options
The output shows 63744 bad hop counts. Each time you type this command, the bad hop count increases. This is a strong indication that the sender sends packets with a TTL=1, which Router A decrements to zero. This results in an increase of the bad hop count field.
Possible Fixes
In order to solve the issue, you need to increase the TTL. This is done at the application level on the Sender. For more information, refer to your multicast application instruction manual.
Once this is done, Router A looks like this:
ROUTERA#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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00
This is the sort of output you want to see.
On Router B you see:
ROUTERB#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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00
This section provides a solution to the common problem where the TTL threshold is set too low, so that IP multicast traffic does not reach the receiver. This network diagram is used as an example.
Diagnose the Problem
In the previous figure, the Receiver does not receive multicast packets from the Source. There might be several routers between the source and Router 75a. First look at Router 75a, since it is directly connected to the Receiver.
ip22-75a#show ip mroute 224.1.1.1 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 Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00
The output shows Router 75a forwards packets out Ethernet0/1. In order to be absolutely sure Router 75a forwards the packets, turn on debug just for this source and multicast group:
ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1 ip22-75a(config)
0 Response to "Feed Mobile Hotspot Wrong Location to Change Ip Address Python"
Postar um comentário