Can't tracert or Ping VoIP or Stack...

[98Converter]

Having a problem where we can ping the mgp, and S8300 without any problems. The G700/S8300 register fine to the main site - but we can't seem to ping the VoIP or Stack consistently.

We've swapped out the entire G700 but still have the same results... I can ping from the mgp to all the addresses without any problems. (ping mgp 10.x.x.voip, stack, s8300).

Any thoughts?

MG-XXX-1(super)# show mg l

SLOT TYPE CODE SUFFIX HW VINTAGE FW VINTAGE VOIP FW
---- ------ ----- ------ ---------- ----------- -------
v0 G700 DAF1 C 08 26.33.1(B) 72
v1 ICC S8300 C 2 4 N/A
v2 DS1 MM710 B 11 44 N/A
v3 ANA MM711 A 63 89 N/A
v4 ANA MM711 A 63 89 N/A

I unfortunately don't have anyone on-site that can use a cross-over cable from their laptop to the G700 to rule out the LAN, but looking for all advice.

CM4.x

Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[9mmgeek]

Masks and default routes.....they all have their own and it looks like the voip and stack are not correct. You can see the voip setup by connecting the mgp.

sh interface show both address and masks
sh ip route mgp route the mgp route table
sh ip route voip shows the voip route table

you can change the voip from here.

After that enter session stack to connect to the stack and check the interface and route config there

sh interface
sh ip route

 

[9mmgeek]

I guess I assumed the addresses are correct, check those too.

 

[98Converter]

I've gone through these exercises on a previous post that died (thread690-1566391), but looking for any other ideas. Thanks and keep em coming... I'm grasping here-

MG-xxx-1(super)# show interface

OPERATIONAL STATE: -- Currently in use --

INTERFACE SRC VLAN IP ADDRESS NETMASK MAC ADDRESS
--------- --- ---- --------------- --------------- -----------------
mgp S 1 10.90.90.13 255.255.255.0 00-04-0D-F9-38-98
voip-v0 S 1 10.90.90.15 255.255.255.0 00-04-0D-F9-38-99

MG-xx-1(super)# show ip route mgp

DESTINATION MASK GATEWAY INTERFACE (F/C/U)
--------------- --------------- --------------- ---------- -----------
0.0.0.0 0.0.0.0 10.90.90.1 motfec0 (3/3/9318)
10.90.90.0 255.255.255.0 10.90.90.13 motfec0 (101/0/0)

MG-xxx-1(super)# show ip route voip v0

DESTINATION MASK GATEWAY
--------------- --------------- ---------------
0.0.0.0 0.0.0.0 10.90.90.1
10.90.90.0 255.255.255.0 10.90.90.15

MG-xxx-1(super)# show ip route static

DESTINATION MASK GATEWAY
--------------- --------------- ---------------
0.0.0.0 0.0.0.0 10.90.90.1


P330-1(super)# show interface
Interface Name VLAN IP address Netmask
-------------------- ---- --------------- ---------------
inband 1 10.90.90.12 255.255.255.0
ppp disabled 1 0.0.0.0 0.0.0.0
P330-1(super)# show ip route
Destination Gateway
------------- -------------
0.0.0.0 10.90.90.1
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0 0.0.0.0
P330-1(super)#

Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[9mmgeek]

This is a different box than the previous thread, different mac addresses, but it has the same mgp ip address and a different voip address.

With all that history it sounds like a network issue to me.
Run a trace route from both ends to narrow down where the problem is. It will be the other side of the last thing that answers or in that device. Then run one from a device that works so you can see what the whole path should look like.

Try clearing the arp table in the router 10.90.90.1.


See if there are any etherchannels(cisco term) in the data path. Other vendors call them trunks (not the same as cisco trunks). These are bundles of interfaces that the switches use as a single link in a point to point connection between switches. They use an algorithm to decide which physical link to use BASED ON THE IP ADDRESSES IN THE PACKET. If one of those interfaces is not working but the switch thinks it is it can throw packets into a black hole without knowing it. I have seen this many times. Some hosts work and others dont because of their different ip addresses.

It can be caused by a one way link failure or by a link that is configured to be in the channel on one switch but got plugged into something else (not the channel) on the other switch.

 

[98Converter]

9mmgeek - thanks for the suggestions.

We replaced the G700, therefore different MACs... I'll throw your suggestions to the NetEng group.

Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[98Converter]

Finally... Solution:

duplicate IP addresses on the core switch (actually the duplicate IP was the core switch).

We were able to mirror the port and ran wireshark to get to the bottom of it. With a simple ping we saw 2 different MAC's for the same address which made no sense. We killed the 2nd port that the odd MAC was plugged into and everything started working seemlessly...

Thanks for everyone's assistance.

Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.