On Fri, Apr 22, 2011 at 12:33 AM, Harry Strongburg wrote:
> On Thu, Apr 21, 2011 at 09:55:03PM -0400, Christopher Morrow wrote:
>> how has mtu got anything to do with packet path?
>
> PMTUD?
that won't change the destination based routed path, it'll cause the
endpoints to lower their MTU to a mut
On Thu, Apr 21, 2011 at 09:55:03PM -0400, Christopher Morrow wrote:
> how has mtu got anything to do with packet path?
PMTUD?
There's also Xconnect.
Frank
-Original Message-
From: Scott Berkman [mailto:sc...@sberkman.net]
Sent: Thursday, April 21, 2011 12:01 PM
To: 'Santino Codispoti'; nanog@nanog.org
Subject: RE: Voice Peering?
It's not specific for mobile, but this is one of the most well know VOIP
exchanges
On Thu, Apr 21, 2011 at 10:51 PM, wrote:
> On Fri, Apr 22, 2011 at 02:48:16PM +1200, Mark Foster wrote:
>> On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote:
>> > On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote:
>> >> Bill Stewart wrote:
>> >>>
>> >>> Rotating shifts between daytime and
On Fri, Apr 22, 2011 at 02:48:16PM +1200, Mark Foster wrote:
> On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote:
> > On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote:
> >> Bill Stewart wrote:
> >>>
> >>> Rotating shifts between daytime and nighttime is a horrible thing to
> >>> do to your
On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote:
> On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote:
>> Bill Stewart wrote:
>>>
>>> Rotating shifts between daytime and nighttime is a horrible thing to
>>> do to your workers, both for their health and their attention span.
>>
>> I Fully ag
On Thu, Apr 21, 2011 at 2:49 PM, harbor235 wrote:
> Anyone out there have experience with Riverbed Steelhead products?
> Do they improve TCP performance over WAN links? is it worth the price?
>
>
> mike
>
I've had good experiences with both Riverbed Steelhead and Cisco WAAS
products. Both have a
On Thu, Apr 21, 2011 at 9:50 PM, Harry Strongburg wrote:
> I had a similar issue, but it was mainly only over IPv6. According to
> someone I spoke to at Google, bumping up the MTU might help (and did
> help for me). I don't remember my previous MTU (I think it was 1280),
> but once I bumped it up
On Thu, Apr 21, 2011 at 04:36:50PM -0500, Dan White wrote:
> We're experiencing very poor quality with You Tube, and it appears we're
> subject to a bad entry within a geolocation database somewhere.
>
> When we attempt to view videos, the contact comes back to us from IPs like:
>
> 208.117.226.2
On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote:
> Bill Stewart wrote:
>>
>> Rotating shifts between daytime and nighttime is a horrible thing to
>> do to your workers, both for their health and their attention span.
>
> I Fully agree.
>
> I think it may pay off to search for people who suf
ok, there are some in the spam folder. Hmm, didn't think to look there
for the missing ones when my inbox appears to be receivng partial
threads.
Thanks,
-b
On Thu, Apr 21, 2011 at 6:31 PM, Christopher Morrow
wrote:
> On Thu, Apr 21, 2011 at 9:24 PM, Bill Blackford wrote:
>> I've recently obse
On Thu, Apr 21, 2011 at 9:24 PM, Bill Blackford wrote:
> I've recently observed gmail dropping messages or not forwarding all
> messages/posts from the nanog list. This is rather annoying.
>
> Has anyone else experienced this? Does anyone have any insight as to why?
sometimes nanog mail gets mar
I've recently observed gmail dropping messages or not forwarding all
messages/posts from the nanog list. This is rather annoying.
Has anyone else experienced this? Does anyone have any insight as to why?
Thanks,
-b
--
Bill Blackford
Network Engineer
Logged into reality and abusing my sudo pr
Bill Stewart wrote:
Rotating shifts between daytime and nighttime is a horrible thing to
do to your workers, both for their health and their attention span.
I Fully agree.
I think it may pay off to search for people who suffer "Delayed sleep
phase syndrome" to do night shift. They'll be happy
On 21/04/11 15:46 -0700, Carl Rosevear wrote:
Quova, Maxmind, and others all return accurate results for everything of
ours I have tested. Some of the IPs in question have been properly assigned
or delegated to us for several years in whois. But yeah, thanks for the
input... I actually hadn't
Quova, Maxmind, and others all return accurate results for everything of
ours I have tested. Some of the IPs in question have been properly assigned
or delegated to us for several years in whois. But yeah, thanks for the
input... I actually hadn't checked Quova until now. Perhaps Google rolls
t
I don't know what Google uses but any company using F5 equipment is using Quova
geolocation services. You can request updates and check your circuit here:
http://www.quova.com/what/request-ip-update/
The problem is that the F5 devices don't update the database files
automatically, they need to
I have had this same problem, followed Google's forms, etc... they never
seem to fix it. Its really annoying.
This is an epic fail on the part of Google in my opinion. My netblocks all
show Seattle in whois... my routing is obviously here... I don't think we
have an official address in the UK
On Apr 21, 2011, at 5:28 46PM, Terry Baranski wrote:
> On Apr 21, 2011, at 4:20PM, Steven Bellovin wrote:
>
>> For your application or for the VPN? For the VPN, I *strongly*
>> suggest you use UDP, or you're going to get dueling retransmissions
>> and spend a lot of time sending many copies of
On Thu, 21 Apr 2011 17:55:32 +0100, Ben Whorwood wrote:
IMHO it is not good idea to go to OpenVPN/IPSec/etc level at all (IP
layer at least, and in case of Windows it is also ethernet headers).
First of all OpenVPN for Windows/different OS sometimes become a
headache and need admin privileges.
We're experiencing very poor quality with You Tube, and it appears we're
subject to a bad entry within a geolocation database somewhere.
When we attempt to view videos, the contact comes back to us from IPs like:
208.117.226.21 (traceroute's through Frankfurt)
173.194.50.47
74.125.100.29
All of
On Apr 21, 2011, at 4:20PM, Steven Bellovin wrote:
> For your application or for the VPN? For the VPN, I *strongly*
> suggest you use UDP, or you're going to get dueling retransmissions
> and spend a lot of time sending many copies of the same thing. Consider:
> if a packet is dropped, either due
What would be nice is a voice peering that actually act's as a traditional
tandem.
Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com /
http://www.race.com
On 4/21/11 1:38
Among other services, the VPF provides an ENUM infrastructure for doing
lookups using DNS for what carrier in the exchange can route calls to a
specific TN. But yes, the underlying concept of the actual interconnections
are similar to IP exchanges.
There are also application specific exchanges ou
On Apr 21, 2011, at 4:31 32PM, Phil Regnauld wrote:
> Steven Bellovin (smb) writes:
>>
>> I should note: IPsec, being datagram-based, will also work well. PPTP,
>> which runs over TCP as far as I know, will suffer all of the ills I just
>> outlined.
>
> PPTP uses 1723/tcp for control, bu
Steven Bellovin (smb) writes:
>
> I should note: IPsec, being datagram-based, will also work well. PPTP,
> which runs over TCP as far as I know, will suffer all of the ills I just
> outlined.
PPTP uses 1723/tcp for control, but the tunneled traffic is GRE,
so that would work fine
On Apr 21, 2011, at 12:55 32PM, Ben Whorwood wrote:
> Dear all,
>
> Can anyone share any thoughts or experiences for VPN links running over slow
> Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)?
>
> We are looking into utilising OpenVPN for out-of-office workers who would be
On Thu, Apr 21, 2011 at 3:13 PM, wrote:
> Ok, I've done a lot of Cisco standard and extended ACLs, but I do not
> understand why the following does not work the way I think it should.
> Near the end of this extended named ACL, I have the following:
>
> permit tcp any eq 443 any
> permit tcp any
On Apr 21, 2011, at 12:11 PM, Jeroen van Aart wrote:
> valdis.kletni...@vt.edu wrote:
>> Well, 33.6k is a Bad Idea right there. :) But if you're stuck with that
>> for technical reasons, but need a VPN for security reasons, it won't
>> be all *that* much worse, unless you're doing a lot of SSH or
Thanks everyone, of course this is what I wanted. Like I said, a stupid
ACL question...I'm blaming heavy medication, sorry for the noise!
> On Thu, 21 Apr 2011, u...@3.am wrote:
>> permit tcp any eq 443 any
>> permit tcp any eq 80 any
>> deny ip any host 2.2.3.4
>> permit ip any any
>>
>> This
On Thu, Apr 21, 2011 at 12:49 PM, harbor235 wrote:
> Anyone out there have experience with Riverbed Steelhead products?
> Do they improve TCP performance over WAN links? is it worth the price?
>
I'll let others answer the specific question about Riverbed. I've heard
plenty of good things about
If this is applied inbound from the Internet, then the first two permits are
permitting reply traffic from the far-end Web server's ports 80 or 443 back
toward your surfing workstations or servers. You should think of those as
permit
- just TCP
-- where the SOURCE is any IP address, but source P
On Thu, Apr 21, 2011 at 1:00 PM, Scott Berkman wrote:
> It's not specific for mobile, but this is one of the most well know VOIP
> exchanges:
And here I thought IP exchanges would cover the IP in VOIP.
When do we get HTTP exchanges? :)
Regards,
Martin
On Thu, 21 Apr 2011, u...@3.am wrote:
permit tcp any eq 443 any
permit tcp any eq 80 any
deny ip any host 2.2.3.4
permit ip any any
This is applied to an inbound interface(s). We want anybody outside to be
able to reach ports 80 and 443 of any host on our network, no matter what,
then block ALL
On 21/04/11 11:53 AM, Brandon Kim wrote:
Nothing like getting into the groove, then losing your connection, waiting for
the modem to dial back up
and then try to figure out what you were just doing!!! Again, it goes back to what I
mentioned, it "could" work
but how will that affect your overa
I've had good experiences with the Riverbed appliances as well. Definitely a
leader in my mind when compared to Cisco and Juniper although there are some
new niche players that have good solutions depending on the details of your
traffic and topology.
One note on the Riverbeds, if you're trying
On Thu, Apr 21, 2011 at 3:13 PM, wrote:
> Ok, I've done a lot of Cisco standard and extended ACLs, but I do not
> understand why the following does not work the way I think it should.
> Near the end of this extended named ACL, I have the following:
>
> permit tcp any eq 443 any
>
Don't you want
Ok, I've done a lot of Cisco standard and extended ACLs, but I do not
understand why the following does not work the way I think it should.
Near the end of this extended named ACL, I have the following:
permit tcp any eq 443 any
permit tcp any eq 80 any
deny ip any host 2.2.3.4
permit ip any
valdis.kletni...@vt.edu wrote:
Well, 33.6k is a Bad Idea right there. :) But if you're stuck with that
for technical reasons, but need a VPN for security reasons, it won't
be all *that* much worse, unless you're doing a lot of SSH or similar
I would think so too. When I first moved to the Stat
> -Original Message-
> From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net]
> Sent: Thursday, April 21, 2011 2:58 PM
> To: 'harbor235'; 'NANOG list'
> Subject: RE: riverbed steelhead
>
> I've had generally good experiences w/ Riverbed's Steelhead as well as
> Juniper's WX Series prod
> -Original Message-
> From: harbor235 [mailto:harbor...@gmail.com]
> Sent: Thursday, April 21, 2011 2:50 PM
> To: NANOG list
> Subject: riverbed steelhead
>
> Anyone out there have experience with Riverbed Steelhead products?
> Do they improve TCP performance over WAN links? is it worth t
Nothing like getting into the groove, then losing your connection, waiting for
the modem to dial back up
and then try to figure out what you were just doing!!! Again, it goes back to
what I mentioned, it "could" work
but how will that affect your overall productivity.
Is over the air 3G or 4G
Anyone out there have experience with Riverbed Steelhead products?
Do they improve TCP performance over WAN links? is it worth the price?
mike
On Apr 21, 2011, at 12:55 PM, Ben Whorwood wrote:
> Dear all,
>
> Can anyone share any thoughts or experiences for VPN links running over slow
> Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)?
>
> We are looking into utilising OpenVPN for out-of-office workers who would be
>
On 04/21/2011 01:32 PM, Brandon Kim wrote:
I vote for Patrick's idea of allowing the end user to remote into a machine
where the SQL resides.
This would eliminate a lot of potential issueswish I had thought of that
first!!!
I third this idea. Using screen would be a good idea as well.
Th
On Thu, Apr 21, 2011 at 1:32 PM, Gary Gladney wrote:
> If you haven't deployed your VPN environment yet I would seriously
>consider using SSL VPN instead of IPSec as your tunneling protocol.
> SSL VPN gives you a lot more options than IPSec.
Hi Gary,
Ben was looking at OpenVPN, not IPSec.. He s
If you haven't deployed your VPN environment yet I would seriously consider
using SSL VPN instead of IPSec as your tunneling protocol. SSL VPN gives you a
lot more options than IPSec.
Gary
-Original Message-
From: Ben Whorwood [mailto:bw...@mube.co.uk]
Sent: Thursday, April 21, 2011
I vote for Patrick's idea of allowing the end user to remote into a machine
where the SQL resides.
This would eliminate a lot of potential issueswish I had thought of that
first!!!
> Subject: RE: VPN over slow Internet connections
> Date: Thu, 21 Apr 2011 13:10:09 -0400
> From: dar...@a
On Thu, Apr 21, 2011 at 12:55 PM, Ben Whorwood wrote:
> Can anyone share any thoughts or experiences for VPN links running over slow
> Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)?
>
> We are looking into utilising OpenVPN for out-of-office workers who would be
> running mobil
> We are looking into utilising OpenVPN for out-of-office workers who
> would be running mobile broadband in rural areas. Typical data across
> the wire would be SQL queries for custom applications and not much else.
>
I agree with Patrick, SSH would do nicely. You could even setup a
tunnel, and
On Thu, 21 Apr 2011 17:55:32 BST, Ben Whorwood said:
>* How well would the connection handle certificate (>= 2048 bit key)
> based authentication?
It will hiccup for a moment (maybe a quarter or half second) for the data. The
certificate exchange is the least of your problems.
>* Is VP
There's not that much overhead--your certs should be ok. TCP for SQL would
just make sense. I personally wouldn't want to do what you are contemplating.
Here's some stuff to think about:
1. your modems will not be able to do compression. You can't easily compress
random data (e.g. encrypt
Ben Whorwood (bw-ml) writes:
> Some initial thoughts include...
>
> * How well would the connection handle certificate (>= 2048 bit
> key) based authentication?
> * Is UDP or TCP better considering the speed and possibility of
> packet loss (no figures to hand)?
I'd go for a UDP tunne
If I had to guestimate, the performance would be horrible considering the VPN
overhead in itself.
You can't choose UDP or TCP, that is all based on the applications being used
within the tunnel.
So the apps will decide what protocols they will need to use, which will then
be encapsulated by IP
It's not specific for mobile, but this is one of the most well know VOIP
exchanges:
http://www.thevpf.com/
-Scott
-Original Message-
From: Santino Codispoti [mailto:santino.codisp...@gmail.com]
Sent: Thursday, April 21, 2011 3:36 AM
To: nanog@nanog.org
Subject: Voice Peering?
I
Dear all,
Can anyone share any thoughts or experiences for VPN links running over
slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)?
We are looking into utilising OpenVPN for out-of-office workers who
would be running mobile broadband in rural areas. Typical data across
On Apr 21, 2011 1:59 AM, "Remco Bressers" wrote:
>
> I also thought GRX peering was only data and sms.
> There's a SIP peering point on the NL-IX though.
Grx is data only. IPX in theory does voice too but I don't think the take
rate is very high.
Cb
> Look at http://www.nl-ix.net/solutions/voic
-Original Message-
From: Curran, David [mailto:david.cur...@windstream.com]
> The LINX, TORIX, and SIX graphs provided earlier, for example, seem
> relatively flat until the Nov. timeframe at which point they seem to
seek
> a new higher "normal". Could just be my lack of sleep and my b
"Curran, David" wrote on 04/21/2011 08:52:29
AM:
> ... it also strikes me that on the aggregate
> the graphs do indeed show a significant increase around the "holidays"
> (the US ones anyway).
Another bias? :-)
Seems Internet participants took some time off for Christmas:
http
> Date: Thu, 21 Apr 2011 10:36:54 +0800
> From: Adrian Chadd
> Subject: Re: Bandwidth growth
> To: "Patrick W. Gilmore"
> Cc: NANOG list
> Message-ID: <20110421023654.ge13...@skywalker.creative.net.au>
> Content-Type: text/plain; charset=us-ascii
>
> If it's a true research project, wo
> Thank you for the response. Its very detailed, and I am yet to understand
> it completely.
>
> Following is the problem I am facing on Ericsson Routers.
>
> (static route)
> Router1-Router2
>
I also thought GRX peering was only data and sms.
There's a SIP peering point on the NL-IX though.
Look at http://www.nl-ix.net/solutions/voice-peering/ for more.
Regards,
Remco Bressers
Signet B.V.
AS28878
On 04/21/2011 10:52 AM, Santino Codispoti wrote:
> Thank you I will look into AMS-IX.
Thank you I will look into AMS-IX. I was thinking the GRX platforms
where for SMS and Data only.
On Thu, Apr 21, 2011 at 4:45 AM, Erik Bais wrote:
> Hi Santino,
>
> Did you had a look at AMS-IX ? They have a grx offering for that.
>
> Regards,
> Erik Bais
> A2B Internet
>
> Verstuurd vanaf mijn
I know a few years ago some Vo/IP peering points where started. Are
they still around today? I am looking for a solution to hand-off
outbound voice calls to mobile operators
64 matches
Mail list logo
