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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Bad default routes in 1720/21s causing VOIP traffic trouble?

Status
Not open for further replies.

573dawn

IS-IT--Management
Jun 13, 2007
300
US
Hi all I must have misnamed this thread before, maybe someone will look at it now. I have an Avaya IPO4 system that routes traffic across 3 T1 PTPs on Cisco 1720/21s to 3 remote locations.

One router, 192.168.0.200, connects 2 of the 3 back to the main site.

The other router, 192.168.0.199, connects the 3rd site.

A 3rd party brought in by my Avaya vendor had added
0.0.0.0 0.0.0.0 Null0 to the 192.168.0.200 router, and
0.0.0.0 0.0.0.0 192.168.0.200 to the 192.168.0.199 router.

We have had dropped call issues for quite a while now, and I THINK that maybe these routes were causing problems. I removed them both, as I have no reason to think that I have any routing loops, and in addition no reason to want traffic going from the main Avaya unit to 192.168.0.199 which would then try and send that traffic to 192.168.0.200.

It has been the site connected by 192.168.0.199 that has all of the problems.

Was this a sound decision?

Thanks, Dawn
 
i would suspect the T1 line before that route being your problem.. once a data stream has been started i really think a bad route would affect it the way you are explaining it.

are you taking errors or possible saturating that T1 link to the third site?

do you have any QOS on your links to ensure the voice always has bandwidth available?
 
plshlpme, I take very few errors and I do have QoS enabled between the two sites, normally the bandwidth is very underutilized anyway. What is interesting is that when looking at the stats for the QoS, only one packet type is registering as being assigned a priority. I think it was you who helped me out on that, and all is correct, no one knows why it is acting that way.
 
plshlpme, one more thing, one of the guys over at the Avaya forum just mentioned that ciscos sometimes block ACK requests between master/slave Avaya units, is there a way I can check that?
 
well for a cisco to be blocking something it would either have to be a broadcast of some sort.. or something that has been denied via an access-list.

it wouldnt make sense to allow some packets through and not others though.. if it was being blocked i would suspect your calls would never connect.

i would do some extended pings between the two locations and see if you are getting drops..

i dont have any avaya experience.. and actually very little voice experience as my customers have all managed their own voice systems so i cant help much there.

the fact that your seeing no errors (youve checked both ends of the t1 right?) and your not seeing discards in your qos

ex
sh policy-map interface s0/0

i would then look to the config of the avaya personally or possible some lan issue at that 3rd location since its the only one that seems to be having the problem.

do you have the same policy-map.

to get a better understanding we would probably have to start looking at the config of your routers though..
 
plshlpme, I was doing just that, and you know, it looks really bad. Routes between locations are varied and there is no consistency. I saw (and removed) one route that was for an IP that doesn't exist on my network. We had a 3rd party brought in when we did this because my experience is also limited to non-voice data, until now. I am usually pretty confident with this stuff, but when they started putting in the Avaya, I was over my head. Well, I think maybe the third party was too, and I am going to see if I can get it cleared up. I know more about the Avaya than I ever wanted to at this point.

I am going to go through the configs tomorrow while I'm at work, it will be easier there, no remote access delays. I may be posing some configs tomorrow, maybe even a new thread, if I can't figure it out myself.

If you want a look at them, I can post them :)
 
ya well take a look and if there is anything that doesn't jive for you post it up.. we can at least get the routing issues out of the way and get a better feeling for how its configured.
process of elimination with these types of troubles is sometimes the only way to get it resolved....
 
What times are you usually here? I'll keep working tonight or post up tomorrow after I've had a comprehensive look, whichever works best for you. I need all the help I can get at this point :)

Thanks, Dawn
 
lol im off work tomorrow so ill be in and out throughout the day.. i get notified on my blackberry so ill check in when i see your post :)
 
Thanks! I need a break, tomorrow sounds great. I appreciate the time you are taking even if not working, what else can I say :)
 
I think the only way Cisco can block those acks is by the Cisco proxy answering the SYN packets being sent from the phones, and if they don't respond proplerly, they can be dropped---I can't remember if the syn-wait time affects this, but I know this can be configured with TCP Intercept mode, if the image supports it.

Burt
 
Good Morning, I have been through my routes this morning and I think we have a mess. Let me start with the basics.

We have 4 locations, 3 are non-trouble sites for the phones, one is a nightmare:
Main (non-trouble)
1mm (non-trouble)
Hwy (non-trouble)
21mm (TROUBLE)

Here are the basic setting for each:
Main router #1 goes to 1mm & Hwy
fa0 192.168.0.200/24
se0 to Hwy 192.168.254.1/30
se1 to 1mm 192.168.254.5/30
IP ROUTES
IP classless
IP route 10.0.0.0 255.0.0.0 se0
IP route 192.168.0.0 255.255.255.0 se0
IP route 192.168.2.0 255.255.255.0 se1
IP route 192.168.3.0 255.255.255.0 192.168.0.199
no IP http server

Main router #2 goes to 21mm
fa0 192.168.0.199/24
se0 to 21mm 192.168.254.10/30
IP ROUTES
IP classless
IP route 192.168.3.0 255.255.255.0 se0
IP route 192.168.3.0 255.255.255.0 192.168.254.9
no IP http server

Router at the 1mm:
fa0 192.168.2.1/24
se0 192.168.254.6/30
IP ROUTES
IP classless
IP default gateway 192.168.254.5
IP route 0.0.0.0 0.0.0.0 se0
no IP http server

Router at Hwy:
fa0 10.10.1.1/8
se0 192.168.254.2/30
IP ROUTES
IP classless
IP route 0.0.0.0 0.0.0.0 192.168.254.1
no IP http server

Router at the 21MM:
fa0 192.168.3.199/24
se0 192.168.254.9/30
IP ROUTES
IP classless
IP route 0.0.0.0 0.0.0.0 se0
no IP http server

thoughts?





 
ok im gonna take a look here..
does each location have its own internet connection? or do they go through the main site.
 
each location has a separate internet connection brought in on cable modem from the local provider. The connection is shared by broadband router, which are the gateways for the desktops, but NOT the phone units. As far as the phone units are concerned, the ciscos are their gateways and they have no idea the broadband routers exist.

Each broadband, and each phone unit, are plugged into a switch to which the cisco is also connected.
 
so basically each branch office site should only have one route

ip route 0.0.0.0 0.0.0.0 s0

because each branch only has one path to the network...

main routers 1 and 2 need to have a route to all three branch offices

Main1
(1mm)
ip route 192.168.2.0 255.255.255.0 se1
(hwy)
ip route 10.0.0.0 255.0.0.0 se0
(21mm)
ip route 192.168.3.0 255.255.255.0 192.168.0.199


Main2
(1mm)
ip route 192.168.2.0 255.255.255.0 192.168.0.200
(hwy)
ip route 10.0.0.0 255.0.0.0 192.168.0.200
(21mm)
ip route 192.168.3.0 255.255.255.0 s0

i assume here too that your main routers are just plugged into a switch and that there is nothing fancy going on there..

so your config is pretty good.. there are a couple routes that are basically doing the same thing and a couple missing from main2 to get back to sites 1 and 2...

unless your running a routing protocol on your lan between main1 and main2?


 
No,no routing protocol, static only. I will make the changes, and thank you again.

I will be back on the board in just a bit, going to a real sit-down lunch :)
 
plshlpme, back from a great lunch at the Outback, full of steak :)

I have removed all routes except what you have listed above, modified where necessary, left in IP classless & no IP http server on all.

I do have managed switches at the Main, Hwy, & 21mm locations. They have Ip's assigned and auto-negotiate port speeds, all of which are showing full/100Mb.

At the Main & 21mm I have just the Avaya DS unit, the Cisco, the Internet broadband, and the link to the unmanaged switches the desktops are plugged into the managed switch (and my pc), all other workstations are on an unmanaged switch.

At the Hwy, everything is plugged into the managed switch.

At the 1mm, I don't have a managed switch (yet).
 
sweet steak.
so the managed switch at the location in question doesn't show anything in its log then either?

it would be nice if one of these devices would shed some light onto the problem.
 
It was yummy :) I don't know to be honest. I know very little about the mamaged switches. They are Avaya P133GT2s and we were recommended by our Avaya BP to install them when we ran into major problems with the new phone equipment from the outset (and I am finding out that is because the BP made alot of mistakes in the initial config, thank God for the Avaya forum!).

In retrospect I'm not sure we really needed them, but I will see if I can pull logs and find out more about what is going on on them

For a while I had a "fade" problem at the 21mm, where one party could hear all, but the other party could hear nothing, that turned out to be an addressing mistake on my part, I had addressed the switch the same as the fa port on the cisco there. Once I corrected it, the fade went away, but the drops kept on coming.
 
I could start an entire forum on Outback...mmmmmm...bloomin' onion...

Burt
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top