Re: [NANOG] Unique v6 (video) content

[Stanislav Sedov]

On Tue, 20 May 2008 14:52:24 +0300
Max Tulyev <[EMAIL PROTECTED]> mentioned:

> Hello Michael,
> 
> I'm getting the permanent error message:
> 

Works fine here. You should try different URL. The page you're
requesting contains an actual URL to the video,
http://cdn4.nacevi.cz//CT24-PAL in IPv6 case.

-- 
Stanislav Sedov
ST4096-RIPE

Re: [NANOG] Unique v6 (video) content

[Michal Krsek]

Hello Michael,

I'm getting the permanent error message:



Works fine here. You should try different URL. The page you're
requesting contains an actual URL to the video,
http://cdn4.nacevi.cz//CT24-PAL in IPv6 case.

  


Server name is generated dynamically - depends on your IP/IPv6 address.

Not a rocket science behind :-)

Regards
   Michal

Re: [NANOG] Unique v6 (video) content

[Sargun Dhillon]

I wonder when IPv6porn.com is coming online. We're all waiting on Kevin
Day @ Your.org. The latest mailing list updated was positive [This
morning 5 AM PST8PDT].  Seems DNS has dissapeared for it though. It
should give a decent boost to IPv6 traffic. We're all going to have a
fun time dealing with this once Your.org breaks out  IPv6. :-)

Michal Krsek wrote:
>
>>> Hello Michael,
>>>
>>> I'm getting the permanent error message:
>>> 
>>
>> Works fine here. You should try different URL. The page you're
>> requesting contains an actual URL to the video,
>> http://cdn4.nacevi.cz//CT24-PAL in IPv6 case.
>>
>>   
>
> Server name is generated dynamically - depends on your IP/IPv6 address.
>
> Not a rocket science behind :-)
>
> Regards
>Michal
>
>


-- 
+1.925.202.9485
Sargun Dhillon
deCarta
[EMAIL PROTECTED]
www.decarta.com

Re: [NANOG] Unique v6 (video) content

[Kevin Day]

On May 21, 2008, at 10:56 AM, Sargun Dhillon wrote:

I wonder when IPv6porn.com is coming online. We're all waiting on  
Kevin

Day @ Your.org.


It honestly is coming soon! :) As I mentioned on the mailing list ( http://mail.your.org/pipermail/v6test/2008-May/65.html 
 ), there are some copyright clearance issues causing a bit of a  
delay. Once that's resolved, we'll do a bit of testing with those  
willing to help, then launch.



The latest mailing list updated was positive [This
morning 5 AM PST8PDT].  Seems DNS has dissapeared for it though.


In preparation for launch, all the "real" domains are being moved to  
their correct IPs. Info about the project itself is still available at http://www.ipv6experiment.com 
.



 It should give a decent boost to IPv6 traffic.


If you want advance warning of a decent amount (many gbps) of v6  
traffic being dumped on the world, sign up for the mailing list for  
the countdown. We've got some major mainstream media exposure going to  
happen after we're live that should bring a lot of public attention to  
v6.



We're all going to have a
fun time dealing with this once Your.org breaks out  IPv6. :-)




-- Kevin

Cisco Security Advisory: Cisco IOS Secure Shell Denial of Service

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Cisco IOS Secure Shell Denial of Service
Vulnerabilities

Advisory ID: cisco-sa-20080521-ssh

http://www.cisco.com/warp/public/707/cisco-sa-20080521-ssh.shtml

Revision 1.0

For Public Release 2008 May 21 1600 UTC (GMT)

+

Summary
===

The Secure Shell server (SSH) implementation in Cisco IOS contains
multiple vulnerabilities that allow unauthenticated users the ability
to generate a spurious memory access error or, in certain cases,
reload the device.

The IOS SSH server is an optional service that is disabled by
default, but its use is highly recommended as a security best
practice for management of Cisco IOS devices. SSH can be configured
as part of the AutoSecure feature in the initial configuration of IOS
devices, AutoSecure run after initial configuration, or manually.
Devices that are not configured to accept SSH connections are not
affected by these vulnerabilities.

Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-1159
has been assigned to this vulnerability.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20080521-ssh.shtm

Affected Products
=

Vulnerable Products
+--

Cisco devices running certain 12.4-based IOS releases and configured
to be managed via SSH may be affected by this issue.

The IOS secure shell server is disabled by default. To determine if
SSH is enabled, use the show ip ssh command.

Router#show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3

The previous output shows that SSH is enabled on this device and that
the SSH protocol major version that is being supported is 2.0. If the
text "SSH Disabled" is displayed, the device is not vulnerable.
Possible values for the SSH protocol version reported by IOS are:

  * 1.5: only SSH protocol version 1 is enabled
  * 1.99: SSH protocol version 2 with SSH protocol version 1
compatibility enabled
  * 2.0: only SSH protocol version 2 is enabled

For more information about SSH versions in IOS, please check the
following URL: 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_ssh2.html

The SSH server is not available in all IOS images. Devices that do
not support SSH are not vulnerable. Please consult the table of fixed
software in the Software Version and Fixes section for the specific
12.4-based IOS releases that are affected.

To determine the software running on a Cisco product, log in to the
device and issue the show version command to display the system
banner. Cisco IOS software will identify itself as "Internetwork
Operating System Software" or simply "IOS". The image name will be
displayed between parentheses on the next line of output followed by
"Version" and the IOS release name. Other Cisco devices will not have
the show version command or will give different output.

The following example identifies a Cisco product running IOS release
12.4(17):

Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 
12.4(17),
RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Fri 07-Sep-07 16:05 by prod_rel_team

ROM: System Bootstrap, Version 12.2(8r) [cmong 8r], RELEASE SOFTWARE (fc1)

Router uptime is 1 week, 5 hours, 5 minutes
System returned to ROM by power-on
System image file is "flash:c2600-adventerprisek9-mz.124-17.bin"

Additional information about Cisco IOS release naming is available at
http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+

Cisco devices that do not run IOS are not affected.

Cisco IOS devices that do not have the SSH server feature enabled are
not affected.

IOS-XR images are not affected.

The following IOS release trains are not affected:

  * 10-based releases
  * 11-based releases
  * 12.0-based releases
  * 12.1-based releases
  * 12.2-based releases
  * 12.3-based releases

IOS releases prior to 12.4(7), 12.4(13d)JA, and 12.4(9)T are not
affected by this vulnerability.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
===

Secure shell (SSH) was developed as a secure replacement for the
telnet, ftp, rlogin, rsh, and rcp protocols, which allow for the
remote access of devices. The main difference between SSH and older
protocols is that SSH provides strong authentication, guarantees
confidentiality, and uses encrypted transactions.

The server side of the SSH implementation in Cisco IOS contains
multiple vulnerabilities that allow an unauthenticated user to
generate a spurious memory access or, in certain cases, reload the
device. If the attacker is able to reload the device, these
vulnerabilities could be repeatedly exp

Re: [NANOG] Multihoming for small frys?

[Heather Schiller]

William Herrin wrote:

Hi folks,

An administrative question about multihoming:

I have a client who needs to multihome with multiple vendors for
reliability purposes, currently in the Northern Virginia area and
later on with a fail-over site, probably in Hawaii. They have only a
very modest need for bandwidth and addresses (think: T1's and a few
dozen servers) but they have to have BGP multihoming and can afford to
pay for it.

The last I heard, the way to make this happen was: Find a service
provider with IP blocks available in ARIN's set of /8's that permit
/24 announcements (networks 199, 204-207), buy a circuit and request a
/24 for multihoming. Then buy circuits from other providers using that
ISP's /24 and an AS# from ARIN.


Yes, but the order is wrong..

- Order service from 2 providers
- Request an ASN from ARIN, show them your documentation that you are 
getting service from 2 providers to justify your need for an ASN
- If you don't meet the utilization requirements for getting a /24, 
request a /24 for multihoming under ARIN 4.2.3.6. from ONE of your 
providers (not both).


At UUnet/VZB we ask customers to provide their ASN as documentation that 
they have demonstrated their intent to multihome.


If you have existing IP space, and it's less than /24 don't be surprised 
if someone asks you to renumber.  If you have existing IP space /24 or 
larger, don't be surprised if someone turns you down under the 
multihoming policy.



http://www.arin.net/policy/nrpm.html#four236

4.2.3.6. Reassignments to multihomed downstream customers

Under normal circumstances an ISP is required to determine the prefix 
size of their reassignment to a downstream customer according to the 
guidelines set forth in RFC 2050. Specifically, a downstream customer 
justifies their reassignment by demonstrating they have an immediate 
requirement for 25% of the IP addresses being assigned, and that they 
have a plan to utilize 50% of their assignment within one year of its 
receipt. This policy allows a downstream customer's multihoming 
requirement to serve as justification for a /24 reassignment from their 
upstream ISP, regardless of host requirements. Downstream customers must 
provide contact information for all of their upstream providers to the 
ISP from whom they are requesting a /24. The ISP will then verify the 
customer's multihoming requirement and may assign the customer a /24, 
based on this policy. Customers may receive a /24 from only one of their 
upstream providers under this policy without providing additional 
justification. ISPs may demonstrate they have made an assignment to a 
downstream customer under this policy by supplying ARIN with the 
information they collected from the customer, as described above, or by 
identifying the AS number of the customer. This information may be 
requested by ARIN staff when reviewing an ISP's utilization during their 
request for additional IP addresses space.




Is that still the way to make it happen? Are there alternate
approaches (besides DNS games) that I should consider?

Who should I talk to? Certain well-known companies seem incapable of
discussing service that isn't cookie-cutter.



It's really pretty straightforward and common actually... but I wouldn't 
be surprised if sales folks don't know ARIN and/or routing policy.




Thanks,
Bill Herrin





--
~*~*~*~*~*~*~*~*~*~*~*~
 Heather Schiller
 Customer Security
 IP Address Management
 1.800.900.0241
~*~*~*~*~*~*~*~*~*~*~*~

RE: [NANOG] Multihoming for small frys?

[Security Admin (NetSec)]

I got a /22 from ARIN last year; ASN 36516.  Is the /20 only rule relatively 
new?

Not multi-homed yet because my 2nd provider does not support it yet.

Best Regards,

Edward Ray

-Original Message-
From: Tony Varriale [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 20, 2008 9:32 PM
To: Andy Dills
Cc: nanog@nanog.org
Subject: Re: [NANOG] Multihoming for small frys?

AFAIK, ARIN doesn't give out /22s anymore.

Last time I went to the well...it's was a /20 or better.

tv
- Original Message -
From: "Andy Dills" <[EMAIL PROTECTED]>
To: "William Herrin" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, May 20, 2008 11:05 PM
Subject: Re: [NANOG] Multihoming for small frys?


> On Tue, 20 May 2008, William Herrin wrote:
>
>> Hi folks,
>>
>> An administrative question about multihoming:
>>
>> I have a client who needs to multihome with multiple vendors for
>> reliability purposes, currently in the Northern Virginia area and
>> later on with a fail-over site, probably in Hawaii. They have only a
>> very modest need for bandwidth and addresses (think: T1's and a few
>> dozen servers) but they have to have BGP multihoming and can afford to
>> pay for it.
>>
>> The last I heard, the way to make this happen was: Find a service
>> provider with IP blocks available in ARIN's set of /8's that permit
>> /24 announcements (networks 199, 204-207), buy a circuit and request a
>> /24 for multihoming. Then buy circuits from other providers using that
>> ISP's /24 and an AS# from ARIN.
>>
>> Is that still the way to make it happen? Are there alternate
>> approaches (besides DNS games) that I should consider?
>
> They should just get their own /22 from ARIN.
>
> If the future fail-over site doesn't help them show a /23's worth of
> justification, break out the ultimate fudge factor: SSL.
>
> Yes, I know, some would argue this isn't responsible usage of community
> resources.
>
> However, if I was representing the interests of a company whose existence
> relies on working connectivity, my biggest concern would be provider
> independance. Altruism is something I encourage my competitors to indulge
> in. In fact, the increasing value and decreasing pool of prefixes should
> motivate any proper capitalist to air on the side of being greedy: just as
> they aren't making any more land, they aren't making any more IP(v4)
> space.
>
> My gut instinct has been telling me for half a decade that prefixes will
> get commoditized long before IPv6 settles in, and if I was representing
> the interests of a company who was in the situation you describe, I would
> certainly want to prepare for that possibility.
>
> ARIN really should allow direct allocation of /24s to multi-homed
> organizations. It wouldn't increase the table size, and it would reduce
> the wasteful (best common) practice I describe above.
>
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
>
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

--
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


--
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.co

Re: [NANOG] Multihoming for small frys?

[david raistrick]

On Tue, 20 May 2008, Tony Varriale wrote:


AFAIK, ARIN doesn't give out /22s anymore.


It's a recent change in the past couple of years.

Still current:

"However, for multi-homed organizations, the minimum allocation size is a 
/22"



http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html


Now, if you're not multihomed you still have the /20 as the longest 
prefix.



---
david raistrickhttp://www.netmeister.org/news/learn2quote.html
[EMAIL PROTECTED] http://www.expita.com/nomime.html

Re: [NANOG] Multihoming for small frys?

[Owen DeLong]

For multihomed, /22 is still the rule.

Owen DeLong
ARIN AC

On May 21, 2008, at 11:16 AM, Security Admin (NetSec) wrote:

I got a /22 from ARIN last year; ASN 36516.  Is the /20 only rule  
relatively new?


Not multi-homed yet because my 2nd provider does not support it yet.

Best Regards,

Edward Ray

-Original Message-
From: Tony Varriale [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 20, 2008 9:32 PM
To: Andy Dills
Cc: nanog@nanog.org
Subject: Re: [NANOG] Multihoming for small frys?

AFAIK, ARIN doesn't give out /22s anymore.

Last time I went to the well...it's was a /20 or better.

tv
- Original Message -
From: "Andy Dills" <[EMAIL PROTECTED]>
To: "William Herrin" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, May 20, 2008 11:05 PM
Subject: Re: [NANOG] Multihoming for small frys?



On Tue, 20 May 2008, William Herrin wrote:


Hi folks,

An administrative question about multihoming:

I have a client who needs to multihome with multiple vendors for
reliability purposes, currently in the Northern Virginia area and
later on with a fail-over site, probably in Hawaii. They have only a
very modest need for bandwidth and addresses (think: T1's and a few
dozen servers) but they have to have BGP multihoming and can  
afford to

pay for it.

The last I heard, the way to make this happen was: Find a service
provider with IP blocks available in ARIN's set of /8's that permit
/24 announcements (networks 199, 204-207), buy a circuit and  
request a
/24 for multihoming. Then buy circuits from other providers using  
that

ISP's /24 and an AS# from ARIN.

Is that still the way to make it happen? Are there alternate
approaches (besides DNS games) that I should consider?


They should just get their own /22 from ARIN.

If the future fail-over site doesn't help them show a /23's worth of
justification, break out the ultimate fudge factor: SSL.

Yes, I know, some would argue this isn't responsible usage of  
community

resources.

However, if I was representing the interests of a company whose  
existence

relies on working connectivity, my biggest concern would be provider
independance. Altruism is something I encourage my competitors to  
indulge
in. In fact, the increasing value and decreasing pool of prefixes  
should
motivate any proper capitalist to air on the side of being greedy:  
just as

they aren't making any more land, they aren't making any more IP(v4)
space.

My gut instinct has been telling me for half a decade that prefixes  
will
get commoditized long before IPv6 settles in, and if I was  
representing
the interests of a company who was in the situation you describe, I  
would

certainly want to prepare for that possibility.

ARIN really should allow direct allocation of /24s to multi-homed
organizations. It wouldn't increase the table size, and it would  
reduce

the wasteful (best common) practice I describe above.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog



___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

--
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com


--
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.co

Re: [NANOG] Multihoming for small frys?

[Tony Varriale]

Thanks for the info.  We needed larger than /22 anyways.

I am a bit surprised that they will hand out a small allocaiton for 
multihomers.  These days it's very easy to do.  And, could be a easy way to 
horde some v4.


Notice the caveats:

To qualify under the IPv4 Multi-homing policy, your organization must prove 
an intent to multi-home, demonstrate utilization for at least a /23-worth of 
IP addresses assigned by upstream providers, and provide 3-, 6-, and 
12-month utilization projections.


In addition, your organization must agree to use the requested IPv4 address 
space to renumber out of your current address space, and to return the 
original address space to your upstream provider(s) once the renumbering is 
complete. Additional space will not be allocated until this is completed. 
Organizations that qualify under this policy may also qualify and request 
space under ARIN's general IPv4 allocation policy.


Of course, this could be smoke and mirrors.  Not sure.

tv

- Original Message - 
From: "Andy Dills" <[EMAIL PROTECTED]>

To: "Tony Varriale" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, May 21, 2008 1:53 AM
Subject: Re: [NANOG] Multihoming for small frys?



On Tue, 20 May 2008, Tony Varriale wrote:


AFAIK, ARIN doesn't give out /22s anymore.

Last time I went to the well...it's was a /20 or better.


Nah, it's /22 for multi-homed networks, /20 for single-homed.


http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html

4.3.2.2 Multihomed Connection
For end-users who demonstrate an intent to announce the requested space in
a multihomed fashion, the minimum block of IP address space assigned is a
/22. If assignments smaller than a /22 are needed, multihomed end-users
should contact their upstream providers. When prefixes are assigned which
are longer than /20, they will be from a block reserved for that purpose.




Are there really networks who can justify a /20 that aren't multi-homed?
The mind boggles.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
--- 

Re: Renumbering, was: [NANOG] Multihoming for small frys?

[Deepak Jain]

Can we all agree that while renumbering sucks, a /24 (or less) is a 
pretty low-pain thing to renumber (vs. say, renumbering a /20 or shorter 
prefix?) In an ideal world, you never have to renumber because your 
allocations were perfect from the get-go.


We've all been to the other, more realistic place, no?

While we all feel pain for folks who have to do renumbers, even if EVERY 
single host in there is a MAJOR dns server (which is my personal worst 
case) for MAJOR sites, even *that* has become much easier to address 
than it used to be.


This is probably rhetorical, but I feel like some threshold of 
materiality should be roughly described so Operators don't get whipsawed 
 over variable length renumbers longer than a certain length.



DJ

Re: Renumbering, was: [NANOG] Multihoming for small frys?

[David Coulson]

Deepak Jain wrote:
Can we all agree that while renumbering sucks, a /24 (or less) is a 
pretty low-pain thing to renumber (vs. say, renumbering a /20 or 
shorter prefix?) In an ideal world, you never have to renumber because 
your allocations were perfect from the get-go.
Depends - If you're an Enterprise where 90% of the equipment is managed 
by people who work in the same building, it's not horrible. I renumbered 
a bunch of /20s onto a /18 where 75% of the equipment was not in my (or 
the company's) control. That sucked big time.


David

Re: [NANOG] Multihoming for small frys?

[Sean Figgins]

William Herrin wrote:


I have a client who needs to multihome with multiple vendors for
reliability purposes, currently in the Northern Virginia area and
later on with a fail-over site, probably in Hawaii. They have only a
very modest need for bandwidth and addresses (think: T1's and a few
dozen servers) but they have to have BGP multihoming and can afford to
pay for it.


Now, I have a question about this...  Is the customer using the sites 
for redundancy, and will have both upstream providers in each site?


Honestly, a small operation like this may be better served by multiple 
connections to the same provider.  Such a setup can usually be done to 
multiple routers, through redundant circuit paths, and done at 
substantially less cost that two different providers.  And, in my 
experience, using one provider can often be more reliable than multiple 
providers, given how many providers transport facilities ride the same 
fiber path, and sometimes the same bundle.


 -Sean

Re: Renumbering, was: [NANOG] Multihoming for small frys?

[Jack Bates]

David Coulson wrote:
Depends - If you're an Enterprise where 90% of the equipment is managed 
by people who work in the same building, it's not horrible. I renumbered 
a bunch of /20s onto a /18 where 75% of the equipment was not in my (or 
the company's) control. That sucked big time.


I had the same issue. Add to that recursive DNS servers and the support issues 
of everything that depends on them in and not in your direct control. While 
mostly taken care of within a year, I've seen small side effects of the renumber 
over 5 years later. Small things that work under normal conditions but still 
have mention of the old IPs which cause problems when rare conditions occur (ie, 
outages under specific circumstances).


Jack Bates

Re: [NANOG] Multihoming for small frys?

[Pete Templin]

Tony Varriale wrote:

Thanks for the info.  We needed larger than /22 anyways.

I am a bit surprised that they will hand out a small allocaiton for 
multihomers.  These days it's very easy to do.  And, could be a easy way 
to horde some v4.


Nope, you can horde a /24 for a single device, but it's 
provider-assigned.  If you can't justify a /23 -now-, you don't qualify 
for an ARIN multihomers' /22.


pt

Re: Renumbering, was: [NANOG] Multihoming for small frys?

[Deepak Jain]

David Coulson wrote:

Deepak Jain wrote:
Can we all agree that while renumbering sucks, a /24 (or less) is a 
pretty low-pain thing to renumber (vs. say, renumbering a /20 or 
shorter prefix?) In an ideal world, you never have to renumber because 
your allocations were perfect from the get-go.
Depends - If you're an Enterprise where 90% of the equipment is managed 
by people who work in the same building, it's not horrible. I renumbered 
a bunch of /20s onto a /18 where 75% of the equipment was not in my (or 
the company's) control. That sucked big time.




Right, but a /20 is a /lot/ more space than a /24. I think I'd say that 
shorter than a /21 is certainly a decent threshold of pain (personally). 
Even if its all in-house.


There are ways to make it less painful and special painless cases (an 
all NAT space), but as a shot-in-the-dark, that's a pretty good bet [you 
almost certainly have a decent mix of network and server gear, different 
authorities, different topologies, etc]


DJ

Re: Renumbering, was: [NANOG] Multihoming for small frys?

[David Coulson]

Jack Bates wrote:
I had the same issue. Add to that recursive DNS servers and the 
support issues of everything that depends on them in and not in your 
direct control.
Indeed. I recall Proxy ARP and a lot of NAT was involved :) At least you 
can keep track of the people who didn't update their configs, even 
though they said they did.


David

Re: [NANOG] Multihoming for small frys?

[Seth Mattinen]

Sean Figgins wrote:


Now, I have a question about this...  Is the customer using the sites 
for redundancy, and will have both upstream providers in each site?


Honestly, a small operation like this may be better served by multiple 
connections to the same provider.  Such a setup can usually be done to 
multiple routers, through redundant circuit paths, and done at 
substantially less cost that two different providers.  And, in my 
experience, using one provider can often be more reliable than multiple 
providers, given how many providers transport facilities ride the same 
fiber path, and sometimes the same bundle.



I have to disagree...

About two years ago, maybe less, Sprint was doing some maintenance in 
California and was moving stuff through an alternate path in Arizona. 
However, while the CA path was off, someone took a backhoe to the AZ 
path. Neither the planned outage, the cut, nor myself were in the same 
state (I'm in Nevada). It didn't matter how many circuits I had with 
Sprint, because none of them worked, including my Sprint cell phone. 
However, I was still on the air because my other providers were unaffected.


Locally, yeah, the path in the ground are probably the same. But beyond 
that, it can matter, and I strongly recommend multihoming if the story 
above is something their organization would like to be protected from.


~Seth

Nortel 4450T switches and QoS?

[Brett Charbeneau]

	Does anyone have any experience with switches of this ilk - and how well 
they do throttling P2P traffic?
	The sales material purports that these switches "filter" at L2 which 
sounds groovy and all, but I'd really like to hear from someone who has used 
these for this purpose. And how well that actually worked for them.


--

Brett Charbeneau, GSEC Gold, GCIH Gold
Network Administrator
Williamsburg Regional Library
7770 Croaker Road
Williamsburg, VA 23188-7064
(757)259-4044  www.wrl.org
(757)259-4079 (fax)[EMAIL PROTECTED]

Re: [NANOG] Limiting ICMP

[John Kristoff]

On Sat, 17 May 2008 23:53:00 -0400
Drew Weaver <[EMAIL PROTECTED]> wrote:

> I'm wondering if anyone else has run into this/has heard of/(is responsible 
> for)/knows the reason behind large IP providers limiting ICMP on outbound 
> connections to the same amounts regardless of the size of the circuit?
>

I might be partially responsible for furthering some of that activity.
I've done this sort of thing on initial ingress facing links (e.g. LAN
segments with client-oriented systems) and it was me who provided the
sample configs for the cymru junos template for limiting udp and icmp.

Perhaps I mentioned it on a mailing list or in some internal documentation
somewhere, but the way I've done it is typically to limit those two IP
protocols (and sometimes other things like multicast) to some fraction
of a percent on a edge LAN ingress link speed, which is not in the
template.  Egress, aggregate and peering/Internet facing links shouldn't
have these limits (yes, kind of a pain to manage if you're not good at
router config management).  Unfortunately I didn't provide all that
detail to the cymru folks at the time and as I'm sure they are aware
those templates are quite a bit outdated now and could easily take some
heavy revisioning.

In the environments where I've done this, my experience was that it was
an acceptable practice at the time and in a couple cases it did help the
net upstream when something went wrong (e.g. this did stop some real
DoS traffic for me more than once).  I made use of protocol counters or
some monitoring tools to ensure they were not unnecessarily dropping
valid packets.  Your mileage may vary of course, as it apparently does?

John

Re: [NANOG] Limiting ICMP

[Rob Thomas]

Yep, agreed, we need to update those docs.  The basic ICMP filtering 
guide still resides here, and comments are welcome:


   


John Kristoff wrote:

On Sat, 17 May 2008 23:53:00 -0400
Drew Weaver <[EMAIL PROTECTED]> wrote:


I'm wondering if anyone else has run into this/has heard of/(is responsible 
for)/knows the reason behind large IP providers limiting ICMP on outbound 
connections to the same amounts regardless of the size of the circuit?



I might be partially responsible for furthering some of that activity.
I've done this sort of thing on initial ingress facing links (e.g. LAN
segments with client-oriented systems) and it was me who provided the
sample configs for the cymru junos template for limiting udp and icmp.

Perhaps I mentioned it on a mailing list or in some internal documentation
somewhere, but the way I've done it is typically to limit those two IP
protocols (and sometimes other things like multicast) to some fraction
of a percent on a edge LAN ingress link speed, which is not in the
template.  Egress, aggregate and peering/Internet facing links shouldn't
have these limits (yes, kind of a pain to manage if you're not good at
router config management).  Unfortunately I didn't provide all that
detail to the cymru folks at the time and as I'm sure they are aware
those templates are quite a bit outdated now and could easily take some
heavy revisioning.

In the environments where I've done this, my experience was that it was
an acceptable practice at the time and in a couple cases it did help the
net upstream when something went wrong (e.g. this did stop some real
DoS traffic for me more than once).  I made use of protocol counters or
some monitoring tools to ensure they were not unnecessarily dropping
valid packets.  Your mileage may vary of course, as it apparently does?

John



--
Rob Thomas
Team Cymru
The WHO and WHY team
http://www.team-cymru.org/

[NANOG-announce] Lightning Talk submissions open for NANOG42

[Todd Underwood]

/me dons the NANOG PC Chair hat again

Lightning talk submissions for NANOG42 are now open:

http://nanogpc.org/lightning/

Lightning talks are short talks of interest to the audience in line
with the rest of the program.  They are strictly limited to 10 minutes
(including questions).  Lightning talks are selected by the program
committee during the conference but we will probably select the first
round of lightning talks just prior to the start of the conference.

Get your submissions in.

/me takes off the hat and wipes his brow

-- 
_
todd underwood +1 603 643 9300 x101
renesys corporationgeneral manager babbledog
[EMAIL PROTECTED]   http://www.renesys.com/blog

___
NANOG-announce mailing list
[EMAIL PROTECTED]
http://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] New socials for NANOG 42 Brooklyn -- Register

[Todd Underwood]

howdy,

NANOG42 will take place in brooklyn, NY in about a week and a half.
there are two new socials (you can read "socials" as "free drinks and
snacks") that have been added to the agenda at 

http://nanog.org/mtg-0806/agenda.html

* equinix is sponsoring a social on tuesday evening:

   http://nanog.org/mtg-0806/invitation.html

* and our host, Telx is sponsoring an event on wednesday evening:

   http://nanog.org/mtg-0806/invitation2.html

both events are open to all nanog attendees.


if you have not yet registered for NANOG42, please do so now.  the
hotel rooms at good rates are all gone, but the registration numbers
indicate that many of you are waiting until the last minute to
register.  please take a minute to do so now so that we can have a
more accurate count of the number of expected attendees:

https://nanog.merit.edu/registration/


thanks,

todd




-- 
_
todd underwood +1 603 643 9300 x101
renesys corporationgeneral manager babbledog
[EMAIL PROTECTED]   http://www.renesys.com/blog

___
NANOG-announce mailing list
[EMAIL PROTECTED]
http://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] Program Committee Vacancy Call for Volunteers Extension

[Todd Underwood]

. o O ( i'm thinking about just leaving this program committee chair
hat on)

the call for volunteers to the nanog program committee (originally
sent:

http://mailman.nanog.org/pipermail/nanog/2008-April/000153.html

) has been extended through the end of the weekend (to sunday, 25 may
2008).  there were some miscommunications among nominators and the
program committee that means that a number of nominations and
solicitations did not take place in a timely fashion.  i believe the
fair thing to do is to extend the time frame for several days to make
it possible for everyone who is interested in this seat to offer their
name.

so if you're interested, review the call for volunteers and submit
your name promptly, please.

thanks,

todd

-- 
_
todd underwood +1 603 643 9300 x101
renesys corporationgeneral manager babbledog
[EMAIL PROTECTED]   http://www.renesys.com/blog

___
NANOG-announce mailing list
[EMAIL PROTECTED]
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: [NANOG] Multihoming for small frys?

[Sean Figgins]

Seth Mattinen wrote:

About two years ago, maybe less, Sprint was doing some maintenance in 
California and was moving stuff through an alternate path in Arizona. 
However, while the CA path was off, someone took a backhoe to the AZ 
path. Neither the planned outage, the cut, nor myself were in the same 
state (I'm in Nevada). It didn't matter how many circuits I had with 
Sprint, because none of them worked, including my Sprint cell phone. 
However, I was still on the air because my other providers were unaffected.


I've been in a situation before where circuits with two different 
providers were both taken out by the same fiber cut.  These were large 
long-haul circuits.


I've had another situation where two circuits out of Charlotte, NC ended 
up in the same bundle in Virginia, even though they were one was going 
to Atlanta, and another was headed to DC, through two different 
providers.  One provider bought the bundle from someone, and leased part 
of it to another company, who sublet it to another company, that 
provided service to the the carrier that provided us the service. 
Kicker was that I think it was originally our fiber.


Of course, these are circuits, not internet traffic.  With todays' large 
networks, it's really hard to completely isolate any given city.  Oh 
sure, it can happen, and some cities are unpopular, and don't hardly 
qualify for IP service, so diversity is hard to justify, but most cities 
have at least two, if not three or more paths out.


 -Sean

Re: [NANOG] Multihoming for small frys?

[Tony Varriale]

Yup.  You can horde.

You can easily justify a /23 these days and not be multihomed still get a 
/22.


tv
- Original Message - 
From: "Pete Templin" <[EMAIL PROTECTED]>

To: "Tony Varriale" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, May 21, 2008 3:32 PM
Subject: Re: [NANOG] Multihoming for small frys?



Tony Varriale wrote:

Thanks for the info.  We needed larger than /22 anyways.

I am a bit surprised that they will hand out a small allocaiton for 
multihomers.  These days it's very easy to do.  And, could be a easy way 
to horde some v4.


Nope, you can horde a /24 for a single device, but it's provider-assigned. 
If you can't justify a /23 -now-, you don't qualify for an ARIN 
multihomers' /22.


pt 

RE: Renumbering, was: [NANOG] Multihoming for small frys?

[McMasters, Jeremy]

I worked for an ISP that was bought by another ISP and had to assign all
new IP's roughly a /16 worth.  Good times.  Only one ASN thank goodness

-Original Message-
From: Deepak Jain [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 4:09 PM
To: nanog list
Subject: Re: Renumbering, was: [NANOG] Multihoming for small frys?


Can we all agree that while renumbering sucks, a /24 (or less) is a 
pretty low-pain thing to renumber (vs. say, renumbering a /20 or shorter

prefix?) In an ideal world, you never have to renumber because your 
allocations were perfect from the get-go.

We've all been to the other, more realistic place, no?

While we all feel pain for folks who have to do renumbers, even if EVERY

single host in there is a MAJOR dns server (which is my personal worst 
case) for MAJOR sites, even *that* has become much easier to address 
than it used to be.

This is probably rhetorical, but I feel like some threshold of 
materiality should be roughly described so Operators don't get whipsawed

  over variable length renumbers longer than a certain length.


DJ

Re: [NANOG] Multihoming for small frys?

[Robert E. Seastrom]

It's always been possible to get resources by lying or committing
fraud - the common law crime of obtaining property by false pretenses
predates the Internet by a substantial margin.

---rob

"Tony Varriale" <[EMAIL PROTECTED]> writes:

> Yup.  You can horde.
>
> You can easily justify a /23 these days and not be multihomed still
> get a /22.
>
> tv
> - Original Message - 
> From: "Pete Templin" <[EMAIL PROTECTED]>
> To: "Tony Varriale" <[EMAIL PROTECTED]>
> Cc: 
> Sent: Wednesday, May 21, 2008 3:32 PM
> Subject: Re: [NANOG] Multihoming for small frys?
>
>
>> Tony Varriale wrote:
>>> Thanks for the info.  We needed larger than /22 anyways.
>>>
>>> I am a bit surprised that they will hand out a small allocaiton for
>>> multihomers.  These days it's very easy to do.  And, could be a
>>> easy way to horde some v4.
>>
>> Nope, you can horde a /24 for a single device, but it's
>> provider-assigned. If you can't justify a /23 -now-, you don't
>> qualify for an ARIN multihomers' /22.
>>
>> pt

RE: [NANOG] Multihoming for small frys?

[William Mullaney]

I got a /22 in January, and was told by someone from ARIN that the
policy below only applied to allocations to ISP's, not to assignments
for end customers.  At the time, they said an end user must show at
least 25% immediate usage (so a /24) and that there was no requirement
for future usage.  In my experience, if you can show you have some
semblance of ability, two real peers, and an existing and established
business, you should be able to get the request through easily in about
a week, start to finish.  When you're ready, fill out the request form,
the worst that can happen is they reject you or defer you until you can
provide more info.  If you have questions for/about ARIN, call them
(number is on the website) and talk to one of their people, they've been
pretty knowledgeable, friendly, and helpful in my experience.

-Will

-Original Message-
From: Tony Varriale [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 3:03 PM
To: Andy Dills
Cc: nanog@nanog.org
Subject: Re: [NANOG] Multihoming for small frys?

Thanks for the info.  We needed larger than /22 anyways.

I am a bit surprised that they will hand out a small allocaiton for 
multihomers.  These days it's very easy to do.  And, could be a easy way
to 
horde some v4.

Notice the caveats:

To qualify under the IPv4 Multi-homing policy, your organization must
prove 
an intent to multi-home, demonstrate utilization for at least a
/23-worth of 
IP addresses assigned by upstream providers, and provide 3-, 6-, and 
12-month utilization projections.

In addition, your organization must agree to use the requested IPv4
address 
space to renumber out of your current address space, and to return the 
original address space to your upstream provider(s) once the renumbering
is 
complete. Additional space will not be allocated until this is
completed. 
Organizations that qualify under this policy may also qualify and
request 
space under ARIN's general IPv4 allocation policy.

Of course, this could be smoke and mirrors.  Not sure.

tv

- Original Message - 
From: "Andy Dills" <[EMAIL PROTECTED]>
To: "Tony Varriale" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, May 21, 2008 1:53 AM
Subject: Re: [NANOG] Multihoming for small frys?


> On Tue, 20 May 2008, Tony Varriale wrote:
>
>> AFAIK, ARIN doesn't give out /22s anymore.
>>
>> Last time I went to the well...it's was a /20 or better.
>
> Nah, it's /22 for multi-homed networks, /20 for single-homed.
>
>
> http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html
>
> 4.3.2.2 Multihomed Connection
> For end-users who demonstrate an intent to announce the requested
space in
> a multihomed fashion, the minimum block of IP address space assigned
is a
> /22. If assignments smaller than a /22 are needed, multihomed
end-users
> should contact their upstream providers. When prefixes are assigned
which
> are longer than /20, they will be from a block reserved for that
purpose.
>
>
>
>
> Are there really networks who can justify a /20 that aren't
multi-homed?
> The mind boggles.
>
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---