Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Delayed dialtone on G700/S8300 LSP? 1

Status
Not open for further replies.

98Converter

Technical User
Sep 17, 2001
1,816
US
I have complaints of folks getting delayed dialtone off a remote location G700/S8300 LSP. I can confirm the following:

MG-079-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/46192
10.90.90.0 255.255.255.0 10.90.90.13 motfec0 (101/0/0)

MG-079-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.13


But when I try and do a show ip route static:

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

DESTINATION MASK GATEWAY
--------------- --------------- ---------------

Operation Failed

The entry does not exist



How do you populate this? And do you think this could be causing my delay?

If I ping the VoIP module it only pings 1 out 4 pings. Same with the P330... The S8300 and MGP ping without any problems.

Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
This sounds similar to a problem we were having. The inspection on H.232 had to be removed for the phones to work.
 
The phones work... Just a delayed dialtone and they have to press the digits slowly. Doesn't happen all the time though.

What do you mean by turning off H.323 inspection? On the firewall? In our environment - there is no firewall.

Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
what is the latency when you ping to the remote site.

Are you going over VPN tunnels via the internet or via an MPLS network link.


[Started on Version 3 software 15 years a go]
 
Relatively short round trip... This is the same for all our international sites.

We have 2Mbps MPLS link into the site.


Reply from 10.90.90.13: bytes=32 time=96ms TTL=59
Reply from 10.90.90.13: bytes=32 time=101ms TTL=59
Reply from 10.90.90.13: bytes=32 time=96ms TTL=59
Reply from 10.90.90.13: bytes=32 time=96ms TTL=59

Ping statistics for 10.90.90.13:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 96ms, Maximum = 101ms, Average = 97ms


Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
I wouldn't think latency would be an issue, as the phones should get dialtone locally from the G700 - I think this is where the problem is... Can only get 25% ping to VoIP.

Any other thoughts?



Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
*Update: delay has disappeared, however we can't ping the VoIP or Stack from a CLAN at the main site... And they can't get analog station calls from site to site. Internally, meaning at the site in question, they can dial analog extensions fine. Wierd...

3A05 is a CLAN in NR 1

ping ip-address 10.90.90.12 board 03A05 repeat 5

STACK PING RESULTS

End-pt IP Port Port Type Result Time(ms) Error Code

10.90.90.12 03A0517 ETH-PT PASS 110
10.90.90.12 03A0517 ETH-PT FAIL 1007
10.90.90.12 03A0517 ETH-PT FAIL 1007
10.90.90.12 03A0517 ETH-PT FAIL 1007
10.90.90.12 03A0517 ETH-PT FAIL 1007


ping ip-address 10.90.90.16 board 03A05 repeat 5

VOIP PING RESULTS

End-pt IP Port Port Type Result Time(ms) Error Code

10.90.90.16 03A0517 ETH-PT FAIL 1007
10.90.90.16 03A0517 ETH-PT FAIL 1007
10.90.90.16 03A0517 ETH-PT FAIL 1007
10.90.90.16 03A0517 ETH-PT FAIL 1007
10.90.90.16 03A0517 ETH-PT FAIL 1007


Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
I've seen this exact thing before. It happened to me. The VOIP and the MGP should not have the same default gateway. In your case they are both .13. That isn't right. Whatever their IP is what the default gateway should be. So if the IP of the MGP is .13 then the DG should be .13. If the VOIP is .14 then DG should be .14.

When this happened to me I had to nvramint and start over.


MG-079-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/46192
10.90.90.0 255.255.255.0 10.90.90.13 motfec0 (101/0/0) <--- This should not be the same as the VOIP.

MG-079-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.13 <--- This should not be the same as the MGP.
 
Can this be done from the CLI?

When I clear it - it clears it for both MGP & VoIP and when I try and set it, the only command I see is:

set ip route

There is no set ip route voip v0 or set ip route mgp...

The gateway is 4000 miles away, so I can't direct connect to it, so an NVRAM is a little risky over dialup.



Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
phoneguy55, if you look at the table, the "0.0.0.0" entry is the default gateway for non local address's (10.90.90.1), and for the 10.90.90.0 LAN, it is saying to use the local IP interface. This is perfectly normal, and there is nothing wrong.

The MGP and the VOIP should be using separate interfaces, since they are supposed to have separate IP interface IP's, however, in some software versions, it does show like this.

I would suggest updating the firmware to the latest release, which is 29.24, and see if you still have the issue.

post a "show image version" so we can see what firmware you are running in the MGP





Mitch

AVAYA Certified Expert
 
My suggestion is these routes. These would be set via a 'set ip route' command. From what I've seen in my G700's when the DG are both the same, in this case 10.90.90.13, you could have voice quality issues.

show ip route mgp
10.90.90.0 255.255.255.0 10.90.90.13 motfec0 (101/0/0)
show ip route voip v0
10.90.90.0 255.255.255.0 10.90.90.13 motfec0 (101/0/0)

Also when you 'show IP route static' you should not see operation failed. That isn't good. He should see 0.0.0.0 0.0.0.0 10.90.90.1. When this happened to me. I wanted to try to change the IP route of voip V0. It wouldn't let me do it, so I did nvraminit and started over. This fixed all my issues which were the same as described.
 
One more thing. As far as doing it remotely, I did it (via the WAN not dialup) and had no problems. Here's how I did it.

Telnet to IP address of S8300
Telnet to 127.1.1.1 Now you are in the P330 stack.
run command ‘session mgp’

This will ensure that when you do 'reset mgp', you will get logged out back to the stack.
 
P330-1(super)# show image version
Mod Module-Type Bank Version
------ ----------- ---- -------
1 Avaya G700 Media Gateway A 0.0.0
1 Avaya G700 Media Gateway B 4.1.9

MG-079-1(super)# show sys

Uptime(d,h:m:s): 5, 14:00:02

System Name : MG-079
System Location: REMOTE SITE
System Contact : -- Empty --
MAC Address : 0X
Serial No : 0X
Model No : G700
HW Vintage : 08
HW Suffix : C
FW Vintage : 27.27.0

Thanks for the insight - makes sense to go the 127 address. Didn't think of that...



Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
What happens when I remove the routes and addresses and then reset the MGP? As long as I don't loose my connection to 127.1.1.1 I should be all set?





Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
Yup. I really think you going to need to nvram init and start over. I did when I had this issue.

I would start by backing up the MGP config. You'll need a TFTP server. 'copy mgp-config tftp data.dat 10.X.X.X'. This way you have a backup if things go really bad. I didn't do this step but I will next time.

After your nvram init and reset mgp you'll be back in the stack. Then you session mgp and you be in your MGP. It will have no configuration and you'll need to rebuilt it. Use the cheat to help you rebuild.
 
I'm guessing I shouldn't NVRAM the Stack... or should I?

I can't seem to ping the stack consistently either.

Same process?



Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
I would start with the MGP and go from there. When my MGP config got messed up it was only the MGP. I didn't need to change the stack.
 
Ughh... been busy.

But now that I've gone and done this, the routes all look better, but I still can't get a reliable ping to the VoIP...

MG-079-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-1B-4F-00-1C-C7
voip-v0 S 1 10.90.90.16 255.255.255.0 00-1B-4F-00-1C-C8

MG-079-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.16

MG-079-1(super)#
MG-079-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/1/4323)
10.90.90.0 255.255.255.0 10.90.90.13 motfec0 (101/0/0)

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

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


Any other ideas? Should I NVRAM the Stack? Can I do this without losing connection if I telnet to the MGP?

Thanks,
98C

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top