Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does
It may also be related to QoS policy inside the carriers. Some time ago I've seen exactly the same symptoms with Verizon when sip signaling was sent marked as EF. Remarking it down to CS1 or CS3 (don't remember exactly) solved the problem. Michael On Wednesday 09 November 2011 13:47:37 Jay Nakamura wrote: > We ran into a strange situation yesterday that I am still trying to > figure out. We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > SIP traffic coming from SIP provider to the affected customer came > through fine. It's just Us -> SIP server was a problem. > > I thought there may be some strange BGP issue going on but we had > other customers within the same /24 as the affected customers and they > were connecting fine. > > The traffic at the time traversed > > Our network -> Qwest/century link -> Level 3 -> SIP provider > > I changed the routing around so it would go through our other > upstream, AT&T, and it started working. With AT&T, the route was > > Our network -> AT&T -> Level 3 -> SIP provider > > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > >
Re: Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2
On Thursday 18 November 2010 18:18:04 Sam Chesluk wrote: > There are a couple potential issues, that when looked at in whole, add > up to a significant performance impact. > > 1) IPSec + GRE involves two forwarding operations, one to send it to the > tunnel interface , and another to send the now-encapsulated packet out > the WAN interface. This effectively halves the total forwarding rate > before any other considerations. > 2) While the IPSec portion is hardware accelerated, the GRE > encapsulation is not, unless this is a Cat6500/CISCO7600 router, or > 7200VXR with C7200-VSA card. Because of this, the GRE process itself > will consume a fairly large amount of CPU, as this is also a per-packet > process. The impact is similar to a forwarding decision, so that > throughput level is halved again. I would like to question this one. I always thought that GRE header is pre-calculated and kept in the CEF adjacency table, thus GRE encapsulation involves no additional processing overhead compared to regular ethernet encapsulation. The only difference with 6500/7600 is that encapsulation is done by CPU, not PFC. I'm in no way an expert in this, but I'd imagine the whole process to be like this: 1. a sinlge CEF lookup/encapsulation produces a GRE packet 2. packet encryption/ESP encapsulation 3. another CEF lookup/encapsulation to get the encrypted packet out So forwarding rate halved, but just once. Am I wrong? Michael
Re: ipv6 transit over tunneled connection
Hello, Just wanted to say thanks to everybody who replied and/or offered help. I've got a few private peering offers, so I guess I'm ok now. Thanks a lot, Michael On Friday 14 May 2010 11:25:10 pm Michael Ulitskiy wrote: > Guys, > > I've started this thread looking for advice on available options. > There's no doubt in my mind that native connectivity is better than tunnels, > but unfortunately tunnel is the only way to get me started, 'cause my > upstream > does not support ipv6 (hopefully just yet) and I have no budget for > additional > circuits to ipv6-enabled carrier. > So my question still stands: is anyone aware of a reasonable tunneled ipv6 > transit service (I mean aside from HE tunnel broker)? The load will be really > light. I don't expect we'll break a few Mbit/s in the nearest future and when > we do then I guess it'll be the time to look for the native transit. > Thanks, > > Michael > > On Thursday 13 May 2010 18:18:12 Michael Ulitskiy wrote: > > Hello, > > > > We're in the early stage of planning ipv6 deployment - > > learning/labbing/experimenting/etc. We've got to the point when we're also > > planning to request initial ipv6 allocation from ARIN. So I wonder what > > ipv6 transit options I have if my upstreams do not support native ipv6 > > connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there > > anything else? Either free or commercial? Thanks, > > > > Michael > > > >
Re: ipv6 transit over tunneled connection
Guys, I've started this thread looking for advice on available options. There's no doubt in my mind that native connectivity is better than tunnels, but unfortunately tunnel is the only way to get me started, 'cause my upstream does not support ipv6 (hopefully just yet) and I have no budget for additional circuits to ipv6-enabled carrier. So my question still stands: is anyone aware of a reasonable tunneled ipv6 transit service (I mean aside from HE tunnel broker)? The load will be really light. I don't expect we'll break a few Mbit/s in the nearest future and when we do then I guess it'll be the time to look for the native transit. Thanks, Michael On Thursday 13 May 2010 18:18:12 Michael Ulitskiy wrote: > Hello, > > We're in the early stage of planning ipv6 deployment - > learning/labbing/experimenting/etc. We've got to the point when we're also > planning to request initial ipv6 allocation from ARIN. So I wonder what > ipv6 transit options I have if my upstreams do not support native ipv6 > connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there > anything else? Either free or commercial? Thanks, > > Michael >
ipv6 transit over tunneled connection
Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? Thanks, Michael
Re: verizon issue?
Can you be more specific about the problem saw? We're having problems with their oc3 right now, not being able to push over 110m since this morning and still going on. And sure can't get anything useful from verizon. Thanks, Michael On Monday 22 June 2009 10:20:11 am James Kennedy (TT) wrote: > Yes, > > They did some maintenance that I think went bad. > > -Original Message- > From: sip vsp [mailto:sip.vsp.5...@gmail.com] > Sent: Monday, June 22, 2009 9:14 AM > To: nanog@nanog.org > Subject: verizon issue? > > Did anyone have trouble with Verizon over the weekend? > > >
Re: anyone else seeing very long AS paths?
My bgp speaking devices are a couple of 7200s running 12.2(40). Not the newest IOS out there, but it's been doing the job just fine up until yesterday. Yesterday, when that malformed announcement hit my routers they didn't crash, but they did reset bgp sessions (even though I didn't accept the route) and they kept doing so until I got my upstream to filter it out. According to cisco bug toolkit CSCdr54230 should be fixed in 12.2, so obviously it's not enough. Does anybody know what IOS version has fix this problem, 'cause I couldn't find this info at CCO? Thanks, Michael On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > Jared Mauch wrote: > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > >>"They" will keep trying and until a vast majority of ISPs implement > >>maxas, this will keep happening. > > > Or until people who are still running multi-year old cisco code > > actually upgrade? This seems to primarily impact: > > > > 1) Old cisco code > > 2) PC based bgp daemons > > > Both of which likely just need to be upgraded. I actually suspect > > that a lot of people who dropped their bgp sessions did not notice > > something happened, and still will not upgrade their codeI > > suspect these people don't even know they have a bgp speaking device > > anymore. > > On the other hand, the fact that various entities have gone out of their > way to advertise that they're running old hardware/out-of-date software > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > that you update, before someone less pleasant and friendly than myself > finds you. Please. >
Re: anyone else seeing very long AS paths?
It hit my routers at 11:26:40, EST. Michael On Monday 16 February 2009 07:26:23 pm Adam Greene wrote: > Anyone have an estimate as to when these long announcements began? Seems > like the first reports appeared just before noon, UTC-05. > > We noticed a significant dip in Internet traffic to AS11579 for a few > minutes last night (19:00 UTC-05) which we've been trying to hunt down the > cause of. At first glance, the two events seem unrelated. Anyone else see > anything similar?
