Packet sniffers for troubleshooting

unknown

What do you guys use when your troubleshooting voice issues? Wireshark, solardwinds, etc?

Find more posts tagged with

Comments

Kelkin

Depends upon the issue.. ive used Wireshark, Solarwinds and OPNet.

shodown

Wireshark
packet capture on gateways.

pitviper

Varies greatly depending on the issue. I use a lot of the built in CUCM tools (DNA, traces, and so on), IOS debug commands on gateways and CME setups, and Wireshark captures.

Legacy User

You know from the what I just noticed I think you 3 and the other guy that has the assassin creed on his avatar. Are really the only hardcore voice guys on the website. Seems like voice is in the minority on here. I hope jobs in voice aren't like that.

shodown

Plenty of voice jobs, but I do see things changing as hosted voip takes larger chunks of enterprise voip. Lowes just moved over 100K people to a hosted Microsoft platform, so I expect other companies to observe and see if it works out for them. Also Voice is much harder than a lot of other fields so people tend to steer clear. Where I work currently the other engineers want no serious involvement with voice.

DexterPark

dmarcisco wrote: »

You know from the what I just noticed I think you 3 and the other guy that has the assassin creed on his avatar. Are really the only hardcore voice guys on the website.

Yeah.....That other guy.

I bet if I had an avatar of Michael C. Hall someone would remember my name is Dexter.

I use Solarwinds Orion to monitor remote sites, and RTMT for CUCM/Unity but my #1 reporting tool is waiting for end users to open P1 tickets with the helpdesk every time they can't access their voice-mail

dmarcisco wrote: »

Seems like voice is in the minority on here. I hope jobs in voice aren't like that.

Voice jobs are actully not hard to find. You are right that voice is the minority (As high paying as it is) I am sure we all get the same calls for Voice opportunities all over the country. If I had a dollar for every voice job opening at StateFarm.........

DexterPark

Also, some handy PRI troubleshooting commands:
Show ISDN Status
debug ISDN q921

I often shut down the voice port, serial0/0:23, and Controller, then bring them back up in reverse order. Oddly enough it seems to work most of the time when the issue is on our end.

shodown

Yeah that state-farm project is huge. I know the delivery manager of it, if anyone is interested shoot me a PM. You do have to relocate to IL. They aren't open to teleworkers at this point, but with as many unfilled positions they have I see either that changing or the salary going up to make it worth someone's while.

Legacy User

Lol i meant no offense by my comment Dexter but i distinctly remember your cool avatar.

DexterPark

shodown wrote: »

Yeah that state-farm project is huge. I know the delivery manager of it, if anyone is interested shoot me a PM. You do have to relocate to IL.

Bloomington, right?

dmarcisco wrote: »

Lol i meant no offense by my comment Dexter but i distinctly remember your cool avatar.

It's all good.

stlsmoore

I did a phone interview for a State Farm Bloomington, IL position as well. Guess I striked out though haha.

nice343

DexterPark wrote: »

Also, some handy PRI troubleshooting commands:
Show ISDN Status
debug ISDN q921

I often shut down the voice port, serial0/0:23, and Controller, then bring them back up in reverse order. Oddly enough it seems to work most of the time when the issue is on our end.

I think you meant

debug isdn q931
Debug dialpeer

should also be a good choice.

shodown

Debug isdn q921 is a real command. When you are troubleshooting the layer 2 portion of a PRI its good to have. I can usually find out if I have a bad VWIC card (which does happen every blue moon)

T1 PRI Troubleshooting - Cisco Systems

pitviper

According to the LECs it’s always your card

I can’t even count the number of loopback tests I’ve run to prove otherwise. I’ve only seen 1 bad VWIC and it was at a site that was hit by lightning w/no UPS.

DexterPark

pitviper wrote: »

According to the LECs it’s always your card I can’t even count the number of loopback tests I’ve run to prove otherwise. I’ve only seen 1 bad VWIC and it was at a site that was hit by lightning w/no UPS.

Yup, same here. I have only seen it be the card one time, and Debugging q921 showed me that the LEC was sending frames but we weren't replying.
**Disclaimer: That was the only time I have ever seen it NOT be on the provider side. 99% of the time it's on them no matter what they say.

shodown

When I worked for a partner this happened every bad storm. I had a customer somewhere who gets caught with there pants down.

sides14

At least 99% of the time it is a provider related issue. It absolutely drives me bonkers when they state otherwise because they hardly want to accept responsibility.

shodown

sides14 wrote: »

At least 99% of the time it is a provider related issue. It absolutely drives me bonkers when they state otherwise because they hardly want to accept responsibility.

When you run into these problems its best to get some sort of email chain going or use there ticekting system and put your debugging in. Once case in point. I had a SIP trunk that we couldn't' reach. The provider said it was our problem, but I had to send them specific debugs and pings showing we couldn't reach there server(pings only would have worked, but this was to make a point) and I showed them pings from my desktop PC which could reach the server. This was a CME device and this was the only external connection it had no firewall or anything. Within min's of that ticket being updated and there account manager being sent the same emails we had a higher level girl on the phone who solved our problem right away. Documentation with providers is key and having a open channel to account managers makes your life much easier when you can prove with debugs and traces its there problem.

Kelkin

There is no doubt about that Shodown.. you have to approach the provider with proving that its their issue and not yours.. Heck alot of time they wont admit its there issue and just state "cleared during test"..

shodown

Kelkin wrote: »

There is no doubt about that Shodown.. you have to approach the provider with proving that its their issue and not yours.. Heck alot of time they wont admit its there issue and just state "cleared during test"..

I always say put yourself in the position of a provider. The guy/gal answering the phone is usually not at the point of being a high level person and sometimes all they do is take tickets. When you finally get someone on the phone it maybe another lower level engineer who has no idea what they are looking at. Is it there fault? I've had a guy who knew nothing about SIP and was going through a knolowdge base trying to figure it out with me on the phone(this was Megapath if you are wondering). Is this good practice? Of course not, but you can't man your phones with CCIE's and have them take tickets all day(you can't even do this with legit CCNP's) and expect them not to become board and go on to what they rather be doing. So a provider has to balance this out with a mix of low and high end engineer's who can solve problems. Your best bet is to work on communication(written and verbal) so when you submit a ticket that when its read it can get as close to the right person as possible. I can't tell you how many "the phones are down" tickets I've gotten when the real problem was that they lost WAN connectivity from there provider managed routers and the low level guy starts where you repot the problem as you haven't given him enough detail onto what symptoms are(in this case the symptoms where the phones would go into SRST failback, loss of email add files stored in the data center). So to sum this up

1. Think about from the provider point of view(low level guy/gal needs as much detail as possible to make correct decision)
2. Your not going to get a expert as soon as you call if you can't explain why. (phones are down doesn't require a expert until you prove otherwise)