SA encryption key

[CulverTech]

Hi All,

I have a Contivity/VPN Router 2700, we have a few IPSec sessions on it for ip phones.  We're experiencing some quality issues, and I suspect the culprit lies between a router managed by a different department and our contivity, so I have to prove that.  So the question is, how do I go about finding the encryption key for each of these SA's on the contivity?  Is there a way to dump the ESP information on the contivity?  I figure if I can match the packets coming out of the ISP's router vs the packets leaving the contivity bound for our PBX, and show this other department the packets went awol within their segment, they can go about fixing that.

Thanks,

Alex

[Telair]

I don't know of any mechanism to show that kind of information, and the Contivity probably shouldn't show that kind of info anyway.  Try setting the encryption type to null for a test phone and then sniff the traffic?  Usually the culprit for poor VoIP quality in my experience has been congested links, overloaded routers, bad QoS implementation on the switches and/or routers ( if any at all ).  I am still surprised by how many networks run VoIP phones without any QoS at all.  If you have large amounts of bandwidth you can get away with it for a while.

[Michael McNamara]

You should be able to look at the tunnel statistics and see if there are missing or dropped packets. Ultimately you can also just monitor (ping) the public IP address of the Nortel VPN Router (formerly Contivity) and see if there are any blatant connectivity issues.

What codec are you using, G.711, G.729? You probably want to use G.711 since it's less noticeable when you loose a few packets. You also want to disable compression on the IPSec tunnel.

Good Luck!

[CulverTech]

Problem is, the Contivity is not the one dropping the packets, I suspect it's one of the other routers, that I have no access to.  It would make sense too, since the problem only started when they changed the path to go through those equipment. 

We're currently using G.729, but the one conversation we had issues with had 34% packet loss.  It's intermittent however, happens once every 4-5 days.  Sometimes it happens when the link sees heavy use, most of the time, the usage is rather low on the links.  It has happened when there's only about 500kbps on the link.

I'll check that compression on the tunnel.  Thanks guys

[Michael McNamara]

Yes, but you can use the tunnel statistics to prove that there are lost/missing packets. The details of the tunnel will show you have many packets transmitted and received. It will also show you if there have been any decryption errors, IP frags, IP filter drops, etc.

I'm assuming this is gong across the Internet? Or is this some type of managed MAN/WAN? Is the tunnel actually dropping and re-establishing?

You should be able to use a simple ping from a management workstation to detect a blatant disconnect between the endpoints.

Good Luck!

[CulverTech]

Thanks,

The problem I see now is actually not with dropped packets.  As it turns out nothing is getting dropped, they just get shuffled around.  When I look at the RTP packets coming out of the Contivity bound for the other endpoint, at first I thought I saw packet loss, but what I'm seeing more often is just that they're out of order.  On the other side of the Contivity of course, they're alll ESP packets.  How would you implement QoS on these?  Mark all ESP packets as EF?

The tunnel had always remained solid.  This is going across the internet.  So the path looks like this

User's phone -> Internet -> ISP Router -> Company routers not under my control -> Contivity -> Media card/internal phones
 

Thanks again,

Alex

[Michael McNamara]

You can try and mark the IPSec packets with and EF DiffServ codepoint but the Internet in general will either strip or not honor them. Is the organization multi-homed to the Internet with multiple (BGP) peering points? This could lead to the path between the user and the VPN router flapping causing packets to potentially take different routes and arrive at different times. You should be able to detect that by running multiple traceroutes to the public IP address (outside of the tunnel) and record the path and see if it changes at any time.

It's probably a mute point but the NVR is design to have it's public Interface connected to the public Internet. You could skip the "Company routers not under my control" and just connect the NVR right behind the ISP router.

Good Luck!

[CulverTech]

Thanks Mike,

Unfortunately I can't touch the path beyond my contivity.  But, we only have one gateway out...for now at least.  Have you ever used the VPN DSCP field on these 1140e phones?  That seems like it could be useful in my case, if it works.

[Michael McNamara]

It's the "public" Internet so in theory the carriers are not going to honor any QoS tags. They'll barely honor any fully managed MAN/WAN connections they have so they definitely aren't going to honor them on the Internet, however, I'm sure they'll have a managed solution to sell you.

Good Luck!

[CulverTech]

Yea, I was hoping the tag will survive to our equipment, I just tried it and it doesn't.  What is that field used for, do you know? 

[Michael McNamara]

That field is used for QoS, specifically DiffServ for Layer 3 and 802.1p (CoS) for Layer 2. However, the Internet is a best-effort network (unlike a corporate or other managed backbone) and most Internet Service Providers will strip the QoS tags from at their network edge. If you were deploying VPN across a managed network backbone such as AT&T or Comcast or Verizon you could potential negotiate with your provider to provide a set QoS across their network.

Cheers!