I have a doubt in ISIS.
While redistributing routes from other protocols, how the metric is decided?
OSPF has deccribed this in RFC 2328 Section 16.4 :
'4) Let X be the cost specified by the preferred routing
table
entry for the ASBR/forwarding address, and Y the cost
I have a doubt in ISIS.
While redistributing routes from other protocols, how the metric is decided?
OSPF has deccribed this in RFC 2328 Section 16.4 :
'4) Let X be the cost specified by the preferred routing
table
entry for the ASBR/forwarding address, and Y the cost
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
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 eb...@a2b-internet.com wrote:
Hi Santino,
Did you had a look at AMS-IX ? They have a grx offering for that.
Regards,
Erik Bais
A2B Internet
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 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
Date: Thu, 21 Apr 2011 10:36:54 +0800
From: Adrian Chadd adr...@creative.net.au
Subject: Re: Bandwidth growth
To: Patrick W. Gilmore patr...@ianai.net
Cc: NANOG list nanog@nanog.org
Message-ID: 20110421023654.ge13...@skywalker.creative.net.au
Content-Type: text/plain;
Curran, David david.cur...@windstream.com 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
-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
On Apr 21, 2011 1:59 AM, Remco Bressers re...@signet.nl 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
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
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?
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
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 tunnel, as
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.
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 VPN
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 the
On Thu, Apr 21, 2011 at 12:55 PM, Ben Whorwood bw...@mube.co.uk 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
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:
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
On Thu, Apr 21, 2011 at 1:32 PM, Gary Gladney glad...@stsci.edu 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,
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.
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
Anyone out there have experience with Riverbed Steelhead products?
Do they improve TCP performance over WAN links? is it worth the price?
mike
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
-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 the
-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 product.
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
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
On Thu, Apr 21, 2011 at 3:13 PM, u...@3.am 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
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
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
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
On Thu, Apr 21, 2011 at 1:00 PM, Scott Berkman sc...@sberkman.net 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
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
On Thu, Apr 21, 2011 at 12:49 PM, harbor235 harbor...@gmail.com 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
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 is applied
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
On Thu, Apr 21, 2011 at 3:13 PM, u...@3.am 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
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
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 as
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, but the
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
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
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 to
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
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.
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 the
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
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
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
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
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
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
On Thu, Apr 21, 2011 at 9:24 PM, Bill Blackford bblackf...@gmail.com 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
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
morrowc.li...@gmail.com wrote:
On Thu, Apr 21, 2011 at 9:24 PM, Bill Blackford
On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart jer...@mompl.net 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
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.21
On Thu, Apr 21, 2011 at 9:50 PM, Harry Strongburg harry.na...@harry.lu 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
On Thu, Apr 21, 2011 at 2:49 PM, harbor235 harbor...@gmail.com 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
On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote:
On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart jer...@mompl.net 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
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 jer...@mompl.net wrote:
Bill Stewart wrote:
Rotating shifts between daytime and nighttime is a horrible thing to
do to your
On Thu, Apr 21, 2011 at 10:51 PM, bmann...@vacation.karoshi.com 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 jer...@mompl.net wrote:
Bill Stewart wrote:
Rotating
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
On Thu, Apr 21, 2011 at 09:55:03PM -0400, Christopher Morrow wrote:
how has mtu got anything to do with packet path?
PMTUD?
On Fri, Apr 22, 2011 at 12:33 AM, Harry Strongburg harry.na...@harry.lu 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
66 matches
Mail list logo