07-16-2012 03:16 AM - last edited on 03-07-2019 07:47 AM by NikolaIvanov
I'm hoping somebody can point me in the right direction for a problem I'm experiencing... I have attached a basic diagram to hopefully make sense of my explanation of the problem.
I have 3 3560 switches which are configured with trunks between them. They run vlan 10, 11 & 12.
I have a 'core' switch (switch 1) of these 3 to which an MPLS router is connected on vlan12.
I in addition have another switch hanging off the 'core' switch via a routed link (switch 4). I have EIGRP configured as a stub and as such the IP address on the routed link at the core switch end is of a /24 from vlan 1 on the other switch. This makes the route directly connected and therefore distributed via EIGRP stubs.
Switch 1 is then exchanging routes with the MPLS router (via EIGRP).
The problem I have is that from any subnet on any switch (switch 1, 2 or 3) I can ping 192.168.13.1 (switch 4). When I try and ping switch 4 from over the MPLS I am unable to. If I trace to the switch I see it reaches the outside of the MPLS router, but is then unresponsive. The same applies if I try to ping switch 1 on 192.168.13.2. Any of the other IP addresses of switch 1 respond.
The MPLS network is a managed solution to which I have no access. I'm told that the MPLS provider is able to ping switch 1 & switch 4 on the 192.168.13.x addresses from a remote router (192.168.32.2). I have tried from a switch on the same L2 subnet (192.168.32.1) and I don't get a response.
From switch 4 I am able to ping the switch on 1 of it's interfaces (192.168.19.1), but not the interface I mentioned above 192.168.32.1
There are no access lists in place on the switches and no firewalls between the sites.
I have no idea where to start troubleshooting this, and any assistance would be much appreciated.
Thanks,
Neil
07-19-2012 08:08 AM
I'm just working on getting all the info together Peter then I shall post it.
Would this information be best collated from the CPE nearest the switch? I notice they have pulled this from a remote switch at another site.
Thanks very much.
Neil
07-19-2012 08:18 AM
I have all the information now. These were taken from a remote router, not the router adjacent to the switches in question.
I have substited the IP addressing, however in this case the summary address is no longer correct. In reality it is...
RO-ROUTER-2801#sh ip route 192.168.13.2 1
Routing entry for 192.168.10.0/22, supernet
Known via "eigrp 100", distance 90, metric 31232, type internal
Redistributing via eigrp 100
Last update from 172.18.30.177 on FastEthernet0/0, 2d18h ago
Routing Descriptor Blocks:
* 172.18.30.177, from 172.18.30.177, 2d18h ago, via FastEthernet0/0
Route metric is 31232, traffic share count is 1
Total delay is 220 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 14/255, Hops 3
RO-ROUTER-2801#sh ip route 192.168.13.1 2
Routing entry for 192.168.10.0/22, supernet
Known via "eigrp 100", distance 90, metric 31232, type internal
Redistributing via eigrp 100
Last update from 172.18.30.177 on FastEthernet0/0, 2d18h ago
Routing Descriptor Blocks:
* 172.18.30.177, from 172.18.30.177, 2d18h ago, via FastEthernet0/0
Route metric is 31232, traffic share count is 1
Total delay is 220 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 14/255, Hops 3
RO-ROUTER-2801#show ip cef 192.168.13.1 internal
192.168.10.0/22, epoch 0, RIB[I], refcount 5, per-destination sharing
sources: RIB
feature space:
IPRM: 0x00028000
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 22
ifnums:
FastEthernet0/0(3): 172.18.30.177
path 68BEA950, path list 68D91744, share 1/1, type attached nexthop, for IPv4
nexthop 172.18.30.177 FastEthernet0/0, adjacency IP adj out of FastEthernet0/0, addr 172.18.30.177 68BF7BE0
output chain: IP adj out of FastEthernet0/0, addr 172.18.30.177 68BF7BE0
RO-ROUTER-2801#show ip cef 192.168.13.2 internal
192.168.10.0/22, epoch 0, RIB[I], refcount 5, per-destination sharing
sources: RIB
feature space:
IPRM: 0x00028000
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 22
ifnums:
FastEthernet0/0(3): 172.18.30.177
path 68BEA950, path list 68D91744, share 1/1, type attached nexthop, for IPv4
nexthop 172.18.30.177 FastEthernet0/0, adjacency IP adj out of FastEthernet0/0, addr 172.18.30.177 68BF7BE0
output chain: IP adj out of FastEthernet0/0, addr 172.18.30.177 68BF7BE0
If you need anything else, please let me know.
Cheers,
Neil
07-19-2012 07:50 AM
HI Neil,
where is no auto-summary?
Alessio
07-19-2012 08:06 AM
Hello Alessio,
Is it possible it's a default on this version of code? We are using 192.168.x.x addresses elsewhere and not seeing any routing issues.
Thanks,
Neil
07-19-2012 08:33 AM
Hi Neil,
i wasn't really thinking about the RFC1918 but about the original classful nature of EIGRP.Read cisco website here:
To restore the default behavior of automatic summarization of subnet routes into network-level routes, use the auto-summary command in router configuration mode. To disable this function and transmit subprefix routing information across classful network boundaries, use the no form of this command.
Alessio
07-20-2012 01:01 AM
Hi Alessio and Neil,
Alessio, you have an eagle eye for spotting this! Indeed, the automatic summarization in Neil's EIGRP configuration does seem to be activated. It is deactivated by default only starting with IOS versions 15.x. Nevertheless, this does not look like to be the reason for the problems here - although I would certainly suggest using the no auto-summary on all Neil's routers just in case. Please note that this change will lead to EIGRP resyncing the topology databases with all its neighbors.
Neil, I am not sure from which router does the requested output come from. Is that very router capable of actually successfully pinging the 192.168.13.1 and 192.168.13.2?
I will really have to rethink the entire case here, as the displayed information do not provide any clues which could explain why only some IP addresses in a common IP network would be reachable.
Best regards,
Peter
08-08-2012 05:34 AM
Allessio/ Peter,
Thanks for your assistance with this. I thought I would update you as I have identified the cause. I'm not yet certain to the solution.
This was being caused because switch 2 didn't have a route to switch 1 (192.168.13.2). Whilst it was learnt via EIGRP, the route was a summary route and had a next hop of null.
In addition to this, the route over the wan was round robin'ing between the two routers and subsequently the 2 switches because the metrics on EIGRP were the same.
Neil
08-11-2012 03:09 PM
Neil
It's nice to hear from you again!
This was being caused because switch 2 didn't have a route to switch 1 (192.168.13.2). Whilst it was learnt via EIGRP, the route was a summary route and had a next hop of null.
Hmm, Alessio pointed out that this may be the problem but at the time, I have dismissed it because I did not see any discontiguous networks in your topology. But this was obviously caused by the fact that you have changed the IP addresses for privacy reasons. You may have inadvertently misled us into believing that your network does not have discontiguous networks or subnets subject to auto summarization while there were some, obviously.
The summary route "learned" via EIGRP with the next hop interface of Null0 is not really learned - it is generated and injected into your routing table by the router itself. This happens automatically when the router performs summarization, and hence, the occurence of such network in your routing table suggests that a summarization is taking place.
I guess lots of misunderstanding was caused by the changed IP addressing...
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide