On Sep 9, 2011, at 12:12 PM, Mark Tinka wrote:
> I think that DSCP 0 is safest for Internet traffic.
One should certainly always re-mark any Priority 6/Priority 7 data-plane
traffic at one's edges, that's pretty much a given.
-
On Saturday, September 03, 2011 12:02:03 AM
valdis.kletni...@vt.edu wrote:
> Except you can't actually *guarantee* that QoS works
> every packet, every time, during congestion even within
> the same network. Remember - QoS is just a marking to
> shoot the other guy first. If a link ends up
> ove
On Friday, September 02, 2011 10:49:32 PM Jeff Saxe wrote:
> Seriously, I would expect that most public Internet
> carriers, unless you paid them extra fees to pay
> attention to the DSCP markings, would completely ignore
> them and treat it all as best-effort traffic, right up
> to and including
On Friday, September 02, 2011 10:48:17 PM Saku Ytti wrote:
> Seems in this instance someone has deployed QoS and is
> trusting markings from Internet, which is just broken,
> as they cannot anymore guarantee that customer
> video/voice etc works during congestion, so the QoS
> product is broken.
On Friday, September 02, 2011 10:24:23 PM Jesse McGraw
wrote:
>I've recently run into a hard-to-troubleshoot issue
> where, somewhere out in the greater Internet, someone
> was silently dropping packets from my company that
> happened to be marked with DSCP AF21. I'd fully expect
> others to
When you need to pile up this amount of trickery to make something
work, it's probably high time for letting the thing die :-)
Warm regards
Carlos
On Thu, Sep 8, 2011 at 8:33 AM, Mike Jones wrote:
> As HTTP seems to be a major factor causing a lot of short lived
> connections, and several larg
e: QUERY, status: NXDOMAIN, id: 5492
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;git.kernel.org.IN A
;; AUTHORITY SECTION:
kernel.org. 1407IN SOA ns7.kernel.org.
hostmaster.ns7.kernel.org. 20110908 360
Hi NANOG,
Based on recent discussions (of our paper and other topics) on this
list, it seems like research on interdomain routing could really
benefit from a better understanding of current routing policies. But
we researchers need your help here. So, we created a short survey:
http://www.cs.tor
Hello,
I noticed i am not the only NANOG'er in Orange County, CA as I have always
thought :)
if you live in the area and interested in having a beer / lunch / dinner some
time to discuss networks , gear and stuff.
ping me off-list
mehmet
And these 'perceived' routing issues won't be noticed nor are they
important to CDN's?
I know what my job is, but that may not matter to the CDN's. Reading
this thread, I wanted to mention another problem that I feel has an
effect on this issue.
Lyle
On 09/08/11 11:22, Joel jaeggli wrote:
On 09/08/11 17:51, Tony McCrory wrote:
On 8 September 2011 23:44, Atticus wrote:
I can't resolve anything for kernel.org from Verizon's 3G network, or from
HE in California. I'm using HE's nameservers, with Google's as a backup.
Neither of them have any records. Anyone know what's up?
Strange
On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) <
j...@probe-networks.de> wrote:
> Hello,
>
> anyone else getting a route for 212.118.142.0/24 with invalid
> attributes? Seems this is (again) causing problems with some (older)
> routers/software.
>
> Announcement bits (4)
# telnet kernel.org 80
Trying 140.211.169.30...
telnet: Unable to connect to remote host: Connection refused
# telnet kernel.org 21
Trying 140.211.169.30...
^C
# telnet www.kernel.org 80
Trying 140.211.169.30...
telnet: Unable to connect to remote host: Connection refused
# telnet www.kernel.org 21
Hi!
anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.
Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Att
Hello,
anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.
Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized
Looks like its fixed already
$ dig kernel.org @8.8.8.8
; <<>> DiG 9.6.-ESV-R3 <<>> kernel.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13079
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;kern
Here in London on BE*There it was not working, either. But the queries
are coming through now.
$ dig www.kernel.org +short
140.211.169.30
On Thu, Sep 8, 2011 at 11:54 PM, Kyle Duren wrote:
> On Thu, Sep 8, 2011 at 3:44 PM, Atticus wrote:
>
>> I can't resolve anything for kernel.org from Verizo
On Thu, Sep 8, 2011 at 3:44 PM, Atticus wrote:
> I can't resolve anything for kernel.org from Verizon's 3G network, or from
> HE in California. I'm using HE's nameservers, with Google's as a backup.
> Neither of them have any records. Anyone know what's up?
>
> --
> FT3(SU) Byron Grobe, USN
>
Ma
On 8 September 2011 23:44, Atticus wrote:
> I can't resolve anything for kernel.org from Verizon's 3G network, or from
> HE in California. I'm using HE's nameservers, with Google's as a backup.
> Neither of them have any records. Anyone know what's up?
Strange one.
Also fails with my ISP (BE*The
On 8 September 2011 15:44, Atticus wrote:
> I can't resolve anything for kernel.org from Verizon's 3G network, or from
> HE in California. I'm using HE's nameservers, with Google's as a backup.
> Neither of them have any records. Anyone know what's up?
I'm seeing the same issue. One of the aut
I can't resolve anything for kernel.org from Verizon's 3G network, or from
HE in California. I'm using HE's nameservers, with Google's as a backup.
Neither of them have any records. Anyone know what's up?
--
FT3(SU) Byron Grobe, USN
> -Original Message-
> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Wednesday, September 07, 2011 3:16 AM
> To: Leigh Porter
> Cc: North American Network Operators' Group
> Subject: Re: NAT444 or ?
>
> > I'm going to have to deploy NAT444 with dual-stack real soon now.
>
> you may want
> -Original Message-
> From: jean-francois.tremblay...@videotron.com [mailto:Jean-
> francois.tremblay...@videotron.com]
> Sent: Wednesday, September 07, 2011 10:06 AM
> To: d...@cluenet.de
> Cc: nanog@nanog.org
> Subject: Re: NAT444 or ?
>
> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy
> -Original Message-
> From: Simon Perreault [mailto:simon.perrea...@viagenie.ca]
> Sent: Wednesday, September 07, 2011 2:29 PM
> To: nanog@nanog.org
> Subject: Re: NAT444 or ?
>
> David Israel wrote, on 09/07/2011 04:21 PM:
> > In theory, this
> > particular performance problem should onl
> -Original Message-
> From: Leigh Porter [mailto:leigh.por...@ukbroadband.com]
> Sent: Wednesday, September 07, 2011 1:38 PM
> To: David Israel; nanog@nanog.org
> Subject: RE: NAT444 or ?
>
>
>
> > -Original Message-
> > From: David Israel [mailto:da...@otd.com]
> > Sent: 07 Sep
Hi :
If there is anyone who offers colo in Telecity2 in Amsterdam on this
list, can you please contact me off list ?
Thanks
Mike
> -Original Message-
> From: Christian de Larrinaga [mailto:c...@firsthand.net]
> Sent: Thursday, September 08, 2011 8:05 AM
> To: Cameron Byrne
> Cc: NANOG
> Subject: what about the users re: NAT444 or ?
>
> I wonder if the discussion as useful as it is isn't forgetting that the
> edge of
...
> The striking thing I picked up is that NTT considers the CGN equipment
> a big black hole where money goes into. Because it won't solve their
> problem now or in the future and it becomes effectively a piece of
> equipment they need to buy and then scrap "soon" after.
It would get scrapped w
> -Original Message-
> From: Geoff Huston [mailto:g...@apnic.net]
> Sent: Wednesday, September 07, 2011 10:27 PM
> To: Leigh Porter
> Cc: nanog@nanog.org list; Daniel Roesen
> Subject: Re: NAT444 or ?
>
>
> On 08/09/2011, at 2:41 AM, Leigh Porter wrote:
>
> >
> >
> >> -Original Messa
On 9/8/11 08:49 , Lyle Giese wrote:
> Can we really push an IPv6 agenda for CDN's when IPv6 routing at high
> backend levels is still not complete? I certainly don't have the
> 'clout' to push that, but full routing between Cogent and HE needs to be
> fixed.
It's your job to run your network such
> Can we really push an IPv6 agenda for CDN's when IPv6 routing at high
> backend levels is still not complete? I certainly don't have the
> 'clout' to push that, but full routing between Cogent and HE needs to be
> fixed.
if you are worried about full v4 or v6 or v8-juice routing between
coge
Can we really push an IPv6 agenda for CDN's when IPv6 routing at high
backend levels is still not complete? I certainly don't have the
'clout' to push that, but full routing between Cogent and HE needs to be
fixed.
Lyle Giese
LCR Computer Services, Inc.
On 09/08/11 10:04, Christian de Larrin
On Thu, 8 Sep 2011, Dylan Bouterse wrote:
Brighthouse in Orlando was not affected as far as I could tell, but I did hear
of customers in Lakeland that were down. Pretty widespread outage.
Internally at brighthouse, Tampa (southwest florida) and Orlando (central
florida) are pretty heavily de
I wonder if the discussion as useful as it is isn't forgetting that the edge of
Internet has a stake in getting this right too! This is not just an ISP problem
but one where content providers and services that is the users need to get from
here to there in good order.
So
What can users do to
On 9/8/2011 7:52 AM, Chris Boyd wrote:
On Sep 7, 2011, at 8:03 PM, Jimmy Hess wrote:
Probably with all air removed from the environment, and a sound
thermal medium such as oil
pumped in in its place (make sure to use SSDs for all storage and no
mechanical devices).
There are ways to submerge s
On Sep 7, 2011, at 8:03 PM, Jimmy Hess wrote:
> Probably with all air removed from the environment, and a sound
> thermal medium such as oil
> pumped in in its place (make sure to use SSDs for all storage and no
> mechanical devices).
There are ways to submerge spinning disks.
http://www.grcool
Brighthouse in Orlando was not affected as far as I could tell, but I did hear
of customers in Lakeland that were down. Pretty widespread outage.
Dylan
-Original Message-
From: Justin Wilson [mailto:li...@mtin.net]
Sent: Wednesday, September 07, 2011 11:10 PM
To: nanog@nanog.org
Subject
Sadly I see these all the time, and Valve's SRCDS is vulnerable as well
(AFAIK any Q3 engine game is too). There are unofficial patches for source
but I wish Valve and others would fix it for good. Normally I see these
types of attacks in the 1-2Gbps range but we recently have seen them in the
5-8G
On Sep 8, 2011 1:47 AM, "Leigh Porter" wrote:
>
>
>
> > -Original Message-
> > From: Owen DeLong [mailto:o...@delong.com]
> > Sent: 08 September 2011 01:22
> > To: Leigh Porter
> > Cc: Seth Mos; NANOG
> > Subject: Re: NAT444 or ?
> >
> > > Considering that offices, schools etc regularly ha
As HTTP seems to be a major factor causing a lot of short lived
connections, and several large ISPs have demonstrated that large scale
transparent HTTP proxies seem to work just fine, you could also move
the IPv4 port 80 traffic from the CGN to a transparent HTTP proxy. As
well as any benefits from
> -Original Message-
> From: Seth Mos [mailto:seth@dds.nl]
> Sent: 08 September 2011 06:43
> To: NANOG
> Subject: Re: NAT444 or ?
>
>
> Op 8 sep 2011, om 07:26 heeft Geoff Huston het volgende geschreven:
>
> >
> > On 08/09/2011, at 2:41 AM, Leigh Porter wrote:
> >
> > It may not be
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: 08 September 2011 01:22
> To: Leigh Porter
> Cc: Seth Mos; NANOG
> Subject: Re: NAT444 or ?
>
> > Considering that offices, schools etc regularly have far more than 10
> users per IP, I think this limit is a little
42 matches
Mail list logo
