not able to ping using LAN interface

Muzzamil Hussain · ‎12-03-2011

Dear All,

i have a branch connected to our Data Center and wr are running OSPF between us and SP , and between all the branches and Data center we are using EIGRP

i recently deployed one branch and its working fine but when i am trying to access other braches LAN from this branch its failing if i sourced my packets from the branch lan

but if its sourced from the WAN interface its working fine.

bellow is the same extracted from the router:

R1#sh ip rou 172.16.119.22 !----------------Branch B Lan ---------------!

Routing entry for 172.16.119.0/24

Known via "eigrp 90", distance 100, metric 15787776, type external

Redistributing via eigrp 90

Last update from 192.168.246.10 on Tunnel1, 00:46:39 ago

Routing Descriptor Blocks:

* 192.168.246.10, from 192.168.246.1, 00:46:39 ago, via Tunnel1

Route metric is 15787776, traffic share count is 1

Total delay is 550050 microseconds, minimum bandwidth is 1500 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 100/255, Hops 2

R1#ping 172.16.119.22 !----------------Using WAN interface---------------!

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.119.22, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

R1#ping 172.16.119.22 sou f0/0 !----------------Using LAN interface---------------!

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.119.22, timeout is 2 seconds:

Packet sent with a source address of 172.16.168.34

.....

Success rate is 0 percent (0/5)

R1#trac 172.16.119.22

Type escape sequence to abort.

Tracing the route to 172.16.119.22

1 192.168.246.10 8 msec 8 msec 8 msec !----------------Branch B DMVPN Tunnel Interface---------------!

2 172.16.110.1 8 msec 12 msec 8 msec !----------------Branch B CORE SW VLAN INTERFACE ---------------!

3 172.16.119.22 4 msec * 8 msec !----------------Branch B DESTENATION NETWORK---------------!

R1#s

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 172.16.168.34 YES NVRAM up up !----------------LAN INTERFACE---------------!

FastEthernet0/1 10.2.0.109 YES NVRAM up up !----------------WAN INTERFACE---------------!

BRI0/1/0 unassigned YES NVRAM administratively down down

BRI0/1/0:1 unassigned YES unset administratively down down

BRI0/1/0:2 unassigned YES unset administratively down down

Serial0/3/0:0 unassigned YES unset down down

Serial0/3/0:1 unassigned YES unset down down

Serial0/3/0:2 unassigned YES unset down down

Serial0/3/0:3 unassigned YES unset down down

Serial0/3/0:4 unassigned YES unset down down

Serial0/3/0:5 unassigned YES unset down down

Serial0/3/0:6 unassigned YES unset down down

Serial0/3/0:7 unassigned YES unset down down

Serial0/3/0:8 unassigned YES unset down down

Serial0/3/0:9 unassigned YES unset down down

Serial0/3/0:15 unassigned YES NVRAM up up

NVI0 192.168.168.34 YES unset up up

Loopback0 192.168.168.34 YES NVRAM up up

Tunnel1 192.168.246.27 YES NVRAM up up

Tunnel2 192.168.247.27 YES NVRAM up up

Tunnel3 192.168.250.27 YES NVRAM up up

Tunnel4 192.168.251.27 YES NVRAM up up

R1#

please advise.

Regards.

nkarpysh · ‎12-03-2011

Hello,

The problem seems to be on remote routers not having route back to your LAN interface on router R1. Other posibility is that there is ACL configured on the way blocking traffic sourcing from that LAN interface. You need first to go to remote direction you are pinging and check if you have a route to 172.16.168.34 then check it hop by hop coming closer to this source.

Simultaneously please check the ACL which might have been blocking it.

Nik

HTH,
Niko

Muzzamil Hussain · ‎12-04-2011

Thanks Nikolay for your replay

yes I forgot to mention it that there is no router in that branch pointing back to this router

sh ip rou 172.16.168.34

% Subnet not in table

but when i check our Data Center router i can see all the routes over there , the issue is only with this branch:

here is how ip route from Data Center :

DC_R1#sh ip rou 172.16.168.32

Routing entry for 172.16.168.32/27

Known via "eigrp 90", distance 90, metric 12885760, type internal

Redistributing via eigrp 90

Last update from 192.168.246.27 on Tunnel1, 01:47:28 ago

Routing Descriptor Blocks:

* 192.168.246.27, from 192.168.246.27, 01:47:28 ago, via Tunnel1

Route metric is 12885760, traffic share count is 1

Total delay is 500100 microseconds, minimum bandwidth is 30769 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 125/255, Hops 1

DC_R1#sh ip rou 172.16.168.64

Routing entry for 172.16.168.64/27

Known via "eigrp 90", distance 100, metric 14507776, type external

Redistributing via eigrp 90

Last update from 192.168.246.27 on Tunnel1, 01:37:53 ago

Routing Descriptor Blocks:

* 192.168.246.27, from 192.168.246.27, 01:37:53 ago, via Tunnel1

Route metric is 14507776, traffic share count is 1

Total delay is 500050 microseconds, minimum bandwidth is 1500 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 120/255, Hops 1

DC_R1#sh ip rou 172.16.168.96

Routing entry for 172.16.168.96/27

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 3

Last update from 10.2.0.2 on GigabitEthernet0/1, 3d21h ago

Routing Descriptor Blocks:

* 10.2.0.2, from 194.170.135.63, 3d21h ago, via GigabitEthernet0/1

Route metric is 20, traffic share count is 1

and the only network known to the branches is the OSPF network non of EIGRP is know to the barcnhes

nkarpysh · ‎12-07-2011

I replied before - but for some reason it did not attach.

SO close to remote branch you are pinging you need to have EIGRP redistributed to OSPF or have a default route pointing to EIGRP AS to make ping work.

Nik

HTH,
Niko