Network Assessment assistance please!

[bigblock454]

Hi All, azjeepgirl sent me an Avaya tech tip on using packet capture software to run my own NA, in an attempt to isolate the drop call issue (sorry if you're not familiar with this problem of the former 573dawn's, most here are). I have set up a PC with wireshark at my main location. I port mirrored the DS port to the PC, and I can merrily see all the packets flying by. However, since drops from the main location are almost unheard of, and primarily occur between the HWY & 21MM locations on a transfer, should I be mirroring the port that the HWY connects to rather than the port that the Main Site DS connects to?

Thanks! Dawn

 

[Duffman88]

Hi Dawn,

It wouldnt be a bad idea to have a sniffer at each location. Even though this is a bit of a pain it will allow you to see the packet being sent at one location then received at the other. Then the reply packet being sent and received at the main location.

So if you now see a packet leave the main site and it never makes it to the remote site with the two sniffers you will know that packet was lost either in the transit or it could be a switch issue at the remote location yada yada yada. You can start to isolate it down. If you have just the one sniffer all you will know is that you sent a packet from the main site and never received a response. The packet may have left the main site been received by the remote site and its just the response that never made it back. You wouldnt be able to tell the difference with out the second sniffer.

to be honest Network Sniffing is not fun especially if you are new to it. It might not be a bad idea to contract someone to find your network problem.

Just for my info, are you running ip phones or is it a SCN that your troubleshooting? Also are you running a converged network (phones and PC on the same network) Sorry I dont know the story

-Chris
ACA

 

[bigblock454]

Duffman88, hi and thanks for the reply. We are running digital handsets (5410/5420) on an SCN. The entire company is on the same network, but the phones themselves aren't IP. I started the network sniffing because the BP just can't seem to be convinced to do it. He too has suggested a 3rd party, and that would be just fine, as long as it's Avaya. I am very, very tired of the run around we have gotten from the BP over the last year, so I decided that I should just attempt it myself. As a business dealing in a high-end luxury item, and given the current economy, we are in rather a belt-tightening mode, so I'm not sure how much we might be willing to spend I will set up a sniff at the other end though, that I can do!

 

[Duffman88]

There are a lot of variables with a mixed network. It could be something as simple as a bad jetdirect card in a printer or it could just be you have no QOS set up and the data traffic is overwhelming the voice traffic.

How do you have the two locations connected? P2P T1, VPN Tunnel, Frame relay. Also what network hardware do you have on both sites. Switches, routers, firewalls etc.

This is going to be a tough one over a forum haha.

-Chris
ACA

 

[bigblock454]

Duffman88, LOL, you must be new <g>. This forum has been assisting me with the IPO, and this problem in particular, for nearly a year now. I have 4 locations connected by full PTP T1s, 2 B8ZS and 1 AMI that I am having changed as we speak, just sent the new contract. We are connected with 1721 Ciscos and Avaya P133GT2 managed switches. QoS is enabled on all devices, with 50% of the bandwidth dedicated to the IPO, not like we max it out though, we are ususally running at around 10% capacity and I have yet to see congestion, jitter, high drop rates, etc. We have been over the network with a finetooth comb, and found nothing. That is why I am trying to do the NA myself, because it was never done by the BP (despite the requirement) and before the IPO was installed, I had exactly zero experience with voice systems. I have had no training on it, and if not for this forum, it would have been a bigger nightmare than it has been. Just as an example, we had a problem in the beginning that was very vexing. Without going into it, the BP spent 2 months telling us it was a problem with our network. That is when I found this forum, who immediately pinpointed the problem as a meshed network configuration in the IPO and had it fixed in one day, if that tells you anything about my BP...

 

[Bas1234]

If you can get NetIQ, it works very good to trouble shoot a VOIP network.

http://www.netiq.com/solutions/platforms/voip/default.asp

greetzzz..Bas

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________

 

[bigblock454]

bas1234, thanks, I'll check it out! I wanted to use the nice one from Orion and Solar Winds, but I don't have a server that'll run it (I'm working on correcting that though)

 

[Duffman88]

How often do you drop calls? Have you noticed a pattern? Maybe a high call volume or data volume time? How are your IP Trunks configured for the IPOs?

Also the way the SCN is configured is one main site and 3 branches off of it?

With a single T1 running PPP between two sites with half bandwidth QOS at G711 you will get around 9 calls reliable (runs about 81kbps per call w/ overhead). I'm sure you know all of this. Also keep in mind if a remote site has to go through the main site and then back out to another site it sucks up bandwidth on both.

Just trying to cover my bases to understand your config and problem.



-Chris
ACA

 

[bigblock454]

Duffman88, in fact we have a very specific pattern. If the caller calls the spoke named Hwy, and that call is transferred to either of the other 2 spokes, it will drop pretty much 100% of the time. However, if they transfer the call to the hub site, the call will stay connected, even if the hub then sends the call to another spoke. This is the workaround we are currently using. There is no time of day or high volume, data or voice, factor apparent. Just an FYI, we are a marina in Missouri, and in winter there is very little volume for either voice or data, but the pattern remains the same. It is always the same error as well, if you'd like to see it I'll post it for you. I am hoping that we get the AMI circuit moved over to B8ZS next week, and we will test again.

 

[Duffman88]

Sure post the error. Also post your IP Line configurations. I wonder if Allow Direct Media Path may have an affect on SCN Transfers in your situation.

What if the caller calls one of the other spokes and the calls transfers to the other spoke (not HWY) do you still have that call drop problem? And I assume that HWY has the AMI line?

-Chris
ACA

 

[Duffman88]

I just read some stuff on the SCN and Direct Media Path. Post your IP Line config for each site. Just settings im not worried about the numbering or anything. Make sure you include if Allow Direct Media Path is enabled on each site.

You dont have the sites firewalled at all do you? The Point-To-Point connections i mean.

-Chris
ACA

 

[kwing112000]

We have been trying to help her for a while. she had posted in another thread the DMP was off on all sites. With the point to point T1's and routers she has the remote sites dont have the ability to communicate directly.

Dawn,
Have you ever tried to run on G729? from what i have been told G711 is more for the LAN and not the WAN. We run a lot of sites on G729 and they have not had much issue. It may be worth a shot. even on the just the AMI site. I think i read somewhere about D4/AMI and packet size or something like that.

Kevin Wing
ACA- Implement IP Office
Carousel Industries

 

[Duffman88]

I'm running G711 at one of my customers over SCN. Runs fine but you just cant have as many call paths as G729. I have dedicated T1's. Originally one and now I have 2 running MLPPP. Full Bandwidth QOS.

The AMI might be a problem in the picture. From my understanding AMI doesnt like to run data. If the data has too many zero's it will cause problems and the T1 will start pulling errors. Also AMI runs robbed-bit so instead of 64K channels w/ B8ZS & ESF you get 56K with AMI & SF.

Also from my understanding SCN the way she has it configured without DMP will run from the spoke site to the hub to the spoke. w/ DMP it will go from spoke to spoke using just the Data network and not the hub H323 Gateway. I might be wrong but that was my understanding. At least when IP phones arent in the picture. Then its a new ballgame.

Best bet is to get that T1 running B8ZS and get the sniffer running between the hub and the two spokes in question and find the dropped RTP packet.


-Chris
ACA

 

[kwing112000]

Duffman88
you are correct about the direct media path. If it is enabled and your network can support it it will only use the Hub for call set up and then the 2 spokes will talk direct. but in a lot of Point to point T1 networks it wont work at all.

Kevin Wing
ACA- Implement IP Office
Carousel Industries

 

[Duffman88]

Good to know. Thanks for the heads up.

-Chris
ACA

 

[bigblock454]

Hi guys, just got back from the weekend. Ok, let me see if I can sort this one out. We don't run direct media path, we took that off last year trying to solve the many problems we had, now that we are down to the single problem (holding my breath saying that), do you think I should re-enable it and do some test calls?

I am unsure how to post only the IP line configs, but I can tell you they are numbered uniquely and that all the channel numbers match (they didn't as recently as a couple weeks ago, azjeepgirl has been assisting me too). I also lowered the channel amounts as they were in excess of the actual available VCMs. We are running G711, H450 is on, and out of band DTMF, voice networking, and fax transport are the only checked items. I verified this for all IP lines. All spokes have the hub address as the gateway, and the hub has the individual addresses for each spoke DS listed as the gateway for each line.

I did a few test calls, it appears that if the call comes into any other spoke but HWY, that it is a stable call, even if transferred to HWY and then back to another spoke. However, if the call is transferred from HWY, it drops 100% of the time, as expected. And yes, HWY is the AMI line (come on ATT, get me that line conversion!) At this point, I am going to wait for the conversion and see what happens, hopefully it will be sometime this week.

 

[kwing112000]

Dawn,
I would say there is only one thing i would change and that is the direct media path. In the network you have where two remotes can not talk directly to each other it is not needed. Other than that i would wait on the new T1 from ATT. the other thing you could try is set the site that is having the drops to G729. maybe it is a packet size issue or MTU on the AMI line.

Kevin Wing
ACA- Implement IP Office
Carousel Industries

 

[Duffman88]

Dawn don't forget that even though you might have enough VCMs for the channel amount you have chosen but if you are running a single T1 and only giving voice half bandwidth qos you will only be guaranteed 8 or 9 calls on G711. Any more than that is a gamble.

Other than that I agree with Kevin, leave DMP off, wait for that B8ZS line and in the meantime you can always drop the HWY connection to G729.

Let us know when they convert that T1.

Chris
ACA- Implement IP Office

 

[NewNic]

Ok, I probably way off base here. Dawn, I know of an issue in a 3 site enviroment that would have intermittant one-way speach path. (could be interpted as dropped calls)

The final resolution was that CDR was turned on at the main location with the MAX CDRs set at 500 (default) This was chewing up memory for use by other resources. Changed the MAX CDRs down to 100 and that resoved our issue.

Let me know will ya

 

[bigblock454]

I will most definitely post once that B8ZS conversion has taken place. I should know pretty much immediately if that resolved the issue, because I have a 100% failure rate as it is now. Come on ATT, get me that line!!!