Routing - odd behaviour

[#1]

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

[#2]

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

[#3]

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

[Alessio Andreoli]

HI Neil,

where is no auto-summary?

Alessio

[#5]

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

[Alessio Andreoli]

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

[Peter Paluch]

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

[#8]

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

[Peter Paluch]

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