I don’t have access to real gear and don’t trust emulators or simulators completely, so I’m speculating here (although of course even between real gear, there could be differences due to IOS versions or hardware). But if the problem IS with the ACLs on RouterA and RouterB, then this would’ve eventually been our conclusion anyway and if the issue was somewhere along the path with the specific IP of host A, this way, we know for sure - or not?įollowing these steps, couldn’t we replicate exactly what happens when host A pings host B, or any other device? If I’m not mistaken, this would be an exact replication of what happens to the IP packets as they travel through the network (so we could check if for example an ACL is blocking the IP address, or a firewall, or anything else specific to what used to be host A’s IP address). So the possible sources of error could be (if RouterA and RouterB are directly connected via a cable):Ī) incoming ACL on RouterA (on the interface facing host A),ī) outgoing ACL on RouterA (on the interface facing RouterB),Ĭ) incoming ACL on RouterB (on the interface facing RouterA),ĭ) outgoing ACL on Router B (on the interface that’s in the direction of host B),Īs we know, the ACL rules on any router don’t apply to packets sourced from that router, so troubleshooting the ACLs by analyzing their statements line-by-line at this point might become inevitable, so the debug command won’t necessarily save us. If RouterA could ping host A, we know that there must be an ACL on RouterA, or RouterB that’s the problem (if RouterA and RouterB are directly connected via a cable).If it turns out that the ping to host B, which is sourced from the LoopbackA interface of RouterB, is successful, we can conclude that there’s no problem along the path to host B.using what used to be host A’s IP address). Finally, from RouterB, we do an extended ping, and we source the ping from LoopbackA (i.e.(We can’t configure host A’s IP address on RouterA, because there would be an error message that says that the newly configured IP address overlaps with the one that is RouterA’s LAN IP address, the one that’s in host A’s subnet.) Let’s call the loopback interface LoopbackA. On RouterB, we configure as a new loopback IP address (what used to be) host A’s IP address. Which router is the best choice? I think it is the next hop router along the path to host B (host B is the destination that host A can’t reach). Let’s call host A’s default gateway RouterA. Next, we configure a loopback IP address on a router that’s close to host A’s default gateway.Then, on the switch that host A connects to, we shut the switchport that connects host A to the network.First, on the DHCP server, we add host A’s IP address as an excluded address, so that it doesn’t get leased in the future.(The first two steps may even just be optional.) If host A can’t ping host B, can’t we test host A’s IP addresss if we follow these steps?: This may help you to troubleshoot your issue further. Look at this lesson that further discusses ICMP redirects, when they occur and what they’re used for. You may need to readjust your configuration somehow, but we can’t know without a detailed view of your topology. I have the impression that when you use an SVI as the source, for some reason, there are ICMP redirects taking place. You should also consider your topology and the way it is set up. Can you further explain your statement, as it is not entirely clear? You mentioned something about drops in the queue, ICMP redirect, and CPU. Try testing with different packet sizes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |