Static IP Routes in IPO4 units, Could bad route cause drops?

[573dawn]

Hi All, I am a posting fool today When our system was setup, static IP routes were added by the BP. One of them was:

0.0.0.0 0.0.0.0 192.168.0.200

where 192.168.0.200 is a cisco router.

Sounds ok, BUT, 192.168.0.200 is one router that connects 2 remote sites to the main site. Neither of those sites has many problems. So 192.168.0.200 conncts to routers 192.168.2.1 and 10.10.1.1

Meanwhile, my trouble site has a different router, 192.168.0.199, and it connects only to router 192.168.3.199

SO the routes in the main DS are (all DS units end in .180):
0.0.0.0 0.0.0.0 192.168.0.200
10.10.1.180 255.255.255.0 10.10.1.1
192.168.2.180 255.255.255.0 192.168.2.1
192.168.3.180 255.255.255.0 192.168.3.199

So I am wondering if the 0.0.0.0 0.0.0.0 192.168.0.200 should be there at all since it only includes 2 of 3 remote sites?

On the remote DS units routes look like this (using my trouble site as an example):

10.10.1.180 255.255.255.0 192.168.3.199
192.168.2.180 255.255.255.0 192.168.3.199
192.168.0.180 255.255.255.0 192.168.3.199

Also, every DS has a "remote management" route of:

192.168.99.0 255.255.255.0 0.0.0.0

Which I don't think should be there, as we aren't managed remotely.

I am just wondering if any of this has an impact on our dropped calls. Incidentally, ATT was out this morning at our trouble site looking at the grounding and mentioned that they thought our BP should be working harder on this, but since they aren't...

Thanks, Dawn

 

[mattKnight]

IMHO, the IPO static route should point to the local default gateway

So
10.10.1.180 255.255.255.0 10.10.1.1
192.168.2.180 255.255.255.0 192.168.2.1
192.168.3.180 255.255.255.0 192.168.3.199

should all be

10.10.1.180 255.255.255.0 192.168.0.200
192.168.2.180 255.255.255.0 192.168.0.200
192.168.3.180 255.255.255.0 192.168.0.200

much like the remote is set.

You might also try running a ping (with -t) switch from 2 pcs (1 with IPO Office as default gateway and 1 with the cisco router as gateway) Keep looking for IP packet loss and then make the chnages above and try again.


Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[ProviderReborn]

The 0.0.0.0 0.0.0.0 192.168.0.200 will route everything. I like matts aproach to this above.

also the 192.168.99.0 routes a remote connection via your trunk to the LAN on your system. Dont remove this without talking to your support people. As if they dial in via an ISDN connection you may upset them when they cannot get into your unit.

 

[573dawn]

mattKnight, wouldn't that go against the basic rules of addressing though? For instance, at the troubled remote site the lan is 192.168.3.x, where

192.168.3.180 is the DS
192.168.3.199 is the default gateway local to the remote location, connecting back to
192.168.0.199, the router at the Main Site connecting to
192.168.0.180, the MAIN DS unit where the PRI comes in.

So is what you are saying that ONLY at the MAIN DS, the routes should point to the default GWs of:

10.10.1.180 255.255.255.0 192.168.0.200
192.168.2.180 255.255.255.0 192.168.0.200
192.168.3.180 255.255.255.0 192.168.0.199


And at the REMOTE sites, they should be (using the 192.168.3.x as example):

10.10.1.180 255.255.255.0 192.168.3.199
192.168.2.180 255.255.255.0 192.168.3.199
192.168.0.180 255.255.255.0 192.168.3.199

AND the route 0.0.0.0 0.0.0.0 192.168.0.200 should be REMOVED because it ONLY encompasses TWO of THREE remote sites (which maked ALOT of sense).

Just want to be completely clear...

 

[573dawn]

TheProvider...LOL, hate to tell you, but this forum IS my support people! My BP has essentially left me on my own, they have made a few, very few, attempts at solving this (and all the other problems), replaced a couple units, talked to ATT a couple times, installed POTS lines back at the trouble site, but this is my REAL support.

Ask aarenot or kurthansen who I get most of my help from!

Anyway, would that remote management route be for Avaya, or my BP? Because if I catch my BP in one of my units, after all the things they have done wrong, I will have a major fit...

 

[ProviderReborn]

Change your remote Manager passwords then. Oh and erm hate to say this. FIND A NEW BP if this is the case.
We are not all bad.

 

[573dawn]

TheProvider, I would if I could, but I have a boss who has a long-term biz realtionship with them, and we are in a rural area where choices are limited

To the best of my knowledge they haven't ever remoted into it anyway.

 

[mattKnight]

Sorry Dawn,

I wasn't clear...

On any network - the gateway is the local address that packets that match the network address / mask combination are passed to for further routing.

It seems odd to me that you have static routes in your IPO that point to a remote netwrok as gateway. Of course, there may be other things in play...

before you make the chnages try doing the ping (or even a tracert) as I suggested.

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[573dawn]

mattKnight, ok, I think we're agreeing here. The REMOTE sites are set up correctly, but the MAIN site is not. In fact I've done many many ping/tracerts and pings are fine, but tracerts will always give from one to three timeouts before hitting the DS units.

I will change the gateways to the locals and REMOVE the 0.0.0.0 0.0.0.0 192.168.0.200 route on the MAIN site.

Maybe it will help...

and Thanks

 

[mattKnight]

Good luck!

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[573dawn]

mattKnight, Thanks! I appreciate your assistance You take care as well.

Dawn

 

[mattKnight]

Bed time for me now!

let us know how you get on!

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[573dawn]

mattKnight, Where are you? Let me know tomorrow, I will be giving an update

 

[mattKnight]

I am in the UK

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[ProviderReborn]

Has any one independant looked at your configs Dawn?

 

[573dawn]

TheProvider, kurthansen looked at them a while back, there have been many changes since then. In fact, it was kurthansen who solved one of my original problems, the one the BP blamed on my network for over a month. He had it fixed in one day, the BP had meshed the topography, not supported by SCN.

No one else though.

 

[ProviderReborn]

Ah meshed topology. Im suprised that has not messed up all of your configs to be honest

 

[573dawn]

TheProvider, well for that month and a half, it did. You would get "incompatible" showing on the phone when trying to dial a remote location, and it was very random in nature. After removing the mesh, no more incompatibles.

But the incompatibles were masking the larger problem, which is the drops.

Which brought me back to the routes. In the beginning, I supplied the routes, and the BP configured them. BUT, he didn't use his head and configured them exactly the same at all locations, NOT factoring in local gateways. When we started getting all the incompatibles, only MY network was looked at, not the phone system. And MY network wasn't the problem.

Keep in mind that at the time, the BP was excluding me from the configuration. In fact, they stated, in my presence, that they wouldn't trust me to be in it "because I might mess something up" and that they wouldn't let me in for the entire YEAR of the warranty.

SO, they brought in a 3rd party router guy, and HE changed the routes to what is shown at the top of the thread, including adding the 0.0.0.0 0.0.0.0 192.168.0.200, which I questioned since not all traffic flowed through that router. I was still not being granted access and had zero knowledge about the system because they wouldn't teach me anything.

No one bothered to ask me what I might know about routing, especially for the ciscos, this despite my 3 years of network engineering experience with Sprint (data only!).

So one day I got fed up with their arrogant, sactimonious, patronizing attitude. It had been over a month with the incompatibles and I KNEW my network wasn't causing it. By this time I had the passwords ONLY because I was ONLY supposed to change the names on extensions.

I decided to look for a forum on Avaya, and I found this place. kurthansen and several other people had the incompatibles fixed the same day. He also looked over my configs and pointed out some other things that were wrong. Needless to say, my confidence in my BP plummeted.

Since then I have been coming here for advice. And believe me, you guys are far more helpful and no one talks down to me I decided to revisit the routes because we've already done so much to try to fix this, with no appreciable results, I wanted to go over the configs again, especially since we were doing the 4.0.7 upgrade yesterday. It reminded me that I wasn't comfortable with the routing, but still don't know Avaya well enough to be confident in just my own judgement, hence this thread.

My BP is blaming ATT on the drop issues. I don't really agree, and have been looking at my overall connection to that site. But the phones are the only thing having problems, even with traffic shaping et al. One thign I haven't done is swapping routers between locations. If changing the routing has no affect, that is my next step.

 

[ProviderReborn]

What a saga.
I feel for your frustration.

Do you get drops in both types of call? Incoming and out going?

 

[573dawn]

TheProvider, yep, a saga I wish I'd never heard of

Yes, both incoming and outgoing. We actually put in an additional 4 POTS lines for a total of 6 to try and get around it, so that inbound callers were on POTS and not the PRI. I have instructed all other sites to transfer calls for that location by using the analog lines rather than extensions as well, but we have very limited POTS lines at the rest of the sites.

So the calls that aren't on POTS are still being dropped, some callers have been dropped 5-6 times within minutes. Of course, sometimes getting the users to do their part can be tough as well, they are resistant to change.

But this is why I questioned especially the default route, as it only took 2 of 3 sites into consideration. The trouble site is reached from the main site through router 192.168.0.199, and the default route was through 192.168.0.200, excluding the trouble site altogether. I removed it last night and pointed the remianing routes to the proper gateways. This morning I asked my users to report any drops (for what has to be the umpteenth time) and I haven't gotten any reports yet, but phones ahven't been busy today, and they have gotten better at using the POTS lines, so maybe I'll know more by the end of the weekend (this is a weekender kind of place, phones HOP on weekends, far more more than the POTS capacity).