> We have also started offering residential Internet to those
> living on campus, which has been very popular (no suprise.)
You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.
In fact, you are better off treating your non-ISP networks
as a customer of your ISP and assigning a
[EMAIL PROTECTED] wrote:
We have also started offering residential Internet to those
living on campus, which has been very popular (no suprise.)
You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.
In fact, you are better off treating your non-ISP networks
as a customer of you
On 2008-11-19, at 09:25, Eugeniu Patrascu wrote:
[EMAIL PROTECTED] wrote:
We have also started offering residential Internet to those living
on campus, which has been very popular (no suprise.)
You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.
In fact, you are better off t
* Michael Sinatra:
> And it just reinforces the fear that people have against putting
> records in DNS for their publicly-accessible resources, especially
> www.
Won't current Windows clients work just fine in this case?
I have no idea what a fix should look like for some of the non-Windows
Joe Abley wrote:
But surely he's not an end-user. He's an ISP, which means he's
(potentially) an LIR.
My gripe was that I wanted to get an IPv6 allocation from RIPE to start
testing how IPv6 would fit in the company that I work for and build a
dual stack network so that when the time comes
On 19 nov 2008, at 9:27, Eugeniu Patrascu wrote:
My gripe was that I wanted to get an IPv6 allocation from RIPE to
start testing how IPv6 would fit in the company that I work for and
build a dual stack network so that when the time comes, just switch
on IPv6 BGP neighbors and update the DNS
> My gripe was that I wanted to get an IPv6 allocation from
> RIPE to start
> testing how IPv6 would fit in the company that I work for and build a
> dual stack network so that when the time comes, just switch
> on IPv6 BGP
> neighbors and update the DNS.
>
> But at almost 10.000 EUR per year
On 14 nov 2008, at 14:55, Fred Baker wrote:
Before we get too deeply exercised, let Margaret and I huddle on it.
The issue you raised can be trivially solved by adding the checksum
offset to a different 16 bits in the address, such as bits 96..127.
Being checksum-equivalent is important so
Hello,
Could someone from Adobe (AS1313) please contact me off list? I'm having
some routing issues getting packets back from your network.
Thanks,
Jeff Calvert
[EMAIL PROTECTED]
[EMAIL PROTECTED]
713-821-1260 opt 2 (NOC)
Hi All,
Nemertes Research released a study on Internet Infrastructure this
morning, this is an update to our 2007 study looking at Internet demand
vs. growth of available bandwidth. This year's update also includes an
examination of routing/addressing trends, IPv6 adoption, and potential of
ot
On 19/11/2008 4:27, "Eugeniu Patrascu" <[EMAIL PROTECTED]> wrote:
[...]
> My gripe was that I wanted to get an IPv6 allocation from RIPE to start
> testing how IPv6 would fit in the company that I work for and build a
> dual stack network so that when the time comes, just switch on IPv6 BGP
> nei
Can someone on the list shed some more light on this? Verizon reports the 9
linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1
unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the
break at 36.4 miles towards Washington. Additional OTDR readings from Laure
On Wed, 19 Nov 2008 14:53:48 EST, Steven Fischer said:
> Can someone on the list shed some more light on this? Verizon reports the 9
> linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1
> unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the
> break at 36.
looks like a single breakBaltimore is about 36.4 miles north of
Washington, and Laurel is about 16.25 miles north of Washington, with
Baltimore being about 20 miles north of Laurel. All this makes sense. The
part that doesn't really make sense is that our headquarters in right
smack-dab along
On 20/11/2008, at 4:06 AM, Florian Weimer wrote:
* Michael Sinatra:
And it just reinforces the fear that people have against putting
records in DNS for their publicly-accessible resources, especially
www.
Won't current Windows clients work just fine in this case?
I have no idea what a
Ah yes, public-but-not-external IPv4 addresses ... I wish a stern note saying
don't do that was feasible ...
/TJ
--Original Message--
From: Nathan Ward
To: nanog list
Subject: Re: IPv6 routing /48s
Sent: Nov 19, 2008 15:02
On 20/11/2008, at 4:06 AM, Florian Weimer wrote:
> * Michael Sin
On Wed, 19 Nov 2008, Steven Fischer wrote:
looks like a single breakBaltimore is about 36.4 miles north of
Washington, and Laurel is about 16.25 miles north of Washington, with
Baltimore being about 20 miles north of Laurel. All this makes sense. The
part that doesn't really make s
On 20/11/2008, at 10:11 AM, [EMAIL PROTECTED] wrote:
Ah yes, public-but-not-external IPv4 addresses ... I wish a stern
note saying don't do that was feasible ...
What people do with their addresses is their business.
The problem here is XPSP2/Vista assuming that non-RFC1918 = unfiltered/
u
Just to agree, I am in Columbia, MD as well, and am unaffected.
J
On Nov 19, 2008, at 3:41 PM, Steven Fischer wrote:
looks like a single breakBaltimore is about 36.4 miles north of
Washington, and Laurel is about 16.25 miles north of Washington, with
Baltimore being about 20 miles north of
Yeah, that's part of why it isn't feasible :)
Also - a more generalized black-hole detection type mechanism (to also catch
PMTUD failures, etc) would be mighty useful ...
/TJ
--Original Message--
From: Nathan Ward
To: nanog list
Subject: Re: IPv6 routing /48s
Sent: Nov 19, 2008 15:34
Technician on site, and excavation has begun. Still no MTTR
On Wed, Nov 19, 2008 at 4:39 PM, Joel Esler <[EMAIL PROTECTED]> wrote:
> Just to agree, I am in Columbia, MD as well, and am unaffected.
>
> J
>
>
> On Nov 19, 2008, at 3:41 PM, Steven Fischer wrote:
>
> looks like a single breakBa
Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 =
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I suppose
- it's supposed to be used on routers.
While I don't doubt that the 6to4 is broken in such circ
Can anyone provide direction (anecdotal or otherwise) on the use of Quagga
in a virtual environment for route servers?
Thanks
On 11/19/08 14:05, Jack Bates wrote:
Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 =
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I
suppose - it's supposed to be used on routers.
While I don't doub
Just for the record, I like my host being the degenerate case of "6to4 site
+ site router all in one".
This makes my life much easier, as I frequently need IPv6 connectivity and
frequently have a public IP(v4) address (EVDO, FTW).
Having said that - what applies to me may well not be the common ca
David Curran wrote:
> Can anyone provide direction (anecdotal or otherwise) on the use of Quagga
> in a virtual environment for route servers?
I run it in a real environment on a virtual machine (as a route
reflector)...
> Thanks
>
Yes, always worth reminding people:
2000::/3 is the currently active "Global Unicast" pool ... and that
doesn't mean native IPv6
(2002::/16 = 6to4, 2001::/32 = Teredo ... ISATAP may be in play, and
not discretely indicated in prefix side of address
... and non-auto
On Wed, Nov 19, 2008 at 5:05 PM, Jack Bates <[EMAIL PROTECTED]> wrote:
> Nathan Ward wrote:
>>
>> The problem here is XPSP2/Vista assuming that non-RFC1918 =
>> unfiltered/unNATed for the purposes of 6to4.
>> Well, deeper problem is that they're using 6to4 on an end host I suppose -
>> it's suppose
Michael Sinatra wrote:
If your reference to 2001:: addressing simply means "non-tunneled,
globally routable IPv6 addressing," then I suppose it is okay. But
please note that there is now a lot of native (non-tunneled), globally
routable IPv6 addressing that is outside of 2001::/16. ARIN, for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 20, 2008, at 02:31 AM, David Curran wrote:
Can anyone provide direction (anecdotal or otherwise) on the use of
Quagga
in a virtual environment for route servers?
We are running it as route collectors in a virtual environment.
Thanks
On 20/11/2008, at 11:05 AM, Jack Bates wrote:
Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 =
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I
suppose - it's supposed to be used on routers.
While I
Christopher Morrow wrote:
6to4 v6 addrs are just regular v6 addrs as far as the network is
concerned. if you put a 6to4 addr on your server you are saying that
you don't have native v6 transport to that host(s) and that you are
reachable via the 6to4 tunnel your host presumably has configured.
Christopher Morrow wrote:
>Jack Bates wrote:
A good example is that traceroutes through my he.net tunnel using 6to4
source addresses do not get replies through he.net's network, presumably due
to their routers not being 6to4 aware and having no route to respond.
can you explain this a little m
On Wed, Nov 19, 2008 at 6:03 PM, Jack Bates <[EMAIL PROTECTED]> wrote:
> Christopher Morrow wrote:
>>
>> 6to4 v6 addrs are just regular v6 addrs as far as the network is
>> concerned. if you put a 6to4 addr on your server you are saying that
>> you don't have native v6 transport to that host(s) and
Mike Leber wrote:
We don't operate any 6to4 gateways.
This I suspected, and actually took as evidence based on the results
from traceroutes.
However, what is likely happening is a random 6to4 gateway operator may
have seen fit to rate limit or filter ICMP.
This may very well be true. I ha
I don't know if a report like this already exists, but I haven't been
able to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a
report that shows the discrepencies in Origin ASN according to the whois
records, and routes in the [global/public] routing table? Publishing it
on some re
On Wed, 19 Nov 2008, Heather Schiller wrote:
> I don't know if a report like this already exists, but I haven't been able
> to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a report that
> shows the discrepencies in Origin ASN according to the whois records, and
> r
Hi
We blocked some prefixes belonging to AS14037 (rackvibe llc) due to
their hosting spammers.
Rackvibe decided to nullroute us back in reply - thats up to them I guess
Only they're dumb enough to inject these blackhole announcements into
the cloud, and various other networks are picking up on t
Hi all.
Grateful if someone from Google and Yahoo can contact me
off-list re: some geo-location issues with their web sites,
our side of the world.
E-mail to the 'noc@' addresses seem to have > /dev/null'ed.
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
Ditto for Google to me please, we are also having geo-location issues
with various google.* domains.
Thanks,
Jasper
On 20/11/2008, at 4:06 PM, Mark Tinka wrote:
Hi all.
Grateful if someone from Google and Yahoo can contact me
off-list re: some geo-location issues with their web sites,
our s
These routes are also being injected by another AS belonging to
Rackvibe - AS19318
This is the guy from rackvibe who said he'd blackhole us because we
blocked him for hosting spammers.
RNOCHandle: GC373-ARIN
RNOCName: Czupryna, Gregg
RNOCPhone: +1-201-605-1425
RNOCEmail: [EMAIL PROTECTED]
RT
If you see 208.36.123.0/24 being announced from any other prefix than
XO (2828 I guess) please ignore it. Especially if you see it
announced from 19318 or 14037.
On Thu, Nov 20, 2008 at 9:38 AM, Suresh Ramasubramanian
<[EMAIL PROTECTED]> wrote:
> These routes are also being injected by another AS
On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote:
If you see 208.36.123.0/24 being announced from any other prefix than
XO (2828 I guess) please ignore it. Especially if you see it
announced from 19318 or 14037.
You're unlikely to get any reasonable response or action here. The
be
Hi
Yes we are on the phone with xo - but meanwhile several other
operators have been picking it up.
As for operational impact - we're Outblaze.com - thats mail.com,
register.com hosted domains etc, email for 40 million users or so.
That makes us, lemme see, quite a bit larger than people like Com
And the guy who is doing this is also an XO downstream as I see.. and
I have a feeling he wont like the consequences of what he did .. but
meanwhile, operationally speaking, my 40 million ++ users would be
glad if these fake announcements could get cut off at the knees
srs
Head, Antispam Operation
We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3
master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone know
anything more about this? Getting any info out of level 3 let alone an ETR has
been challenging.
46 matches
Mail list logo
