Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Michael Sokolov]

James Hess  wrote:

> Auto MDI/MDI-X  is an optional feature in the 1000BaseT standard.

Can someone please explain how can the whole MDI vs. MDI-X distinction
be meaningful at all for 1000BaseT?  I thought they run 250 Mbps on each
of the 4 pairs in both directions using some form of echo-cancelling
hybrid techniques.  If one no longer has separate Rx and Tx pins, how is
it meaningful to talk about MDI or MDI-X?

I thought that for 1000BaseT a straight-through cable was always the
"native" cable choice for connecting any two ports, be they switch ports
or station ports - is that not true?  It also seems to me that a
crossover cable should never make sense for 1000BaseT, but from what I
understand such cables do work because the PHYs are generally smart
enough to detect "hey, I'm seeing signal on pair B that ought to be on
pair C" and auto-correct.

MS

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Steven King]

Along with bpduguard, Cisco switches also continue to look for loops
with loopguard. They continuously look for the Keepalive packets that
they send out each port. So as long as you have not turned off STP all
together on the port, you will be fine.

On 3/26/10 6:21 PM, Matthew Huff wrote:
> Bpduguard if running cisco.
>  
> set all the switch ports to bpduguard or enable it globally
>
>
> -Original Message-
> From: Chuck Anderson [mailto:c...@wpi.edu] 
> Sent: Friday, March 26, 2010 6:09 PM
> To: nanog@nanog.org
> Subject: Auto MDI/MDI-X + conference rooms + bored == loop
>
> Anyone have suggestions on Ethernet LAN loop-prevention?  With the 
> advent of Auto MDI/MDI-X ports on switches, it seems way too easy to 
> accidentally or maliciously create loops between network jacks.  We 
> have bored or inattentive people plugging in patch cords between 
> adjacent network jacks.  STP for loop-prevention isn't working so well 
> for us.
>
> STP "edge" or "portfast" or "faststart" modes are required for 
> end-station ports (with normal STP, DHCP often times out after 30+ 
> seconds it takes to go into Forwarding state).  Since the "edge" STP 
> mode goes into Forwarding state immediately, there is a period when 
> loops will form, causing havok with upstream gear until STP blocks the 
> port (if it ever does see below).
>
> "Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet 
> switches.  Apparently, many of them don't do any kind of STP at all.  
> Recommendations on ones that do STP?
>
> RSTP: is it any better than traditional STP in regards to "edge" ports 
> and blocking before a loop gets out of hand?  Or perhaps blocking for 
> 5-10 seconds before going into Forwarding state, hopefully preventing 
> loops before they happen but also allowing DHCP clients to get an 
> address without timeouts?  Recommendations on "Desktop" switches that 
> do RSTP?
>
> Thanks for your suggestions/discussion.
>
>   

-- 
Steve KingSenior

Senior Linux Engineer - Advance Internet, Inc.
Cisco Certified Network Associate
CompTIA Linux+ Certified Professional
CompTIA A+ Certified Professional

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[James Hess]

On Fri, Mar 26, 2010 at 9:29 PM, Chuck Anderson  wrote:
> So basically, the problem is the core switches implement a proprietary
> loop-prevention protocol that sends "beacon" frames out every 500ms,
> and if a certain number of these special frames come back (exceeds
--> loop first, but I'm beginning to think that this protocol is crap and
> I should just disable it and let the core ride out the loop in the

Ah, nasty..  it seems like you definitely should want to keep the
beacon frames from getting injected then. Taking down core links ought
to be harder than 1 user emitting a few frames.   A malicious user, or
a naive user with a malicious trojan on their computer could try to
send fake beacons, to cause trouble.  I for one might start thinking
if the beacons can be sunk from end user ports by brute force, using a
 Layer 2 ACL.

I wonder if RFC 5556, IETF TRILL specs, or  802.1aq/802.1Qbb /
Datacenter Ethernet  / Bridging  standards  and more  robust
standards-based loop avoidance standards will ever get finalized,
considering they have been drafts for over 5 years,   it seems like
the standardization is very sluggish.
A new protocol is probably the right solution,  but it might not be
ready until 2015 at this rate.

> Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T?
> It would be nice if I could shut it off.

Auto MDI/MDI-X  is an optional feature in the 1000BaseT standard.
Automatic negotiation of speeds and duplex, is mandatory due to 802.3ab,
but not auto-crossover

You  can get that here
http://standards.ieee.org/getieee802/802.3.html
Clause  40.4.4   in IEEE 802.3-2008 -- Section Three
states the following:

"40.4.4 Automatic MDI/MDI-X Configuration  Automatic MDI/MDI-X
Configuration is intended to eliminate the need for crossover cables
between simi
lar devices. Implementation of an automatic MDI/MDI-X configuration is
optional for 1000BASE-T   devices. If an automatic configuration
method is used, it shall comply with the following specifications. The
  assignment of pin-outs for a 1000BASE-T crossover function cable is
shown in Table40–12 in 40.8.
"


--
-J

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Chuck Anderson]

On Fri, Mar 26, 2010 at 08:29:52PM -0500, James Hess wrote:
> Most all switch manufacturers provide some type of  port security
> feature that allows an  end-user connection port to automatically be
> disabled and require admin intervention to re-activate, if the number
> of MAC addresses exceed  a configurable number,   e.g. allow 5  MAC
> addresses,  which are remembered as that port's list of  "secured" MAC
> addresses  with an aging time of  5 minutes.

In fact, the last time this happened, I implemented exactly what you 
describe, mac-security with a limit of 5 MACs.  The security kicked in 
and shutdown the port, but not before the core shutdown the edge 
switch's uplinks (see below).

> Use that function, and use the functions of a switch that provide
> storm control  for client ports.  With a reasonable aging duration
> for expiring secured MAC addresses.

Have that.

> If a  client port   emits packets with more than the expected number
> of MAC address  sources within a short time,  then that  should be an
> early warning that traffic has taken an improper path.

Have that.

> Keeping in mind a loop doesn't necessarily create an instant issue,
> until there is other broadcast traffic on the network,  that crosses
> the loop, and starts messing up the CAM table  on the upstream device,
>  as well as possibly generating duplicate traffic.

Which pretty much means within milliseconds on my network.

> But with port security, the number of devices that lose packets due to
> the loop should be limited   (the smaller you set the limit without
> impacting legitimate use of the port,   the better).

So basically, the problem is the core switches implement a proprietary 
loop-prevention protocol that sends "beacon" frames out every 500ms, 
and if a certain number of these special frames come back (exceeds 
threshold) it shuts down the port.  Even with a 10:1 ratio of 
threshold settings on the two redundant links to the edge switch, it 
still trips both thresholds fast enough that both redundant links get 
shutdown in the short time before the edge switch's protection 
mechanism (mac-security, STP, bpduprotect, whatever) kicks in.  I've 
now set the ratio to 100:1 (500:5 in actual packet counts) and the 
transmit interval to 1000ms in the hopes that at least one core link 
will survive long enough for the edge port to shutdown and break the 
loop first, but I'm beginning to think that this protocol is crap and 
I should just disable it and let the core ride out the loop in the 
hopes that it survives without taking down the entire core before the 
edge switch shutdown happens.

The good news is that this core is being replaced soon, hopefully with 
gear that will be able to implement a service-provider-like design 
with per-port VLAN separation as was suggested in this thread.  But it 
surprises me that low-end switch vendors (like NetGear) still put out 
crap that doesn't do STP, especially when the switch does Auto 
MDI/MDI-X, which is just asking for trouble.

Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T?  
It would be nice if I could shut it off.

Thanks for all the ideas.

RE: ARIN negotiation?

[Jeremy Charles]

Thanks to those who replied to offer experience and input on working with ARIN. 
 You've given me some helpful information to pass along to our legal team when 
considering the RSA.

Cheers!

-JC

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[James Hess]

On Fri, Mar 26, 2010 at 5:21 PM, Matthew Huff  wrote:
> Bpduguard if running cisco.  set all the switch ports to bpduguard or enable 
> it globally

Bpduguarding a cool idea, and not a bad protective measure, if running
that vendor's equipment, but  it  still allows a possibly large
disruption  for the (small) duration until the first BPDU is received
and relies on reasonable operation from the thing creating a loop --
the guard is a  no-op  if  whatever crosses jacks does not pass STP
PDUs.

Whether it is enough, depends on your threshold of pain for looping,
packet loss,  and the frequency of conference room physical
configuration errors.

Most all switch manufacturers provide some type of  port security
feature that allows an  end-user connection port to automatically be
disabled and require admin intervention to re-activate, if the number
of MAC addresses exceed  a configurable number,   e.g. allow 5  MAC
addresses,  which are remembered as that port's list of  "secured" MAC
addresses  with an aging time of  5 minutes.

Use that function, and use the functions of a switch that provide
storm control  for client ports.  With a reasonable aging duration
for expiring secured MAC addresses.

If a  client port   emits packets with more than the expected number
of MAC address  sources within a short time,  then that  should be an
early warning that traffic has taken an improper path.

Keeping in mind a loop doesn't necessarily create an instant issue,
until there is other broadcast traffic on the network,  that crosses
the loop, and starts messing up the CAM table  on the upstream device,
 as well as possibly generating duplicate traffic.

But with port security, the number of devices that lose packets due to
the loop should be limited   (the smaller you set the limit without
impacting legitimate use of the port,   the better).

--
-J

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Mark Foster]

or reboot is problematic in many cases.  Many systems drop link-state during 
reboot for a long-enough period that the bridge-port restarts its spanning tree 
process, making results across reboots consistently bad.


Interesting; Windows tends to bring link up well-prior to the login 
dialogue and ive never seen a dhcp lease fail such that the user has had 
no lease by the time they try to login...

Re: ARIN negotiation?

[John Curran]

Hello Jeremy - 
 
  So let's see if I can clarify some of your questions:

  - ARIN doesn't generally modify the terms of the RSA agreement 
(this is a fairness issue so that all address holders are 
under similar terms to the extent possible)

  - We've actually revised the RSA on several occasions to make
the language more member-friendly.  The most recent change
was the release in February 2009 of RSA 10.0, noted here:
 
I'd recommend referring your legal team to this announcement
and related FAQ documents, as we've tried to make as much of 
background information and reasoning available as possible.

  - If there are changes that your legal department would like
to suggest, I would like to hear about them, and they'll be 
considered to see if they can be accommodated in a future 
revision to be made available for all members.  Email is 
the best way to reach me, but I can also be tracked down
at my ARIN office number (+1 703 227 9850).

Thanks!
/John

John Curran
President and CEO
ARIN

On Mar 26, 2010, at 5:45 PM, Jeremy Charles wrote:

> Has anyone here had their legal department balk at the legal agreement that 
> ARIN wants you to sign when you get things like an AS number or an IP block?  
> Any luck in negotiating with ARIN?
> 
> The agreement has language at the top saying that ARIN doesn't accept 
> modifications, but our legal team is questioning whether that means it really 
> is non-negotiable.  They're not exactly fans of it as it is written.

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Owen DeLong]

On Mar 26, 2010, at 4:33 PM, Mark Foster wrote:

> 
>> "Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet
>> switches.  Apparently, many of them don't do any kind of STP at all.
>> Recommendations on ones that do STP?
> 
> If the network fabric you're on is important enough to cause you grief in the 
> event of a STP event, you shouldn't be fielding 'dumb' switches.
> 
> Even the 'dumbest' switch I would ever place into user-space is fully 
> managable, layer 2 with VLAN's and STP support.  That is, it's in a cabinet 
> or TC and fed by infrastructure cabling, and the only folks who can get at it 
> are the engineers and techs supporting the site.
> 
> The other side of things is that if DHCP times out once during STP 
> negotiation, it rarely times out twice. Users whos machines are 'dynamically 
> connected' often enough to have STP related glitches in their DHCP grab 
> should know enough to hit 'repair' or run ipconfig /renew - or should be told 
> to reboot :-)
> 
or reboot is problematic in many cases.  Many systems drop link-state during 
reboot for a long-enough period that the bridge-port restarts its spanning tree 
process, making results across reboots consistently bad.

>> RSTP: is it any better than traditional STP in regards to "edge" ports
>> and blocking before a loop gets out of hand?  Or perhaps blocking for
>> 5-10 seconds before going into Forwarding state, hopefully preventing
>> loops before they happen but also allowing DHCP clients to get an
>> address without timeouts?  Recommendations on "Desktop" switches that
>> do RSTP?
> 
> There's plenty of desktop switches out there which are close to 'fully 
> featured' - but obviously there's money involved. If your uplink switch (at 
> the very least) supports STP then at least you can isolate the problem if the 
> switch itself can't handle, but I wouldn't recommend this.
> 
With the additional advantage that the uplink switch link to the 
conference-room switch doesn't flap often enough to cause DHCP issues, but, 
will shut down the port if properly configured and the conference-room switch 
at least passes the BPDUs around the loop.

Owen

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Anton Kapela]

On Mar 26, 2010, at 7:48 PM, Chuck Anderson wrote:

> If you have 2 network jacks next to each other in a conference room, 
> do they each get configured as a separate "user"?

Indeed, most of the buildings have a 'community room' like that -- but all the 
deployed ports (unless ordered differently) will get incrementing-vlan 
assignments, so indeed, they'd be different vlans back to l3 core. 

> What happens if a 
> user connects them together?

Nothing, basically, as the network from edge port towards IP edge is (or should 
be) loop-free. The router will hear DHCP req's on 2x ints, but the client will 
(should) pick the first-heard response. Depending on the DHCP client 
implementation, it may wedge/break, but I haven't encountered one in testing. 
For higher-availability from edge towards IP core, LACP/PAGP provides 
link-independence, and UDLD/802 OAM provide something of a decent safety-net 
for breakage detection in metro-spans over other providers/resellers. 

> What happens if a user plugs a desktop 
> switch into one of them, then connects two ports on *that* switch 
> together?

In my example config, bcast or mcast over 100 pps shuts the port that's 
receiving the bcast or mcast's down -- but, that's a configurable action. It 
could discard them, police them, or just report a syslog/trap to the NMS... Of 
course, this is all switch-vendor specific, etc.

> Would this work in a collapsed L2/L3 core (no agg, no L3 at edge)?

Oh, indeed -- and is. The UTOPIA network (http://www.utopianet.org/) in SLC, 
Utah, is doing basically this for it's ISP-reseller tiers. ISP's get customers 
on vlans or Q-stacked vlans, and do what they will with it. The ISP's I've 
talked with have tended to use Juni ERX for this, but there's nothing stopping 
one from using IOS, or another vendor that can do this trick. It just implies 
something to consider in the layer2 transport network (support for man l2 addrs 
in cam, QinQ, etc) at design-time.

> When doing 1:1 VLAN:Port mapping, can you do more than 4096 
> VLANs/ports?  Or are you doing QinQ?

Indeed -- q-stacking enables this. In most cases, I don't backhaul more than a 
few hundred vlans per building -- if it's over 200 to 250 ports/jacks, I 
generally drop local 3550/3560/3750 or cpu-based boxes on-site, routing towards 
the metro edge/backbone.

> Cool, but I'm not sure this will work in my non-Cisco campus 
> environment with 10,000 edge ports.

Ahh; a pickle. C and J do indeed enable this in many of the popular boxes, 
which is great. That's not to say other vendors don't have something like 
it--the concept is perhaps the most valuable bit to discuss here, imho; the 
vendor-particulars are less important.

-Tk

[NANOG-announce] Early registration for NANOG 49

[Steve Feldman]

Registration is now open for the 49th NANOG meeting, to be held in San  
Francisco on June 13-16, 2010 and hosted by Netflix.

The early registration price is $450, so register now to get the best  
value!

Hotel reservations are also available.  The group rate expires on May  
24, 2010, or when the room block is full.

See http://www.nanog.org for more information on the meeting, and  
follow the links to register and reserve your hotel room.

See you in San Francisco!
Steve Feldman
NANOG Steering Committee chair


___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: IP4 Space

[Christopher LILJENSTOLPE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings Owen,

The only problem is that there will be a number of devices that the 
eyeballs like that won't ever see an IPv6 packet (specifically thinking about 
the CE devices in the home).  As such, it won't be IPv6 only, it will be 
dual-stack.  Eventually we won't be able to give that eyeball's NAT box a 
unique address, then the proliferation of state begins

Chris

On 27 Mar 2010, at 08.42 , Owen DeLong wrote:

> Dave,
>   It's clear we disagree about what will happen in an obviously
> unpredictable future. I think that eyeball networks will deploy IPv6
> rapidly due to the high costs of attempting to continue to hack IPv4.
> You believe that something else will happen.  In time, we will see
> which of us turns out to be more correct.  We can look at it in
> hindsight over drinks in about 5 years or so.
> 
> Owen
> 
> On Mar 26, 2010, at 1:32 PM, Dave Israel wrote:
> 
>> 
>> 
>> On 3/26/2010 1:31 PM, Owen DeLong wrote:
>>> 
>>> On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote:
>>> 
>>> You should ask your server guy how he plans to talk to your core
>>> stakeholders when they can't get IPv4 any more.
>> 
>> Then, at that time, both he and his key stakeholders will experience
>> pain while they both deploy IPv6, or more likely,  his key stakeholders
>> will add another level of NAT-like indirection to give themselves space
>> to expand with the address pool they have.
>> 
 At the CxO level, it's all about the money.  Or the lack therof.
 
>>> How much less money will you have when donors can not reach your
>>> website or have a poor user experience doing so?
>> 
>> This assumption is incorrect. "They can't keep nursing IPv4 forever. 
>> Eventually everybody will have to switch to v6.  If you don't, you'll be
>> sorry.  Just wait and see."  That attitude did not force any previous
>> supposed IPv4-killer protocol to be deployed.  The fact is, for the
>> foreseeable future,  his donors will tend to have a better experience
>> over v4 than v6.  He isn't going to be blindsided by the need to deploy
>> v6, and he knows it.  By the time an important v4 host is not reachable
>> via the entire internet (and at full speed), v6 will have been
>> everywhere for years.
>> 
>> An address space crisis will not result in v6 deployment from repentant
>> network engineers who did not see the light in time.  An address space
>> crisis will merely result in more hacks to keep v4 running longer.  v6
>> will be deployed slowly by the curious, encouraged by features v6 has
>> that they want and with the assumption that they will still be able to
>> do everything they can do on v4 (either through translation or dual
>> stacking.)  This process can be accelerated by something that v6 can do
>> that v4 can't.  So far, there's nothing that fits that description;
>> everything being done over v6 can also be done over v4. 
>> 
> 
> 
> 

- ---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJLrUppAAoJEGmx2Mt/+Iw/k30IAIv4rBRUbpWpFt7g5aXj5Jdh
BfT7vKZp20Ho4O4IPPu5gqF1w5m/PWAsdyyuD+seUaVx/r6+KQbS5cLuErt+RXtb
nZShLBjmXRusuJaz6Wj9ydTPaCZ0YdAC+drLLVN+7ogyoLpk3bp8JYf9nA66eHV5
BvaepyWOO47Fl2jG18Zds/xuPDlx9wTTi/fdeJiPAfLMFUKyMhoooFbqZXYd1Go4
tZVZWShvD8WOSiCnBr746WiuUpsqzpk0UPD+fmkciMkLEC3kCCJlRg0ak0O/SSlC
nl8DgMk/ADY421ilZpUs27NwrpjOd8AXMgXoDhmeZ4q7HyH7KqqVrBlWrWuYe6Q=
=ELTE
-END PGP SIGNATURE-

Re: ARIN negotiation?

[Christopher LILJENSTOLPE]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

yes; no; without reservation; really, why would a competent lawyer have any 
problems accepting that contract :) ?
On 27 Mar 2010, at 08.45 , Jeremy Charles wrote:

> Has anyone here had their legal department balk at the legal agreement that 
> ARIN wants you to sign when you get things like an AS number or an IP block?  
> Any luck in negotiating with ARIN?
> 
> The agreement has language at the top saying that ARIN doesn't accept 
> modifications, but our legal team is questioning whether that means it really 
> is non-negotiable.  They're not exactly fans of it as it is written.
> 
> 
> (I probably can't share what my legal counsel is saying to me about the 
> agreement, but it's probably not relevant to the question anyway...)
> 
> 
> ===
> Jeremy Charles
> Epic - Computer and Technology Services Division
> jchar...@epic.com
> 
> Phone:  608-271-9000   Fax:  608-271-7237
> 
> 

- ---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJLrUnQAAoJEGmx2Mt/+Iw/smoH/2eOivfobfS8RLEESWVp/cDx
QYv7ALqfKh4RArXr3lRWtYjpJhjCwBH+bPDbycEyQGtq4738Ry5fC+MMwmwQf8GZ
be6xa6C4RXxGMuRfaNX3xpPIxU893Vg++2vEvApQItrgBuMoc8R3+yxzT7s4P4b8
G0FnKp469LYiSFVaH2/0Pd8FrmXRUAMHWfi4BvOp3+rb8mKBReTUtfN7Sl/Rgts7
D1C7TjKo0lBN/4W6jjB0WAXA3A4MZF+HqHX3l28FIIpsv28NecWJfNun1Ja8PVmh
O7yIg/RKrxezCLnNWEp6A7zeBSvpqDkrr2gKKrWDdKOkZXsa2cnby/2bBLCbtBk=
=WweW
-END PGP SIGNATURE-

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Chuck Anderson]

On Fri, Mar 26, 2010 at 06:56:15PM -0400, Anton Kapela wrote:
> In general, I avoid the potential for layer2 loops to any 
> user-accesible layer2 ports in a manner that many edge network and 
> broadband providers may find familiar -- vlan per user, tail, port, 
> etc. -- aggregated in a hierarchical manner within the building, 
> metro area, or city.

If you have 2 network jacks next to each other in a conference room, 
do they each get configured as a separate "user"?  What happens if a 
user connects them together?  What happens if a user plugs a desktop 
switch into one of them, then connects two ports on *that* switch 
together?

> avoiding the preconditions necessary for loops/etc to pose a problem 
> to the agg/border/etc of a network. Don't worry about users' being 

Would this work in a collapsed L2/L3 core (no agg, no L3 at edge)?

> After the access ports are setup and trunking per-port layer2 frames 
> up to the l3 edge (could be 3550, 650x, mwr-1941, etc), we have 
> pages of things like:

When doing 1:1 VLAN:Port mapping, can you do more than 4096 
VLANs/ports?  Or are you doing QinQ?

> A few words on this config: in what you see above, a user simply 
> cannot introduce enough traffic to the network (unicast) to matter 
> (i.e. perhaps they create an unknown unicast dest flood..), and will 
> be shut down if they spew enough bcast/mcast frames (thresholds set 
> appropriate given your expected end-user profiles). Further, only 
> the first 10 mac addresses can ride this bus (sorry, no LAN parties 
> without prior approval), mitigating concerns for CAM or vlan table 
> exhaustion. Lastly, no funky l3/4 acl's are required to prevent 
> users handing out DHCP addresses, leaking RA's, or fronting ARP as 
> your routers MAC address to their vlan-sharin' neighbors--simply 
> because they don't get to send layer2 frames to anyone but the 
> upstream routers control plane.

Cool, but I'm not sure this will work in my non-Cisco campus 
environment with 10,000 edge ports.

Thanks.

Re: IPv4 ANYCAST setup

[Mark Smith]

On Fri, 26 Mar 2010 14:24:21 +0100
Jeroen Massar  wrote:

> InterNetX - Lutz Muehlig wrote:
> > Hello,
> > 
> > has someone experience in anycast ipv4 networks (to support DNS)?
> 
> "Never been done" "Dangerous" "TCP does not work" etc etc etc.
> 
> I assume quite a number of people know how to do it, especially as
> several root DNS servers abuse it.
> 
> Simple recipe:
>  - Box with:
>- Your favourite OS
>- Quagga or OpenBGPd
>- Your favourite DNS server
>  - Announce the IP of the anycast node in BGP
>  - Monitor the DNS server, when it does not work kill your local BGPd
>and notify the admins that it broke
> 
> That is it. Probably with the above couple of things, google a bit and
> find the rest.
> 

I was involved in building an anycast setup where we had two anycast
DNS /32 addresses. Each of them was the backup for the other i.e. each
DNS server was announcing both /32s via BGP, with opposite weights. If
one failed, the other DNS server then took over the failed DNS
cache's queries, and as it was also already an operational DNS
server for one of the anycast addresses, it's DNS cache was already hot.

For load balancing, we alternated the order of announcing the DNS
server addresses in e.g. PPP IPCP, DHCP. That worked somewhat
surprisingly well - the peak query per second values on each of them
were no more than about 10% different.

One trap we got caught by was stateful firewalling on the host. We knew
to up the number of stateful connections, however on that particular
Linux distro there were two places it was set - /etc/sysctl.conf and in
the iptables configuration. We only knew about the first, so when the
firewall rules were updated the number of supported stateful
connections was dropped down to too low a level. It wasn't funny to
have one DNS server stop answering queries, and have it's own
monitoring script fail itself, switch all the traffic to the other one
and then have that die too for the same reason. Lots of gnashing of
teeth until we worked out .

The final and better solution was to stop doing stateful firewalling on
DNS queries, using the iptables 'raw' table.

Regards,
Mark.

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Chuck Anderson]

On Fri, Mar 26, 2010 at 03:33:56PM -0700, Owen DeLong wrote:
> Switches that support STP?

Yes, "soho" or "desktop" switches I mean.  Apparently Netgear GS105's 
do not do STP at all, at least they don't claim to.

> There are switches that have STP protection such that they are
> portfast until they see an inbound BPDU and then revert to
> spanning tree on that port (it blocks, listens, learns, then
> forwards if appropriate).

Do the ports so configured also send BPDUs such that a loop on a 
"desktop" switch uplinked to that port will cause the port to see its 
own BPDUs and revert to STP Blocking?  Even if that is the case, I 
think the detection of BPDU and subsequent transition to Blocking will 
happen too slowly.  By then the damage is already done upstream in the 
collapsed L2/L3 core.

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Mark Foster]

"Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet
switches.  Apparently, many of them don't do any kind of STP at all.
Recommendations on ones that do STP?


If the network fabric you're on is important enough to cause you grief in 
the event of a STP event, you shouldn't be fielding 'dumb' switches.


Even the 'dumbest' switch I would ever place into user-space is fully 
managable, layer 2 with VLAN's and STP support.  That is, it's in a 
cabinet or TC and fed by infrastructure cabling, and the only folks who 
can get at it are the engineers and techs supporting the site.


The other side of things is that if DHCP times out once during STP 
negotiation, it rarely times out twice. Users whos machines are 
'dynamically connected' often enough to have STP related glitches in their 
DHCP grab should know enough to hit 'repair' or run ipconfig /renew - or 
should be told to reboot :-)



RSTP: is it any better than traditional STP in regards to "edge" ports
and blocking before a loop gets out of hand?  Or perhaps blocking for
5-10 seconds before going into Forwarding state, hopefully preventing
loops before they happen but also allowing DHCP clients to get an
address without timeouts?  Recommendations on "Desktop" switches that
do RSTP?


There's plenty of desktop switches out there which are close to 'fully 
featured' - but obviously there's money involved. If your uplink switch 
(at the very least) supports STP then at least you can isolate the 
problem if the switch itself can't handle, but I wouldn't recommend this.


Havn't fielded any recently but there's a fanless version of the Cisco 
2960 I was looking at a while ago for desktop use (fan noise is usualy an 
issue).


Mark.

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Anton Kapela]

Hi Chuck,

> Anyone have suggestions on Ethernet LAN loop-prevention?  With the 

In general, I avoid the potential for layer2 loops to any user-accesible layer2 
ports in a manner that many edge network and broadband providers may find 
familiar -- vlan per user, tail, port, etc. -- aggregated in a hierarchical 
manner within the building, metro area, or city. 

This simple and logical layer2 isolation (real isolation, none of this 
pvlan-edge stuff) basically solves many problems by simply avoiding the 
preconditions necessary for loops/etc to pose a problem to the agg/border/etc 
of a network. Don't worry about users' being entire walled-off from each other 
-- unicast IP reachability is not broken with this model. Currently, the IOS 
implementation of unnumbered vlans/subints provides proxy-arp responses for all 
in-prefix (as defined by loopback/interface pointer-membership) addresses that 
your end-users may issue who-has's for. 

This is analogous to docsis and rfc1483 half-bridge as often used on xDSL 
network edges -- layer3's not broken, but layer2 is nicely walled off per-user. 
Perhaps you could think of this as dedicated layer2 resources per customer edge 
(CE), rather, "complaining entity."

More here: 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtunvlan.html

I use this feature on 3550/3560/3750, sup2/sup720 on 6500; several colleagues 
have verified this works on 4900m an 4500's in 12.2SG trains. 

Of course, terminating lower-speed subints or QinQ tag'd vlan bundles works on 
higher-end ports (sip/spa), as well as all cpu-based boxes... 7200/7301 will 
consume QinQ ip subints for breakfast, and even give populate option 82 info in 
DHCP transactions auto-magically, if given the chance (by using helder-addrs on 
subints).

The user-facing port config is usually some per-site variation of this 
following flavor, configured expecting users to land at 10/fdx or hdx:

interface FastEthernet0/1
 description Unit 201 
 load-interval 30
 speed 10
 port security max-mac-count 10
 port security aging time 5
 port storm-control broadcast action shutdown
 port storm-control broadcast threshold rising 100 falling 50
 port storm-control multicast action shutdown
 port storm-control multicast threshold rising 100 falling 50
 port storm-control unicast action filter
 port storm-control unicast threshold rising 3000 falling 1000
 switchport access vlan 201
 spanning-tree portfast
 spanning-tree bpdufilter enable

...Errdisable autorecover (or having the user call the support desk) are some 
of the ways out of the down/down access port penalty box; mix and combine these 
elements to taste. If terminating fast or gig-e, scale things accordingly. 

After the access ports are setup and trunking per-port layer2 frames up to the 
l3 edge (could be 3550, 650x, mwr-1941, etc), we have pages of things like:

[...]

interface FastEthernet0/1.112
 encapsulation dot1Q 112
 ip unnumbered Loopback0
!
interface FastEthernet0/1.113
 encapsulation dot1Q 113
 ip unnumbered Loopback0
!
interface FastEthernet0/1.114
 encapsulation dot1Q 114
 ip unnumbered Loopback0

[...]

In my mdu and mtu layer2 edge sites, this approach has saved our posteriors 
from real problems--year in, year out. 

A few words on this config: in what you see above, a user simply cannot 
introduce enough traffic to the network (unicast) to matter (i.e. perhaps they 
create an unknown unicast dest flood..), and will be shut down if they spew 
enough bcast/mcast frames (thresholds set appropriate given your expected 
end-user profiles). Further, only the first 10 mac addresses can ride this bus 
(sorry, no LAN parties without prior approval), mitigating concerns for CAM or 
vlan table exhaustion. Lastly, no funky l3/4 acl's are required to prevent 
users handing out DHCP addresses, leaking RA's, or fronting ARP as your routers 
MAC address to their vlan-sharin' neighbors--simply because they don't get to 
send layer2 frames to anyone but the upstream routers control plane. 

-Tk

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Owen DeLong]

Switches that support STP?

There are switches that have STP protection such that they are
portfast until they see an inbound BPDU and then revert to
spanning tree on that port (it blocks, listens, learns, then
forwards if appropriate).

The only draw-back to such a configuration I am aware of is
that you have the (very small) overhead of all such ports
sending BPDUs.

Owen

On Mar 26, 2010, at 3:09 PM, Chuck Anderson wrote:

> Anyone have suggestions on Ethernet LAN loop-prevention?  With the 
> advent of Auto MDI/MDI-X ports on switches, it seems way too easy to 
> accidentally or maliciously create loops between network jacks.  We 
> have bored or inattentive people plugging in patch cords between 
> adjacent network jacks.  STP for loop-prevention isn't working so well 
> for us.
> 
> STP "edge" or "portfast" or "faststart" modes are required for 
> end-station ports (with normal STP, DHCP often times out after 30+ 
> seconds it takes to go into Forwarding state).  Since the "edge" STP 
> mode goes into Forwarding state immediately, there is a period when 
> loops will form, causing havok with upstream gear until STP blocks the 
> port (if it ever does see below).
> 
> "Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet 
> switches.  Apparently, many of them don't do any kind of STP at all.  
> Recommendations on ones that do STP?
> 
> RSTP: is it any better than traditional STP in regards to "edge" ports 
> and blocking before a loop gets out of hand?  Or perhaps blocking for 
> 5-10 seconds before going into Forwarding state, hopefully preventing 
> loops before they happen but also allowing DHCP clients to get an 
> address without timeouts?  Recommendations on "Desktop" switches that 
> do RSTP?
> 
> Thanks for your suggestions/discussion.
> 
> -- 
> - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)

RE: Auto MDI/MDI-X + conference rooms + bored == loop

[Matthew Huff]

Bpduguard if running cisco.
 
set all the switch ports to bpduguard or enable it globally


-Original Message-
From: Chuck Anderson [mailto:c...@wpi.edu] 
Sent: Friday, March 26, 2010 6:09 PM
To: nanog@nanog.org
Subject: Auto MDI/MDI-X + conference rooms + bored == loop

Anyone have suggestions on Ethernet LAN loop-prevention?  With the 
advent of Auto MDI/MDI-X ports on switches, it seems way too easy to 
accidentally or maliciously create loops between network jacks.  We 
have bored or inattentive people plugging in patch cords between 
adjacent network jacks.  STP for loop-prevention isn't working so well 
for us.

STP "edge" or "portfast" or "faststart" modes are required for 
end-station ports (with normal STP, DHCP often times out after 30+ 
seconds it takes to go into Forwarding state).  Since the "edge" STP 
mode goes into Forwarding state immediately, there is a period when 
loops will form, causing havok with upstream gear until STP blocks the 
port (if it ever does see below).

"Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet 
switches.  Apparently, many of them don't do any kind of STP at all.  
Recommendations on ones that do STP?

RSTP: is it any better than traditional STP in regards to "edge" ports 
and blocking before a loop gets out of hand?  Or perhaps blocking for 
5-10 seconds before going into Forwarding state, hopefully preventing 
loops before they happen but also allowing DHCP clients to get an 
address without timeouts?  Recommendations on "Desktop" switches that 
do RSTP?

Thanks for your suggestions/discussion.

-- 
- Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)

Re: Auto MDI/MDI-X + conference rooms + bored == loop

[Mike Lyon]

Disable the jacks all together and go wireless? Have them put in a trouble
ticket if they absolutely need a port activated in a conference room for a
one-time meeting.

-Mike




On Fri, Mar 26, 2010 at 3:09 PM, Chuck Anderson  wrote:

> Anyone have suggestions on Ethernet LAN loop-prevention?  With the
> advent of Auto MDI/MDI-X ports on switches, it seems way too easy to
> accidentally or maliciously create loops between network jacks.  We
> have bored or inattentive people plugging in patch cords between
> adjacent network jacks.  STP for loop-prevention isn't working so well
> for us.
>
> STP "edge" or "portfast" or "faststart" modes are required for
> end-station ports (with normal STP, DHCP often times out after 30+
> seconds it takes to go into Forwarding state).  Since the "edge" STP
> mode goes into Forwarding state immediately, there is a period when
> loops will form, causing havok with upstream gear until STP blocks the
> port (if it ever does see below).
>
> "Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet
> switches.  Apparently, many of them don't do any kind of STP at all.
> Recommendations on ones that do STP?
>
> RSTP: is it any better than traditional STP in regards to "edge" ports
> and blocking before a loop gets out of hand?  Or perhaps blocking for
> 5-10 seconds before going into Forwarding state, hopefully preventing
> loops before they happen but also allowing DHCP clients to get an
> address without timeouts?  Recommendations on "Desktop" switches that
> do RSTP?
>
> Thanks for your suggestions/discussion.
>
> --
> - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)
>
>

Auto MDI/MDI-X + conference rooms + bored == loop

[Chuck Anderson]

Anyone have suggestions on Ethernet LAN loop-prevention?  With the 
advent of Auto MDI/MDI-X ports on switches, it seems way too easy to 
accidentally or maliciously create loops between network jacks.  We 
have bored or inattentive people plugging in patch cords between 
adjacent network jacks.  STP for loop-prevention isn't working so well 
for us.

STP "edge" or "portfast" or "faststart" modes are required for 
end-station ports (with normal STP, DHCP often times out after 30+ 
seconds it takes to go into Forwarding state).  Since the "edge" STP 
mode goes into Forwarding state immediately, there is a period when 
loops will form, causing havok with upstream gear until STP blocks the 
port (if it ever does see below).

"Desktop" switches.  You know, those 4 or 5 port Gigabit Ethernet 
switches.  Apparently, many of them don't do any kind of STP at all.  
Recommendations on ones that do STP?

RSTP: is it any better than traditional STP in regards to "edge" ports 
and blocking before a loop gets out of hand?  Or perhaps blocking for 
5-10 seconds before going into Forwarding state, hopefully preventing 
loops before they happen but also allowing DHCP clients to get an 
address without timeouts?  Recommendations on "Desktop" switches that 
do RSTP?

Thanks for your suggestions/discussion.

-- 
- Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/)

The Cidr Report

[cidr-report]

This report has been generated at Fri Mar 26 21:11:54 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
19-03-10316783  195181
20-03-10318199  195244
21-03-10318191  194191
22-03-10317341  194985
23-03-10318630  195016
24-03-10318820  194978
25-03-10318566  194959
26-03-10318754  195401


AS Summary
 33979  Number of ASes in routing system
 14497  Number of ASes announcing only one prefix
  4402  Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
  96814336  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 26Mar10 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 319000   195345   12365538.8%   All ASes

AS6389  4055  319 373692.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  4402 1277 312571.0%   TWTC - tw telecom holdings,
   inc.
AS4766  1836  491 134573.3%   KIXS-AS-KR Korea Telecom
AS4755  1294  193 110185.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS1785  1778  682 109661.6%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS22773 1132   75 105793.4%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS18566 1059   33 102696.9%   COVAD - Covad Communications
   Co.
AS17488 1306  347  95973.4%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS8151  1537  626  91159.3%   Uninet S.A. de C.V.
AS10620 1028  170  85883.5%   Telmex Colombia S.A.
AS18101  907   62  84593.2%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS19262 1085  245  84077.4%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS7545  1047  239  80877.2%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS6478  1176  419  75764.4%   ATT-INTERNET3 - AT&T WorldNet
   Services
AS24560  864  239  62572.3%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS4808   844  237  60771.9%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS8452   969  364  60562.4%   TEDATA TEDATA
AS4134  1030  436  59457.7%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS4804   678   85  59387.5%   MPX-AS Microplex PTY LTD
AS7303   692  113  57983.7%   Telecom Argentina S.A.
AS7018  1564 1002  56235.9%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS5668   804  254  55068.4%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS17908  772  234  53869.7%   TCISL Tata Communications
AS3356  1233  696  53743.6%   LEVEL3 Level 3 Communications
AS35805  610  101  50983.4%   UTG-AS United Telecom AS
AS4780   655  155  50076.3%   SEEDNET Digital United Inc.
AS22047  545   49  49691.0%   VTR BANDA ANCHA S.A.
AS17676  575   87  48884.9%   GIGAINFRA Softbank BB Corp.
AS9443   555   74  48186.7%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS11492 1146  678  46840.8%   CABLEONE - CABLE ONE, INC.

Total  37178 99822719673.2%   Top 30 total


Possible Bogus Routes

2.0.0.0/16   AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project
2.1.0.0/21   AS12654 RIP

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 18-Mar-10 -to- 25-Mar-10 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS30890   50203  3.6% 113.6 -- EVOLVA Evolva Telecom s.r.l.
 2 - AS845230728  2.2%  42.9 -- TEDATA TEDATA
 3 - AS14420   22146  1.6%  55.8 -- CORPORACION NACIONAL DE 
TELECOMUNICACIONES CNT S.A.
 4 - AS45985   21594  1.5%5398.5 -- DAEWOOSEC Daewoo Securities 
Co., Ltd.
 5 - AS466817699  1.3%  54.6 -- LGNET-AS-KR LG CNS
 6 - AS19647   15320  1.1% 957.5 -- HPOD20001 - Hewlett-Packard 
Operation Division
 7 - AS432313234  0.9%   7.1 -- TWTC - tw telecom holdings, inc.
 8 - AS773813202  0.9%  29.5 -- Telecomunicacoes da Bahia S.A.
 9 - AS35805   12943  0.9%  21.2 -- UTG-AS United Telecom AS
10 - AS45987   12236  0.9%4078.7 -- DONGWHA-AS-KR EUNIQUE CO.,LTD
11 - AS12479   10644  0.8% 532.2 -- UNI2-AS Uni2 - Lince 
telecomunicaciones
12 - AS580310461  0.7% 104.6 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
13 - AS9829 9508  0.7%  15.0 -- BSNL-NIB National Internet 
Backbone
14 - AS3786 8791  0.6%  51.7 -- LGDACOM LG DACOM Corporation
15 - AS165698232  0.6%8232.0 -- ASN-CITY-OF-CALGARY - City of 
Calgary
16 - AS260257610  0.5%7610.0 -- COC - City of Calgary
17 - AS277477574  0.5%  44.0 -- Telecentro S.A.
18 - AS100367537  0.5%  27.8 -- CNM-AS-KR C&M Communication 
Co.,Ltd.
19 - AS100667153  0.5%  43.1 -- GAYANET-AS-KR CJ-CABLENET
20 - AS100376268  0.5%  43.5 -- NEXEYE-AS-KR Jeil CATV Co.,Ltd


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS165698232  0.6%8232.0 -- ASN-CITY-OF-CALGARY - City of 
Calgary
 2 - AS260257610  0.5%7610.0 -- COC - City of Calgary
 3 - AS45985   21594  1.5%5398.5 -- DAEWOOSEC Daewoo Securities 
Co., Ltd.
 4 - AS45987   12236  0.9%4078.7 -- DONGWHA-AS-KR EUNIQUE CO.,LTD
 5 - AS100525375  0.4%2687.5 -- KNU-AS Kyungpook National Univ.
 6 - AS5691 2348  0.2%2348.0 -- MITRE-AS-5 - The MITRE 
Corporation
 7 - AS327941072  0.1%1072.0 -- ICFG - International Church of 
the Foursquare Gospel
 8 - AS19647   15320  1.1% 957.5 -- HPOD20001 - Hewlett-Packard 
Operation Division
 9 - AS259691694  0.1% 847.0 -- SLU - St. Louis University
10 - AS459893420  0.2% 684.0 -- KLNETCO-AS-KR KL-Net Corp.
11 - AS42214 607  0.0% 607.0 -- IWC-AS SC International Work 
Company SRL
12 - AS1280  602  0.0% 602.0 -- ISC-AS1280 Internet Systems 
Consortium, Inc.
13 - AS22395 587  0.0% 587.0 -- GHCO-INTERNAP - Goldenberg 
Hehmeyer
14 - AS12479   10644  0.8% 532.2 -- UNI2-AS Uni2 - Lince 
telecomunicaciones
15 - AS104452748  0.2% 458.0 -- HTG - Huntleigh Telcom
16 - AS270971740  0.1% 435.0 -- DNIC-ASBLK-27032-27159 - DoD 
Network Information Center
17 - AS45960 374  0.0% 374.0 -- YTLCOMMS-AS-AP YTL 
COMMUNICATIONS SDN BHD
18 - AS27027 364  0.0% 364.0 -- ANBELL ASN-ANBELL
19 - AS35291 704  0.1% 352.0 -- ICOMM-AS SC Internet 
Communication Systems SRL
20 - AS28052 326  0.0% 326.0 -- Arte Radiotelevisivo Argentino


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 208.98.230.0/248232  0.6%   AS16569 -- ASN-CITY-OF-CALGARY - City of 
Calgary
 2 - 208.98.231.0/247610  0.5%   AS26025 -- COC - City of Calgary
 3 - 123.140.107.0/24   5399  0.4%   AS45985 -- DAEWOOSEC Daewoo Securities 
Co., Ltd.
 4 - 210.92.10.0/24 5399  0.4%   AS45985 -- DAEWOOSEC Daewoo Securities 
Co., Ltd.
 5 - 210.92.6.0/24  5399  0.4%   AS45985 -- DAEWOOSEC Daewoo Securities 
Co., Ltd.
 6 - 210.92.4.0/24  5397  0.4%   AS45985 -- DAEWOOSEC Daewoo Securities 
Co., Ltd.
 7 - 155.230.0.0/16 5373  0.4%   AS10052 -- KNU-AS Kyungpook National Univ.
 8 - 41.235.80.0/24 5081  0.3%   AS8452  -- TEDATA TEDATA
 9 - 183.109.74.0/244101  0.3%   AS45987 -- DONGWHA-AS-KR EUNIQUE CO.,LTD
10 - 210.120.80.0/244069  0.3%   AS45987 -- DONGWHA-AS-KR EUNIQUE CO.,LTD
11 - 210.120.82.0/244066  0.3%   AS45987 -- DONGWHA-AS-KR EUNIQUE CO.,LTD
12 - 62.193.80.0/24 3659  0.2%   AS5536  -- Internet-Egypt
13 - 85.60.192.0/23 3119  0.2%   AS12479 -- UNI2-AS Uni2 - Lince 
telecomunicaciones
14 - 194.126.40.0/213049  0.2%   AS24627 -- SHOWNET-KW-AS 
GULFSATCOMMUNICATIONS COMPANY K.S.C.
 AS25122 -- GULFSAT_COMMUNICATIONS-AS 
Gulfsat Communications Co.
15 - 199.114.154.0/24   2952  0.2%   AS1733  -- CENTAF-SWA 

Re: ARIN negotiation?

[bmanning]

I am aware of a general case where the RSA has been modified. As presented, the 
RSA is
targeted toward US-based commercial & not-for-profit entities.  If you are a 
soveriegn
in the ARIN region or are a state government in the US, I beleive there is some 
wiggle-room
for changing liability and venue clauses.

Your best bet is to inquire of the ARIN GC or legal team about your specfic 
concerns.

--bill manning


On Fri, Mar 26, 2010 at 04:45:45PM -0500, Jeremy Charles wrote:
> Has anyone here had their legal department balk at the legal agreement that 
> ARIN wants you to sign when you get things like an AS number or an IP block?  
> Any luck in negotiating with ARIN?
> 
> The agreement has language at the top saying that ARIN doesn't accept 
> modifications, but our legal team is questioning whether that means it really 
> is non-negotiable.  They're not exactly fans of it as it is written.
> 
> 
> (I probably can't share what my legal counsel is saying to me about the 
> agreement, but it's probably not relevant to the question anyway...)
> 
> 
> ===
> Jeremy Charles
> Epic - Computer and Technology Services Division
> jchar...@epic.com
> 
> Phone:  608-271-9000   Fax:  608-271-7237
> 

Re: ARIN negotiation?

[William Herrin]

On Fri, Mar 26, 2010 at 5:45 PM, Jeremy Charles  wrote:
> Has anyone here had their legal department balk at the legal
> agreement that ARIN wants you to sign when you get things
> like an AS number or an IP block?

Yes.

> Any luck in negotiating with ARIN?

No.

> The agreement has language at the top saying that ARIN
> doesn't accept modifications, but our legal team is
> questioning whether that means it really is non-negotiable.

It does.

> They're not exactly fans of it as it is written.
> (I probably can't share what my legal counsel is
> saying to me about the agreement, but it's
> probably not relevant to the question anyway...)

I can't imagine why anyone would balk at a contract where the "seller"
more or less says, "You agree that all your base are belong to us."

Suck it up; for better or for worse, that's how the game is played.
The good news is that you can hop on ARIN PPML and have a respectably
strong say in what rules get written.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

RE: ARIN negotiation?

[Aaron Wendel]

Don't know for sure but I doubt it.  The whole point is that everyone plays
by the same set of rules and opening up the RSA for "negotiation" would
defeat that purpose.



-Original Message-
From: Jeremy Charles [mailto:jchar...@epic.com] 
Sent: Friday, March 26, 2010 4:46 PM
To: nanog@nanog.org
Subject: ARIN negotiation?

Has anyone here had their legal department balk at the legal agreement that
ARIN wants you to sign when you get things like an AS number or an IP block?
Any luck in negotiating with ARIN?

The agreement has language at the top saying that ARIN doesn't accept
modifications, but our legal team is questioning whether that means it
really is non-negotiable.  They're not exactly fans of it as it is written.


(I probably can't share what my legal counsel is saying to me about the
agreement, but it's probably not relevant to the question anyway...)


===
Jeremy Charles
Epic - Computer and Technology Services Division
jchar...@epic.com

Phone:  608-271-9000   Fax:  608-271-7237


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.791 / Virus Database: 271.1.1/2752 - Release Date: 03/26/10
02:33:00

Re: ARIN negotiation?

[Christopher Morrow]

doesn't hurt to ask arin's legal folks, they work for you (kinda).

On Fri, Mar 26, 2010 at 2:45 PM, Jeremy Charles  wrote:
> Has anyone here had their legal department balk at the legal agreement that 
> ARIN wants you to sign when you get things like an AS number or an IP block?  
> Any luck in negotiating with ARIN?
>

Re: IP4 Space

[Owen DeLong]

Dave,
It's clear we disagree about what will happen in an obviously
unpredictable future. I think that eyeball networks will deploy IPv6
rapidly due to the high costs of attempting to continue to hack IPv4.
You believe that something else will happen.  In time, we will see
which of us turns out to be more correct.  We can look at it in
hindsight over drinks in about 5 years or so.

Owen

On Mar 26, 2010, at 1:32 PM, Dave Israel wrote:

> 
> 
> On 3/26/2010 1:31 PM, Owen DeLong wrote:
>> 
>> On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote:
>> 
>> You should ask your server guy how he plans to talk to your core
>> stakeholders when they can't get IPv4 any more.
> 
> Then, at that time, both he and his key stakeholders will experience
> pain while they both deploy IPv6, or more likely,  his key stakeholders
> will add another level of NAT-like indirection to give themselves space
> to expand with the address pool they have.
> 
>>> At the CxO level, it's all about the money.  Or the lack therof.
>>> 
>> How much less money will you have when donors can not reach your
>> website or have a poor user experience doing so?
> 
> This assumption is incorrect. "They can't keep nursing IPv4 forever. 
> Eventually everybody will have to switch to v6.  If you don't, you'll be
> sorry.  Just wait and see."  That attitude did not force any previous
> supposed IPv4-killer protocol to be deployed.  The fact is, for the
> foreseeable future,  his donors will tend to have a better experience
> over v4 than v6.  He isn't going to be blindsided by the need to deploy
> v6, and he knows it.  By the time an important v4 host is not reachable
> via the entire internet (and at full speed), v6 will have been
> everywhere for years.
> 
> An address space crisis will not result in v6 deployment from repentant
> network engineers who did not see the light in time.  An address space
> crisis will merely result in more hacks to keep v4 running longer.  v6
> will be deployed slowly by the curious, encouraged by features v6 has
> that they want and with the assumption that they will still be able to
> do everything they can do on v4 (either through translation or dual
> stacking.)  This process can be accelerated by something that v6 can do
> that v4 can't.  So far, there's nothing that fits that description;
> everything being done over v6 can also be done over v4. 
> 

ARIN negotiation?

[Jeremy Charles]

Has anyone here had their legal department balk at the legal agreement that 
ARIN wants you to sign when you get things like an AS number or an IP block?  
Any luck in negotiating with ARIN?

The agreement has language at the top saying that ARIN doesn't accept 
modifications, but our legal team is questioning whether that means it really 
is non-negotiable.  They're not exactly fans of it as it is written.


(I probably can't share what my legal counsel is saying to me about the 
agreement, but it's probably not relevant to the question anyway...)


===
Jeremy Charles
Epic - Computer and Technology Services Division
jchar...@epic.com

Phone:  608-271-9000   Fax:  608-271-7237

Re: IP4 Space

[Lamar Owen]

On Friday 26 March 2010 02:10:45 pm Mark Andrews wrote:
> In message <201003261157.23601.lo...@pari.edu>, Lamar Owen writes:
> > "Hey, great presentation.  Compelling arguments.  But I have one
> > question: will our existing gear that's not yet fully depreciated handle
> > it?  No? 

> What percentage of your equipment already supports IPv6?  Most 5 year old
> pieces of equipement already have IPv6 support.  It just needs to be
> enabled.

While my hypothetical answer was intentionally worst-case, with just-barely-
too-old hypothetical hardware being mentioned, in reality my situation is 
dealing with in some cases much older equipment.  I could go into detail, but 
you guys don't want to read my pity party, I'm sure.  

But "supporting IPv6"  and "handling it [dual stack with comparable 
throughput]" are two different things.

> > No, we cannot afford to forklift upgrade now.

> IPv6 is *not* a "forklift upgrade".  

I have few routers that will do IPv6 at all, and even fewer that will do it 
efficiently. Where we have layer 3 switches, none will do IPv6 in hardware, and 
only one will do it in software (OSR 7609).  For us, efficient dual-stack is a 
forklift upgrade.

> Turning on IPv6 doesn't really affect the amount of bandwith you use.

Not my point; if I have to spend on hardware/software upgrades (both being 
expensive, especially for out-of-contract hardware), then that's less dollars 
we have to spend on bandwidth.  Thus I lower my bandwidth, and spend that 
previously-opex money on capex instead.
 
[snip]

Don't misunderstand; we are and have been working on our plan for rolling out 
dual-stack, and I hope to have an IT intern this summer who will do the grunt 
work. 

I'm just having to try to be frugal when doing so, and with an understanding 
of the limitations of our older gear; I don't plan on being bit by some 
surprise 'feature' on one of our arcane pieces of gear. Once we understand 
what can do what and how fast it can do what it does, then we can 
intelligently redeploy equipment to produce the least pain at the least cost 
when IPv6 is enabled on it.  And if we have to purchase some newer kit, well, 
we'll cross that bridge when we come to it.  It will be a tough sell when we 
come to that bridge.

For instance, terminating a slow MetroE on Cisco 12000 1 port GE.  Overkill, 
on first glance, but not when you factor the actual IPv6 performance on that 
linecard.  And if already have that gear, fully amortized, then you've reduced 
your implementation cost (maybe not opex, but it would take a lot of reduction 
in opex to offset the reduction in capex), and thus made it more likely to 
happen.

> > At the CxO level, it's all about the money.  Or the lack therof.

> Turn on IPv6 should be a $0 cost.  Fully supporting IPv6 on all the
> services you offer will have some cost.

Nothing is $0 cost.  Time is money, after all.

But I do appreciate all the advice I have gleaned from NANOG and c-nsp over 
the years on the various and sundry ways people have performed the 'addition' 
of IPv6 to their IPv4 networks.  And I thank all those who have shared their 
experiences; even if it didn't help anyone else, it has helped this non-profit.

And while I understand most of the issues involved in the negative impact of 
not going dual-stack, and am in full agreement that we need to do so, I still 
have to look at the economic reality of the situation.  

Yes, in order to get this done in this economy you (or your department head, 
or whatever) have to get your CIO/CTO and maybe the CEO on board (typically 
the CIO would get the CEO on board).  But even with them on board the costs 
may be greater than the bottom line can currently bear.  And to get the CxO's 
on board you have to speak the C languageno, not that C, but the language 
of the CxO.  And that's dollars and cents; cost-benefit, etc.  Business 101.

Having said all that, we are well on the way to getting the equipment 
selection phase (among equipment we already have on hand or in service) 
completed.  We know what equipment we have that will definitely not work, and 
we know what equipment we have on hand that definitely will work.  Now we have 
to determine how well that workable equipment will work, and if there are ways 
to continue to use some of the equipment that is in service, but not able to 
handle IPv6.

Re: IP4 Space

[Lamar Owen]

On Friday 26 March 2010 01:31:33 pm Owen DeLong wrote:
> The other key point to take away... If your engineer is telling you that
> your ISP isn't ready yet, it's time for you to give your engineer your
> backing at telling the ISP that IPv6 is a requirement for contract
> renewal.

At least right now, I don't have many choices, as I'm in an area served by a 
rural ILEC under 47 USC 251(f) as cited by 47 CFR 51.401.  So there isn't an 
alternative at the moment.  But this ILEC has great engineers and techs, and I 
believe when they're ready to field trial IPv6 we'd likely be on the short 
list.

As for as the economy is concerned, due to the current situation I've already 
had to cut back on the bandwidth department, moving from an OC3 with full APS 
to a MetroE delivered via 1000Base-LX.  We are cutting our total Internet-
facing bandwidth by 75%.  We are scrambling as it is.  And my nickname of 'Mr. 
Make-Do' is getting a real workout.  

> You should ask your server guy how he plans to talk to your core
> stakeholders when they can't get IPv4 any more.

If full IPv4 deprecation is 10 years out, well, it's not yet on the radar, 
quite honestly.

> Here we come to the essential part of this which is hard to communicate.
> 
> It's kind of like flying up a box canyon (yes, I know flying up box
> canyons
> is best avoided, but, bear with me)...

[snip]

Our CEO is a FAA certified balloonist and balloonist certifier.  He understands 
these issues, with the caveat that a hot-air balloon can out-climb all but the 
most powerful airplanes, with climb rates of 1500 feet per minute being easily 
attainable.  So he's used to some agility in the climbing department, but 
understands how winds blow

But the analogy is flawed to a degree, since this isn't really a hard 'wall' 
we're headed to.  The farther in, the greater the pain, obviously, but, unlike 
a canyon wall, there is some give.  

> > At the CxO level, it's all about the money.  Or the lack therof.

> How much less money will you have when donors can not reach your
> website or have a poor user experience doing so?

As those folk who might donate lose IPv4 connectivity, then the pain 
increases, yes indeed.  Most of the people we apply to don't come in that way, 
though.  The bigger issue to us is when the NSF goes entirely IPv6 with no 
IPv4 connectivity, or when NASA does the same, or any of our other major 
funders.  This is, I would think, farther down the road than when unallocated 
IPv4 space is exhausted.

Not that this means we have room to procrastinate, but it's just not as 
cataclysmic of an event as flying a plane, or a balloon, into the wall at the 
end of a box canyon would be.

> That's a good thing.  Hopefully you pull the trigger soon enough that
> quickly is fast enough.  The key point here is to at least have a plan
> that gets IPv6 deployed to the important parts of your infrastructure
> before you start losing business (with the full understanding that
> plans never execute as fast as planned).

We're small enough where our network inertia shouldn't prevent us being able 
to only take a couple of months of work to implement dual stack in all of the 
critical pieces.  The hard and most time consuming part isn't the creation of 
the configs or the assignment of the addresses, but in the planning of which 
equipment that is on hand can be used, testing that equipment, and planning 
the deployment so that we experience the fewest hiccups.  We're working on 
that piece already, as other projects permit, and with a mind to turn it 
around rapidly when needed.

Re: NTP clock source

[todd glassey]

On 3/25/2010 7:03 AM, Dave Hart wrote:
> On Thu, Mar 25, 2010 at 12:51 UTC, Kyle Bader  wrote:
>> Can anyone recommend a solid clock souce (stratum 0) that's not overly
>> expensive?
> 
> All the options I'm aware of have no prices posted, sadly.  For me,
> that means "forget it, you don't want to spend that much", but then
> I'm not spending other people's money :)
> 
> In addition to Symmetricom and EndRun Technologies, Meinberg has a
> solid reputation in this space:
> 
> http://www.meinberg.de/english/products/#network_sync
> 
> I'm biased toward Meinberg because several of their staff contribute
> their skills to the development and maintenance of the ntp.org
> reference implementation.  They have also been generous donating
> hardware over the years to ntp.org and pool.ntp.org, and their Windows
> NTP binaries and GUI installer are widely used.

I totally agree! Meinberg's M300's rock solid and JTime is really easy
to deal with as are its distributor's.

> 
> The cheapest solution involves the Garmin GPS 18x LVC receiver and a
> soldering iron.  Unlike the USB and "PC" (232) versions of the GPS
> 18x, the LVC version supplies a pulse-per-second signal which makes it
> suitable for sub-millisecond NTP sync.  The supplied connector has to
> be cut off, a DB-9 serial hood wired in its place, and either a USB
> cable or other 5V power supply needs to be attached.  Or you can do as
> I did and pay for the completed GPS 18x LVC with DB-9 and USB
> connectors from a third party.  $105 from:
> 

True - you can build very accurate timekeeping service practices, but
ALL GPS-L1 based systems have one flaw - the provability of the time
data is squat. The evidence-model from a passive L1 system no matter how
accurate it is - is zero... zip... it has as much legal impact with a
competent lawyer on the other side, as you looking at mickey on your
wrist and setting the ToD by hand daily.

This  is becoming more and more important in the world of commercial
computing and something that timekeeping will have to morph towards to
insure its not unseated...

> 
> You also need a junkbox PC with real serial ports (not via a USB
> adapter), or the capacity on an existing server.  The GPS 18x cable is
> either 3m or 5m long, if your PC is not close enough to a
> southern-exposed window or to roof access for the 18x to lock, you may
> also need a RS-232 extension cable and USB power supply.  Unlike
> timing-focused GPSes, the 18x needs 3 or more birds in view to provide
> a PPS signal.
> 
> Good luck,
> Dave Hart
> 
> 

<>

Re: IP4 Space

[Dave Israel]

On 3/26/2010 1:31 PM, Owen DeLong wrote:
>
> On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote:
>
> You should ask your server guy how he plans to talk to your core
> stakeholders when they can't get IPv4 any more.

Then, at that time, both he and his key stakeholders will experience
pain while they both deploy IPv6, or more likely,  his key stakeholders
will add another level of NAT-like indirection to give themselves space
to expand with the address pool they have.

>> At the CxO level, it's all about the money.  Or the lack therof.
>>
> How much less money will you have when donors can not reach your
> website or have a poor user experience doing so?

This assumption is incorrect. "They can't keep nursing IPv4 forever. 
Eventually everybody will have to switch to v6.  If you don't, you'll be
sorry.  Just wait and see."  That attitude did not force any previous
supposed IPv4-killer protocol to be deployed.  The fact is, for the
foreseeable future,  his donors will tend to have a better experience
over v4 than v6.  He isn't going to be blindsided by the need to deploy
v6, and he knows it.  By the time an important v4 host is not reachable
via the entire internet (and at full speed), v6 will have been
everywhere for years.

An address space crisis will not result in v6 deployment from repentant
network engineers who did not see the light in time.  An address space
crisis will merely result in more hacks to keep v4 running longer.  v6
will be deployed slowly by the curious, encouraged by features v6 has
that they want and with the assumption that they will still be able to
do everything they can do on v4 (either through translation or dual
stacking.)  This process can be accelerated by something that v6 can do
that v4 can't.  So far, there's nothing that fits that description;
everything being done over v6 can also be done over v4. 

RE: Need to talk to Charter email contact

[Eric J Esslinger]

And a followup I've got someone in their mail group and we're working on 
clearing up the issue.

Thank you everyone for the replies and help.

__
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165



> -Original Message-
> From: Eric J Esslinger [mailto:eesslin...@fpu-tn.com]
> Sent: Friday, March 26, 2010 1:54 PM
> To: 'nanog@nanog.org'
> Subject: Need to talk to Charter email contact
>
>
> Good afternoon, I'm looking for some cluefull help from
> someone at Charter. I've got a static IP customer unable to
> deliver mail to charter.net customers and I can get no help
> trying to get in through the 'front door' of tech support.
> I've been forwarded to the residential spanish technicians 3
> times so far to get rid of me. Customer is unable to get any
> connection to ib1.charter.net on port 25 thus is unable to
> use the unbl...@charter.net
> method of clearing this up. The few people I've talked to
> that understand what I'm talking about say that his
> connection timing out is 'impossible to be an issue on the
> Charter side', but there is no block preventing his email on
> our side (and he can successfully send to aol, bellsouth,
> hotmail, gmail, yahoo, comcast, etc..) DNS is configured with
> mx, forward and reverse records properly setup.
>
> Can contact me off list by phone or email. Thanks in advance.
> __ Eric Esslinger Information
> Services Manager - Fayetteville Public Utilities
> http://www.fpu-tn.com/ (931)433-1522 ext 165
>
> 
> This message may contain confidential and/or proprietary
> information and is intended for the person/entity to whom it
> was originally addressed. Any use by others is strictly prohibited.
>

This message may contain confidential and/or proprietary information and is 
intended for the person/entity to whom it was originally addressed. Any use by 
others is strictly prohibited.
<>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 27 Mar, 2010

Report Website: http://thyme.apnic.net
Detailed Analysis:  http://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  316354
Prefixes after maximum aggregation:  146166
Deaggregation factor:  2.16
Unique aggregates announced to Internet: 153886
Total ASes present in the Internet Routing Table: 33654
Prefixes per ASN:  9.40
Origin-only ASes present in the Internet Routing Table:   29228
Origin ASes announcing only one prefix:   14274
Transit ASes present in the Internet Routing Table:4426
Transit-only ASes present in the Internet Routing Table:107
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  28
Max AS path prepend of ASN (28009)   24
Prefixes from unregistered ASNs in the Routing Table:  1005
Unregistered ASNs in the Routing Table: 155
Number of 32-bit ASNs allocated by the RIRs:496
Prefixes from 32-bit ASNs in the Routing Table: 511
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:224
Number of addresses announced to Internet:   2207844992
Equivalent to 131 /8s, 153 /16s and 10 /24s
Percentage of available address space announced:   59.6
Percentage of allocated address space announced:   66.2
Percentage of available address space allocated:   90.0
Percentage of address space in use by end-sites:   81.8
Total number of prefixes smaller than registry allocations:  151722

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:75992
Total APNIC prefixes after maximum aggregation:   26357
APNIC Deaggregation factor:2.88
Prefixes being announced from the APNIC address blocks:   72662
Unique aggregates announced from the APNIC address blocks:31966
APNIC Region origin ASes present in the Internet Routing Table:3984
APNIC Prefixes per ASN:   18.24
APNIC Region origin ASes announcing only one prefix:   1094
APNIC Region transit ASes present in the Internet Routing Table:618
Average APNIC Region AS path length visible:3.6
Max APNIC Region AS path length visible: 15
Number of APNIC addresses announced to Internet:  505653824
Equivalent to 30 /8s, 35 /16s and 170 /24s
Percentage of available APNIC address space announced: 79.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
APNIC Address Blocks 1/8,  27/8,  43/8,  58/8,  59/8,  60/8,  61/8,
   110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8,
   117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8,
   124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8,
   183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8,
   220/8, 221/8, 222/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:132383
Total ARIN prefixes after maximum aggregation:68542
ARIN Deaggregation factor: 1.93
Prefixes being announced from the ARIN address blocks:   105593
Unique aggregates announced from the ARIN address blocks: 40196
ARIN Region origin ASes present in the Internet Routing Table:13605
ARIN Prefixes per ASN: 7.76
ARIN Region origin ASes announcing only one prefix:5276
ARIN Region transit ASes present in the Internet Routing Table:1342
Average ARIN Region AS path length visible: 3.4
Max ARIN Region AS path length visible:  22
Number of ARIN addresses announced to Internet:   724613536
Equivalent to 43 /8s, 48 /16s and 185 /24s
Percentage of available ARIN address space announced:  61.7

Need to talk to Charter email contact

[Eric J Esslinger]

Good afternoon, I'm looking for some cluefull help from someone at Charter. 
I've got a static IP customer unable to deliver mail to charter.net customers 
and I can get no help trying to get in through the 'front door' of tech 
support. I've been forwarded to the residential spanish technicians 3 times so 
far to get rid of me.
Customer is unable to get any connection to ib1.charter.net on port 25 thus is 
unable to use the unbl...@charter.net method of 
clearing this up. The few people I've talked to that understand what I'm 
talking about say that his connection timing out is 'impossible to be an issue 
on the Charter side', but there is no block preventing his email on our side 
(and he can successfully send to aol, bellsouth, hotmail, gmail, yahoo, 
comcast, etc..)
DNS is configured with mx, forward and reverse records properly setup.

Can contact me off list by phone or email. Thanks in advance.
__
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165


This message may contain confidential and/or proprietary information and is 
intended for the person/entity to whom it was originally addressed. Any use by 
others is strictly prohibited.

Re: "Is TDM going the way of dial-up?"

[Justin M. Streiner]

On Fri, 26 Mar 2010, valdis.kletni...@vt.edu wrote:


On Fri, 26 Mar 2010 11:35:37 EDT, "Justin M. Streiner" said:


I don't see TDM going away entirely any time soon because it still comes
in handy for things like out-of-band management, etc, plus nowadays there
is lots of TDM gear on the secondary market that can be picked up
dirt-cheap.


All the same, the price of gear dropping through the floor on the secondary
market is usually a pretty good indication that the technology is played out,
because supply-and-demand says that demand for the gear will keep the price
propped up until the demand goes away - which usually means the tech is
played out.


I don't know too many people who build their out-of-band management 
networks out of the latest and greatest gear.  There are tons of Cisco 
2511s, 2611s, etc that have been given second lives as terminal servers.


There are also lots of areas where Ethernet transports are either 
ridiculously expensive because the carrier wants me to partially subsidize 
their initial build costs, or it's just flat-out not available.  There are 
also areas where I've seen it delivered over n x STS-1's bonded together, 
so the Ethernet frames are still riding over a SONET transport in many 
cases.


jms

Re: "Is TDM going the way of dial-up?"

[Valdis . Kletnieks]

On Fri, 26 Mar 2010 11:35:37 EDT, "Justin M. Streiner" said:

> I don't see TDM going away entirely any time soon because it still comes 
> in handy for things like out-of-band management, etc, plus nowadays there 
> is lots of TDM gear on the secondary market that can be picked up 
> dirt-cheap.

All the same, the price of gear dropping through the floor on the secondary
market is usually a pretty good indication that the technology is played out,
because supply-and-demand says that demand for the gear will keep the price
propped up until the demand goes away - which usually means the tech is
played out.

Anybody got a counter-example? ;)


pgpfVptIBk0DV.pgp
Description: PGP signature

Re: IP4 Space

[Mark Andrews]

In message <201003261157.23601.lo...@pari.edu>, Lamar Owen writes:
> On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote:
> > On 3/10/2010 16:57, Owen DeLong wrote:
> > > The target really needs to be the CxOs and the management,
> > > especially in places where there is content facing the general
> > > public.  Fortunately, Google, Yahoo, Netflix, etc. get it and have
> > > moved forward with IPv6. Some others are coming along.
> 
> > True.  CxOs can basically order it to be done.  
> 
> Fascinating thread; thanks to all for the many insights found here; this 
> thread has made my personal archive, just like the other long one did.  I've 
> chosen to reply to this post, because it directly addresses me, in addition t
> o 
> the other two topical posts I just couldn't resist.
> 
> So, let me give the insight from the CIO point of view, at least in terms of 
> a 
> non-profit organization.  How do I know this PoV?  I _am_ the CIO here, that'
> s 
> how.  Here's my hypothetical reaction to a hypothetical network engineer 
> coming to me with a good, solid, thorough, and compelling presentation on why
>  
> we need to go to IPv6:
> 
> "Hey, great presentation.  Compelling arguments.  But I have one question: 
> will our existing gear that's not yet fully depreciated handle it?  No? Sorry
> , 
> won't happen.  Not in this recession year; grants have been tight, and nobody
>  
> wants to fund this kind of capex right now.  Especially not since it hasn't 
> yet been five years since that previous grant bought some of that equipment. 

What percentage of your equipment already supports IPv6?  Most 5 year old
pieces of equipement already have IPv6 support.  It just needs to be enabled.
  
> No, we cannot afford to forklift upgrade now.

IPv6 is *not* a "forklift upgrade".  It's a parallel deployment that can
be done incrementally one service at a time.  The first step is to get
the bits to you.

> Do whatever you can with what we 
> have.  Or, if we absolutely must upgrade, find the money in the bandwidth 
> budget, and reduce our bandwidth if you have to do so. 

Turning on IPv6 doesn't really affect the amount of bandwith you use.

> Oh, and one other 
> thing: is our ISP supporting this IPv6 thing yet?  No?

You don't need your ISP to support IPv6 to turn on IPv6.  You just need
a IPv4 path to someone who does support IPv6.

> Come back when they 
> do, and when you figure out how to do this with our existing equipment, or fi
> nd 
> the money in the existing budget.  If you'll excuse me, I have a meeting with
>  
> the head of the server group, who says he needs funds for upgrading our serve
> r 
> farm to something called vSphere 4.  Says he can save us a couple of grand pe
> r 
> month in power and cooling costs, and has a plan to use the savings to upgrad
> e 
> our website to something more interactive for our core stakeholders."
> 
> Fact: many, if not most, businesses today are struggling to do basic things, 
> at least in my area.  IPv6 migration for many businesses is a desirable, not 
> an essential, thing to do, at least right now, and especially if serious cape
> x 
> is required to do it.  For some businesses, IPv6 addition is more of an 
> annoyance than a desirable.  So, many businesses, in today's economic climate
> , 
> will be dragged into IPv6 kicking and screaming simply because it's going to 
> be, in their eyes, dead cost.  Unless there is either a significant value-add
>  
> or cost reduction in the mid to long term, that is.  Having more addresses is
>  
> not enough.  And thus, ISP's which serve those businesses really don't have 
> sufficient economic reason to expend their own capex budgets down to the bone
> if the demand from their customers is low.  

Most IPv4 only ISPs are already carrying IPv6 traffic.  It's just
encapsulated by one of the early deployment methods. 
 
> At the CxO level, it's all about the money.  Or the lack therof.

Turn on IPv6 should be a $0 cost.  Fully supporting IPv6 on all the services
you offer will have some cost.

> In our case, yes, we're going to add IPv6 when it makes cents to do so.  
> Misspelling intentional; but I do have a plan in place to roll it out quickly
>  
> when needed, in no small part thanks to threads on NANOG and Cisco-NSP.
> -- 
> Lamar Owen
> Chief Information Officer
> Pisgah Astronomical Research Institute
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: [OT] Old kit (was:Re: IP4 Space)

[Jorge Amodio]

> Same is true of MIPS and PowerPC, though.  There are far more MIPS chips in
> routers than ever saw desktop use in SGI workstations; and while it might take
> a little while for Cisco's PowerPC driven routers' CPU's to outnumber all the
> PowerMacs our there, one day it will happen.

MIPS are now used as a core in many microcontrollers as an alternative to ARM.

I do development using Microchip's PIC32MX which is based on a 32-bits
MIPS M4K core, beautiful piece of silicon and very good performance.

I have a small collection of old gear, somewhere I've a couple of the
old Sinclair Spectrum Z-80 with 16KB RAM !!, amazing that one used to
program those things with 4K and some kids today don't know how to get
started if they don't have a couple of GB's in APIs.

Cheers
Jorge

Re: IP4 Space

[Owen DeLong]

On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote:


On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote:

On 3/10/2010 16:57, Owen DeLong wrote:

The target really needs to be the CxOs and the management,
especially in places where there is content facing the general
public.  Fortunately, Google, Yahoo, Netflix, etc. get it and have
moved forward with IPv6. Some others are coming along.



True.  CxOs can basically order it to be done.


Fascinating thread; thanks to all for the many insights found here;  
this
thread has made my personal archive, just like the other long one  
did.  I've
chosen to reply to this post, because it directly addresses me, in  
addition to

the other two topical posts I just couldn't resist.

So, let me give the insight from the CIO point of view, at least in  
terms of a
non-profit organization.  How do I know this PoV?  I _am_ the CIO  
here, that's
how.  Here's my hypothetical reaction to a hypothetical network  
engineer
coming to me with a good, solid, thorough, and compelling  
presentation on why

we need to go to IPv6:

"Hey, great presentation.  Compelling arguments.  But I have one  
question:
will our existing gear that's not yet fully depreciated handle it?   
No? Sorry,
won't happen.  Not in this recession year; grants have been tight,  
and nobody
wants to fund this kind of capex right now.  Especially not since it  
hasn't
yet been five years since that previous grant bought some of that  
equipment.
No, we cannot afford to forklift upgrade now.  Do whatever you can  
with what we
have.  Or, if we absolutely must upgrade, find the money in the  
bandwidth
budget, and reduce our bandwidth if you have to do so.   Oh, and one  
other
thing: is our ISP supporting this IPv6 thing yet?  No?  Come back  
when they
do, and when you figure out how to do this with our existing  
equipment, or find
the money in the existing budget.  If you'll excuse me, I have a  
meeting with
the head of the server group, who says he needs funds for upgrading  
our server
farm to something called vSphere 4.  Says he can save us a couple of  
grand per
month in power and cooling costs, and has a plan to use the savings  
to upgrade

our website to something more interactive for our core stakeholders."

_IF_ your gear is less than 5 years old, then, the answer probably  
isn't "no".

Most gear that is less than 5 years old WILL support IPv6.

However, even in cases where it won't, it is better to move forward  
with IPv6

where you can and have islands of IPv4-only on your network than to wait
until you have a complete IPv6 solution.

The other key point to take away... If your engineer is telling you that
your ISP isn't ready yet, it's time for you to give your engineer your
backing at telling the ISP that IPv6 is a requirement for contract
renewal.

You should ask your server guy how he plans to talk to your core
stakeholders when they can't get IPv4 any more.

Fact: many, if not most, businesses today are struggling to do basic  
things,
at least in my area.  IPv6 migration for many businesses is a  
desirable, not
an essential, thing to do, at least right now, and especially if  
serious capex
is required to do it.  For some businesses, IPv6 addition is more of  
an
annoyance than a desirable.  So, many businesses, in today's  
economic climate,
will be dragged into IPv6 kicking and screaming simply because it's  
going to
be, in their eyes, dead cost.  Unless there is either a significant  
value-add
or cost reduction in the mid to long term, that is.  Having more  
addresses is
not enough.  And thus, ISP's which serve those businesses really  
don't have
sufficient economic reason to expend their own capex budgets down to  
the bone if

the demand from their customers is low.



Here we come to the essential part of this which is hard to communicate.

It's kind of like flying up a box canyon (yes, I know flying up box  
canyons

is best avoided, but, bear with me)...

There comes a point, well before it is known to the passengers, where  
the

canyon becomes too narrow to make a maneuver known as a "canyon
turn" which is a _VERY_ tight course reversal and your best hope of
survival in a situation where you cannot out-climb the canyon walls.
This point may not be known to the inexperienced pilot, either, and,  
there
are plenty of aircraft dotting the slopes of various canyons to prove  
that.


If you fly beyond that point without making the turn, then, in essence,
even though nobody on the airplane knows it, the crash has already
occurred.

It will take time to deploy IPv6. If you start when IPv6 is essential  
to your

business continuity, then, your business will be suffering until your
deployment is completed.


At the CxO level, it's all about the money.  Or the lack therof.


How much less money will you have when donors can not reach your
website or have a poor user experience doing so?

In our case, yes, we're going to add IPv6 when it makes cents to do  
so.
Misspelling in

Re: [OT] Old kit

[Joel Jaeggli]

On 03/26/2010 10:16 AM, Owen DeLong wrote:
> 
> On Mar 26, 2010, at 8:45 AM, Lamar Owen wrote:
> 
>> On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote:
>>> For comparison look at the z-80 CPU which powered the early desktop
>>> computers. When the IBM PC came out, people thought that the Intel 8086
>>> would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared
>>> into all sorts of electronic
>>> devices where it serves as a controller for some function, perhaps the
>>> video display or the disk drive servos. And you can still buy them.
>>
>> Lots of DVD drives use embedded Z80's as controllers, including the
>> dual-layer
>> drive in my laptop.  Never thought that my teenage years spent hacking
>> Z80
>> machine code on a TRS-80 could produce a currently marketable skill
>>
>> Quick, Z80 joke coming Addr: :21 00 00 01 FF FF 11 01 00 ED
>> B0...Will it finish?
>>
>> Same is true of MIPS and PowerPC, though.  There are far more MIPS
>> chips in
>> routers than ever saw desktop use in SGI workstations; and while it
>> might take
>> a little while for Cisco's PowerPC driven routers' CPU's to outnumber
>> all the
>> PowerMacs our there, one day it will happen.
>>
>> And then all those PowerMac assembly language gurus might prove useful
>> in the
>> router side of the house.
> 
> The Juniper SRX-100 appears to have a MIPS or MIPS-like chip in it called
> an Octeon.

Cavium is mips arch... so are npu's or control plane processors from
RMI, Broadcom, Atheros, Marvell etc.

> Owen
> 
> 

Re: [OT] Old kit (was:Re: IP4 Space)

[Owen DeLong]

On Mar 26, 2010, at 8:45 AM, Lamar Owen wrote:


On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote:

For comparison look at the z-80 CPU which powered the early desktop
computers. When the IBM PC came out, people thought that the Intel  
8086
would make the Z-80 obsolete. But it didn't. The Z-80 just  
disappeared

into all sorts of electronic
devices where it serves as a controller for some function, perhaps  
the

video display or the disk drive servos. And you can still buy them.


Lots of DVD drives use embedded Z80's as controllers, including the  
dual-layer
drive in my laptop.  Never thought that my teenage years spent  
hacking Z80
machine code on a TRS-80 could produce a currently marketable  
skill


Quick, Z80 joke coming Addr: :21 00 00 01 FF FF 11 01 00 ED
B0...Will it finish?

Same is true of MIPS and PowerPC, though.  There are far more MIPS  
chips in
routers than ever saw desktop use in SGI workstations; and while it  
might take
a little while for Cisco's PowerPC driven routers' CPU's to  
outnumber all the

PowerMacs our there, one day it will happen.

And then all those PowerMac assembly language gurus might prove  
useful in the

router side of the house.


The Juniper SRX-100 appears to have a MIPS or MIPS-like chip in it  
called

an Octeon.

Owen

Re: IPv4 ANYCAST setup

[Joe Abley]

On 2010-03-26, at 10:04, Owen DeLong wrote:

> It doesn't require an unstable routing table.  There is a small set of
> locations that could hit routers with multipath that may "balance"
> the anycast packets down divergent paths.
> 
> Essentially, these are the topological midpoints between any two
> (or more) anycast servers.

As with most things, there are risks and benefits to distributing services 
using anycast. There are also risks and benefits from not doing so.

Far too many words to bother people with here on this list, but the ;login: 
article I include a link to earlier 
() 
attempts to discuss ways in which people can decide whether anycast suits their 
own particular circumstances ("Horses for Courses").


Joe

Re: IPv4 ANYCAST setup

[Owen DeLong]

On Mar 26, 2010, at 6:55 AM, Jeroen Massar wrote:


Max Larson Henry wrote:



has someone experience in anycast ipv4 networks (to support DNS)?


   "Never been done" "Dangerous" "TCP does not work" etc etc etc.


- Yes but as for DNS, anycast is essentially used for user requests
(UDP) not to perform zone transfer(TCP).


Also that would work, unless you have a very unstable routing table  
that

makes the node swap all the time.


It doesn't require an unstable routing table.  There is a small set of
locations that could hit routers with multipath that may "balance"
the anycast packets down divergent paths.

Essentially, these are the topological midpoints between any two
(or more) anycast servers.

Owen

Re: IPv4 ANYCAST setup

[Joe Abley]

On 2010-03-26, at 06:40, Max Larson Henry wrote:

>>> has someone experience in anycast ipv4 networks (to support DNS)?
>> 
>> "Never been done" "Dangerous" "TCP does not work" etc etc etc.
> 
> - Yes but as for DNS, anycast is essentially used for user requests (UDP)
> not to perform zone transfer(TCP).

As others have mentioned, TCP can generally be used for any DNS query, not just 
AXFR.

This becomes more important as DNS responses get bigger, e.g. responses from 
root servers due to the root zone containing DNSSEC information, see 
.

If your nameserver can't be reached over TCP, it's likely that there are people 
who can't talk to your nameserver. This means your DNS records can't be found. 
This is a bad thing.

Here, in glorious LOLCAPS:

  ALWAYS MAKE SURE YOUR DNS SERVER CAN BE REACHED OVER TCP
  TCP IS NOT JUST FOR ZONE TRANSFERS
  FIX YOUR FIREWALLS

:-)


Joe

Re: IPv4 ANYCAST setup

[Owen DeLong]

On Mar 26, 2010, at 6:40 AM, Max Larson Henry wrote:


has someone experience in anycast ipv4 networks (to support DNS)?


"Never been done" "Dangerous" "TCP does not work" etc etc etc.



- Yes but as for DNS, anycast is essentially used for user requests  
(UDP)

not to perform zone transfer(TCP).

-M


The number of DNS queries for user requests that are in UDP in IPv4
is nearly all.  When you start seeing hosts with more than a couple
of  records, you will start seeing more user requests in TCP.

FWIW, World of Warcraft authentication actually involves some hosts
with enough A records to require TCP.

Owen

Re: IPv4 ANYCAST setup

[Joe Abley]

On 2010-03-26, at 06:21, InterNetX - Lutz Muehlig wrote:

> has someone experience in anycast ipv4 networks (to support DNS)?

This is a general reference that tries hard not to be DNS-specific:

  http://www.ietf.org/rfc/rfc4786.txt

These are two papers written whilst at ISC describing many aspects of how ISC 
did what you are talking about with the F root nameserver:

  http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt
  http://ftp.isc.org/isc/pubs/tn/isc-tn-2004-1.txt

This is a rendering of the OSPF/IGP anycast tech note above as a USENIX paper:

  http://www.usenix.org/events/usenix04/tech/sigs/full_papers/abley/abley.pdf

This is a more sarcastic article about anycast that was published in the USENIX 
publication ;login:

  http://www.usenix.org/publications/login/2008-02/openpdfs/abley.pdf

This is a presentation about building nameserver clusters that was presented at 
NANOG 34:

  http://nanog.org/meetings/nanog34/presentations/abley.nameservers.pdf


Joe

Re: "Is TDM going the way of dial-up?"

[Michael Sokolov]

Rick Ernst  wrote:

> I've noticed over the last 3 years or so that TDM, specifically T-1, access
> and transport has been in a steady decline.  Customers are moving to FTTH
> and cable, or going WiMAX and Metro-Ethernet.  Ethernet seems to have taken
> an even bigger bite out of DS-3.  The bigger pipes seem to favor ethernet. A
> recent upgrade from OC-3 to GigE transport actually saved us a large chunk
> of money.
>
> I'm wondering if others are seeing the same behavior, if it's
> market-dependant, or if I'm just imagining things.

Unfortunately what you are seeing is indeed where the world is going,
and it is extremely painful to watch.  My personal preference is the
direct opposite of that: Ethernet for non-LAN use is my very antithesis,
I hate it to the core of my being.  V.35/HDLC forever for me!  I will
continue using HDLC over traditional synchronous serial WAN media for as
long as I am alive.

MS

P.S. This message is being sent from a VAX running a variant of 4.3BSD
(Quasijarus).  Almost the entire ARPA Internet software stack that's
running on my VAXen is mostly unchanged from how it was in 1988.

Re: IPv4 ANYCAST setup

[Mark Andrews]

In message <4828.1269611...@localhost>, valdis.kletni...@vt.edu writes:
> --==_Exmh_1269611568_4209P
> Content-Type: text/plain; charset=us-ascii
> 
> On Fri, 26 Mar 2010 09:40:39 EDT, Max Larson Henry said:
> 
> > - Yes but as for DNS, anycast is essentially used for user requests (UDP)
> > not to perform zone transfer(TCP).
> 
> DNS uses TCP for more than just XFR.  For instance, if you're running a
> resolver that doesn't do EDNS0, and you hit an (increasingly common) DNSSEC
> signed reply, it's going to be over 512 bytes and the lack of EDNS0 will
> cause it to re-ask via TCP.

DNSSEC depends on EDNS and DO being set in the EDNS OPT record, so
won't get DNSSEC records, except in response to * queries, for non
EDNS queries.
 
> Just mentioning it because the sort of sites that think TCP==XFR are the
> sort most likely to be running firewalls that munch the EDNS0 bits, and
> are setting themselves up for big surprises in the very near future.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: "Is TDM going the way of dial-up?"

[Frank A. Coluccio]

   Apologies for the gibberish of my previous message.
   Here's The URL that never made it to the list that contains the article
   I referenced and my footer note:
   [1]http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512
   --- fr...@fttx.org wrote:
   From: "Frank A. Coluccio" 
   To: "Michael Thomas" 
   Cc: nanog@nanog.org
   Subject: Re: "Is TDM going the way of dial-up?"
   Date: Fri, 26 Mar 2010 09:10:37 -0700
 re: "what is the state of voip-over-cellular as essentially the last
 holdout
 of TDM? Will the new 4G stuff be able to support latencies, etc? Has
 the
 work on handovers-over-IP matured enough that it's viable?"
 One of the biggest hurdles in bringing Ethernet to mobile/cellular
   apps
 has been its lack of synchronous capabilities. This is now being
 overcome
 in a variety of ways, both IETF-instigated and at IEEE, and through
 some
 proprietary solutions where vendors are re-introducing system
   clocking.
 See
 my footer note  that addresses this subject at the bottom of
 [1]this message.
 --- m...@mtcc.com wrote:
 From: Michael Thomas 
 To: Steve Meuse 
 Cc: nanog@nanog.org
 Subject: Re: "Is TDM going the way of dial-up?"
 Date: Fri, 26 Mar 2010 08:33:38 -0700
 On 03/26/2010 08:26 AM, Steve Meuse wrote:
 > Rick Ernst expunged (na...@shreddedmail.com):
 >
 >> I'm wondering if others are seeing the same behavior, if it's
 >> market-dependant, or if I'm just imagining things.  I'm working on
 building
 >> new infrastructure and my current thoughts are to minimize my TDM
 >> footprint.  It would be useful to get a better feel if this is an
 overall
 >> trend or something local.
 >
 > You aren't imagining things. In fact, some large national networks
 have been designed to support solely ethernet. It comes down to cost,
 as always
 Speaking of which, what is the state of voip-over-cellular as
 essentially the
 last holdout of TDM? Will the new 4G stuff be able to support
 latencies, etc?
 Has the work on handovers-over-IP matured enough that it's viable?
 Mike
   References
 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512

References

   1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512

Re: Call for papers (Deadline Extended): ISP-10, USA, July 2010

[Bill Fehring]

On Fri, Mar 26, 2010 at 09:03, J.D. Falk  wrote:
> Why is this fake conference still posting to NANOG?

Maybe a motivational speaker at one of his past "conferences" told him
never to give up?

-Bill

Re: "Is TDM going the way of dial-up?"

[Frank A. Coluccio]

   re: "what is the state of voip-over-cellular as essentially the last
   holdout
   of TDM? Will the new 4G stuff be able to support latencies, etc? Has
   the
   work on handovers-over-IP matured enough that it's viable?"
   One of the biggest hurdles in bringing Ethernet to mobile/cellular apps
   has been its lack of synchronous capabilities. This is now being
   overcome
   in a variety of ways, both IETF-instigated and at IEEE, and through
   some
   proprietary solutions where vendors are re-introducing system clocking.
   See
   my footer note  that addresses this subject at the bottom of
   [1]this message.
   --- m...@mtcc.com wrote:
   From: Michael Thomas 
   To: Steve Meuse 
   Cc: nanog@nanog.org
   Subject: Re: "Is TDM going the way of dial-up?"
   Date: Fri, 26 Mar 2010 08:33:38 -0700
   On 03/26/2010 08:26 AM, Steve Meuse wrote:
   > Rick Ernst expunged (na...@shreddedmail.com):
   >
   >> I'm wondering if others are seeing the same behavior, if it's
   >> market-dependant, or if I'm just imagining things.  I'm working on
   building
   >> new infrastructure and my current thoughts are to minimize my TDM
   >> footprint.  It would be useful to get a better feel if this is an
   overall
   >> trend or something local.
   >
   > You aren't imagining things. In fact, some large national networks
   have been designed to support solely ethernet. It comes down to cost,
   as always
   Speaking of which, what is the state of voip-over-cellular as
   essentially the
   last holdout of TDM? Will the new 4G stuff be able to support
   latencies, etc?
   Has the work on handovers-over-IP matured enough that it's viable?
   Mike

References

   1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512

Re: "Is TDM going the way of dial-up?"

[Jared Mauch]

On Mar 26, 2010, at 11:44 AM, Olsen, Jason wrote:

>> From: Rick Ernst [mailto:na...@shreddedmail.com]
> 
> 
>> an even bigger bite out of DS-3.  The bigger pipes seem to favor
>> ethernet. A recent upgrade from OC-3 to GigE transport actually saved
> us a large
>> chunk of money.
> 
> We recently had exactly the opposite experience, unfortunately.  During
> relocation of our datacenter we asked our MPLS WAN provider to provide
> GigE transport rather than the multiple OC-3s we were using today. To us
> it seemed like it would be cheaper - GigE interfaces, even WAN-PHY rated
> ones, were orders of magnitude cheaper than SONET.  Unfortunately the
> provider came back with absolutely outrageous costs for the port,
> claiming they had to do non-standard agreements with incumbents to
> provide the lines to us (despite the amount of circuits already in the
> site).
> 
> This may be more a function of that particular provider, however.

What I've been hearing rumors of is ---

unregulated services (eg: gigaman, opteman) typically have a better price-point 
if you are going with the carrier of choice.

TDM services (DSn/OCn) where there is a standard interconnection method tend to 
have higher costs than ethernet services, but are available when you have 
multiple carriers involved. (eg: VZ/MCI/XO/QWEST to SBC/ATT) territory.

I see this as a two-fold issue, one, the carriers (ATT) are trying to provide 
an incentive for shifting away from the TDM based services.  At the same time, 
it's more difficult to deliver service if you're not building to the market.

I would take into account the filing that ATT gave to the FCC recently asking 
to set a sunset date for their POTS (read: TDM) network elements.  This will 
allow them to leave the markets that are unprofitable, while delivering the 
unregulated (ethernet/IP) services where it currently is profitable.

- Jared

Re: Call for papers (Deadline Extended): ISP-10, USA, July 2010

[J.D. Falk]

On Mar 26, 2010, at 6:38 AM, Rich Kulawiec wrote:

> This is the same fake conference spammer who's been hitting a lot
> of mailing lists and Usenet newsgroups -- best to blacklist the
> sender address and the domain.

Why is this fake conference still posting to NANOG?

--
J.D. Falk 
Return Path Inc

Re: IP4 Space

[Lamar Owen]

On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote:
> On 3/10/2010 16:57, Owen DeLong wrote:
> > The target really needs to be the CxOs and the management,
> > especially in places where there is content facing the general
> > public.  Fortunately, Google, Yahoo, Netflix, etc. get it and have
> > moved forward with IPv6. Some others are coming along.

> True.  CxOs can basically order it to be done.  

Fascinating thread; thanks to all for the many insights found here; this 
thread has made my personal archive, just like the other long one did.  I've 
chosen to reply to this post, because it directly addresses me, in addition to 
the other two topical posts I just couldn't resist.

So, let me give the insight from the CIO point of view, at least in terms of a 
non-profit organization.  How do I know this PoV?  I _am_ the CIO here, that's 
how.  Here's my hypothetical reaction to a hypothetical network engineer 
coming to me with a good, solid, thorough, and compelling presentation on why 
we need to go to IPv6:

"Hey, great presentation.  Compelling arguments.  But I have one question: 
will our existing gear that's not yet fully depreciated handle it?  No? Sorry, 
won't happen.  Not in this recession year; grants have been tight, and nobody 
wants to fund this kind of capex right now.  Especially not since it hasn't 
yet been five years since that previous grant bought some of that equipment.  
No, we cannot afford to forklift upgrade now.  Do whatever you can with what we 
have.  Or, if we absolutely must upgrade, find the money in the bandwidth 
budget, and reduce our bandwidth if you have to do so.   Oh, and one other 
thing: is our ISP supporting this IPv6 thing yet?  No?  Come back when they 
do, and when you figure out how to do this with our existing equipment, or find 
the money in the existing budget.  If you'll excuse me, I have a meeting with 
the head of the server group, who says he needs funds for upgrading our server 
farm to something called vSphere 4.  Says he can save us a couple of grand per 
month in power and cooling costs, and has a plan to use the savings to upgrade 
our website to something more interactive for our core stakeholders."

Fact: many, if not most, businesses today are struggling to do basic things, 
at least in my area.  IPv6 migration for many businesses is a desirable, not 
an essential, thing to do, at least right now, and especially if serious capex 
is required to do it.  For some businesses, IPv6 addition is more of an 
annoyance than a desirable.  So, many businesses, in today's economic climate, 
will be dragged into IPv6 kicking and screaming simply because it's going to 
be, in their eyes, dead cost.  Unless there is either a significant value-add 
or cost reduction in the mid to long term, that is.  Having more addresses is 
not enough.  And thus, ISP's which serve those businesses really don't have 
sufficient economic reason to expend their own capex budgets down to the bone 
if 
the demand from their customers is low.  

At the CxO level, it's all about the money.  Or the lack therof.

In our case, yes, we're going to add IPv6 when it makes cents to do so.  
Misspelling intentional; but I do have a plan in place to roll it out quickly 
when needed, in no small part thanks to threads on NANOG and Cisco-NSP.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute

Re: "Is TDM going the way of dial-up?"

[Steve Meuse]

Dylan Ebner expunged (dylan.eb...@crlmed.com):

> Funny thing about this is we have been steadily getting rid of all of our t1 
> and ds3 circuits and replacing them with metro-e or cable based services at 
> much better price/Mbs. However, when we went to VOIP and wanted to do sip 
> trunking with qwest, they needed to deliver this over t1, otherwise is wasn't 
> cost effective.


E911 was a sticky point for us. We ended up having to install some small boxes 
to do T1 handoff to our provider of choice, they didn't have any ethernet 
options (which we pushed for). 


-Steve

RE: "Is TDM going the way of dial-up?"

[Olsen, Jason]

> From: Rick Ernst [mailto:na...@shreddedmail.com]


> an even bigger bite out of DS-3.  The bigger pipes seem to favor
> ethernet. A recent upgrade from OC-3 to GigE transport actually saved
us a large
> chunk of money.

We recently had exactly the opposite experience, unfortunately.  During
relocation of our datacenter we asked our MPLS WAN provider to provide
GigE transport rather than the multiple OC-3s we were using today. To us
it seemed like it would be cheaper - GigE interfaces, even WAN-PHY rated
ones, were orders of magnitude cheaper than SONET.  Unfortunately the
provider came back with absolutely outrageous costs for the port,
claiming they had to do non-standard agreements with incumbents to
provide the lines to us (despite the amount of circuits already in the
site).

This may be more a function of that particular provider, however.

[OT] Old kit (was:Re: IP4 Space)

[Lamar Owen]

On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote:
> For comparison look at the z-80 CPU which powered the early desktop
> computers. When the IBM PC came out, people thought that the Intel 8086
> would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared
> into all sorts of electronic
> devices where it serves as a controller for some function, perhaps the
> video display or the disk drive servos. And you can still buy them.

Lots of DVD drives use embedded Z80's as controllers, including the dual-layer 
drive in my laptop.  Never thought that my teenage years spent hacking Z80 
machine code on a TRS-80 could produce a currently marketable skill 

Quick, Z80 joke coming Addr: :21 00 00 01 FF FF 11 01 00 ED 
B0...Will it finish?  

Same is true of MIPS and PowerPC, though.  There are far more MIPS chips in 
routers than ever saw desktop use in SGI workstations; and while it might take 
a little while for Cisco's PowerPC driven routers' CPU's to outnumber all the 
PowerMacs our there, one day it will happen.

And then all those PowerMac assembly language gurus might prove useful in the 
router side of the house.

RE: "Is TDM going the way of dial-up?"

[Dylan Ebner]

Funny thing about this is we have been steadily getting rid of all of our t1 
and ds3 circuits and replacing them with metro-e or cable based services at 
much better price/Mbs. However, when we went to VOIP and wanted to do sip 
trunking with qwest, they needed to deliver this over t1, otherwise is wasn't 
cost effective.

Dylan Ebner

-Original Message-
From: Rick Ernst [mailto:na...@shreddedmail.com] 
Sent: Friday, March 26, 2010 10:16 AM
To: nanog@nanog.org
Subject: "Is TDM going the way of dial-up?"

I've noticed over the last 3 years or so that TDM, specifically T-1, access
and transport has been in a steady decline.  Customers are moving to FTTH
and cable, or going WiMAX and Metro-Ethernet.  Ethernet seems to have taken
an even bigger bite out of DS-3.  The bigger pipes seem to favor ethernet. A
recent upgrade from OC-3 to GigE transport actually saved us a large chunk
of money.

I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.

Thoughts?

Thanks,

Re: "Is TDM going the way of dial-up?"

[joel jaeggli]

On 3/26/2010 8:15 AM, Rick Ernst wrote:

I've noticed over the last 3 years or so that TDM, specifically T-1, access
and transport has been in a steady decline.  Customers are moving to FTTH
and cable, or going WiMAX and Metro-Ethernet.  Ethernet seems to have taken
an even bigger bite out of DS-3.  The bigger pipes seem to favor ethernet. A
recent upgrade from OC-3 to GigE transport actually saved us a large chunk
of money.

I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.
   


Why I think it comes down to is do you want to use frame-relay, atm, sdh 
and ethernet when you can just use ethernet?


lan-phy ethernet has economies of scale that result in lower cost along 
virtually every dimension relative to the alternatives.



Thoughts?

Thanks,

   

Re: "Is TDM going the way of dial-up?"

[Justin M. Streiner]

On Fri, 26 Mar 2010, Rick Ernst wrote:


I've noticed over the last 3 years or so that TDM, specifically T-1, access
and transport has been in a steady decline.  Customers are moving to FTTH
and cable, or going WiMAX and Metro-Ethernet.  Ethernet seems to have taken
an even bigger bite out of DS-3.  The bigger pipes seem to favor ethernet. A
recent upgrade from OC-3 to GigE transport actually saved us a large chunk
of money.

I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.


I tend to think this is market dependent.  In major population centers, 
TDM service may well be on the decline, but I'd suspect that Ethernet 
based services have a much lower penetration in areas with lower 
population densities.


I don't see TDM going away entirely any time soon because it still comes 
in handy for things like out-of-band management, etc, plus nowadays there 
is lots of TDM gear on the secondary market that can be picked up 
dirt-cheap.


jms

Re: "Is TDM going the way of dial-up?"

[Bret Clark]

   Steve Meuse wrote:

I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.


You aren't imagining things. In fact, some large national networks have been des
igned to support solely ethernet. It comes down to cost, as always


-Steve



   Actually, a lot of people would be shocked at just how much VoIP is now
   used to transport voice with TDM only occurring at the last mile and in
   many cases at the last foot. Anyone designing a voice infrastructure
   would be best to design it for VoIP. Your ROI is much much greater. If
   you need to use TDM, then do so only at the edge as close to the TDM
   equipment as possible.
   Of course if you are going to use VoIP through-out an infrastructure it
   certainly is a good idea to get familiar with QoS provisioning.
   Bret

Re: "Is TDM going the way of dial-up?"

[Michael Thomas]

On 03/26/2010 08:26 AM, Steve Meuse wrote:

Rick Ernst expunged (na...@shreddedmail.com):


I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.


You aren't imagining things. In fact, some large national networks have been 
designed to support solely ethernet. It comes down to cost, as always


Speaking of which, what is the state of voip-over-cellular as essentially the
last holdout of TDM? Will the new 4G stuff be able to support latencies, etc?
Has the work on handovers-over-IP matured enough that it's viable?

Mike

Re: "Is TDM going the way of dial-up?"

[Michael Thomas]

On 03/26/2010 08:26 AM, Steve Meuse wrote:

Rick Ernst expunged (na...@shreddedmail.com):


I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.


You aren't imagining things. In fact, some large national networks have been 
designed to support solely ethernet. It comes down to cost, as always


Speaking of which, what is the state of voip-over-cellular as essentially the
last holdout of TDM? Will the new 4G stuff be able to support latencies, etc?
Has the work on handovers-over-IP matured enough that it's viable?

Mike

Re: "Is TDM going the way of dial-up?"

[Steve Meuse]

Rick Ernst expunged (na...@shreddedmail.com):

> I'm wondering if others are seeing the same behavior, if it's
> market-dependant, or if I'm just imagining things.  I'm working on building
> new infrastructure and my current thoughts are to minimize my TDM
> footprint.  It would be useful to get a better feel if this is an overall
> trend or something local.

You aren't imagining things. In fact, some large national networks have been 
designed to support solely ethernet. It comes down to cost, as always 


-Steve

"Is TDM going the way of dial-up?"

[Rick Ernst]

I've noticed over the last 3 years or so that TDM, specifically T-1, access
and transport has been in a steady decline.  Customers are moving to FTTH
and cable, or going WiMAX and Metro-Ethernet.  Ethernet seems to have taken
an even bigger bite out of DS-3.  The bigger pipes seem to favor ethernet. A
recent upgrade from OC-3 to GigE transport actually saved us a large chunk
of money.

I'm wondering if others are seeing the same behavior, if it's
market-dependant, or if I'm just imagining things.  I'm working on building
new infrastructure and my current thoughts are to minimize my TDM
footprint.  It would be useful to get a better feel if this is an overall
trend or something local.

Thoughts?

Thanks,

Re: IP4 Space

[Lamar Owen]

On Tuesday 23 March 2010 10:59:31 pm Mark Newton wrote:
> How many 10 year old pieces of kit do you have on your network?

90% of the network equipment here is over ten years old, and still trucking.  
No plans to replace what is still working, as long as we have spares in stock, 
and until we get grants to pay for replacements.

No compelling reasons for the capex on replacing 75% of that over ten year old 
equipment, either, as long as it still works and isn't too insecure to use.  

Re: IPv4 ANYCAST setup

[Florian Weimer]

* Jeroen Massar:

> Simple recipe:
>  - Box with:
>- Your favourite OS
>- Quagga or OpenBGPd
>- Your favourite DNS server
>  - Announce the IP of the anycast node in BGP
>  - Monitor the DNS server, when it does not work kill your local BGPd
>and notify the admins that it broke

This is fine if you just use BGP to indirectly hook into your IGP.
For global anycast, you need a sufficiently short prefix with no
non-anycast services on it.  This can be difficult to justify for
newcomers.

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: IPv4 ANYCAST setup

[Jeroen Massar]

Max Larson Henry wrote:
> 
> > has someone experience in anycast ipv4 networks (to support DNS)?
> 
> "Never been done" "Dangerous" "TCP does not work" etc etc etc.
> 
> 
> - Yes but as for DNS, anycast is essentially used for user requests
> (UDP) not to perform zone transfer(TCP).

Also that would work, unless you have a very unstable routing table that
makes the node swap all the time.

Please also note that if a DNS answer does not fit inside a a UDP packet
(default 512, MTU with EDNS0) that the fallback is TCP mode...

John Payne wrote:
[..]
> Can't really tell if you're being serious here due to caffeine
> underrun.

As it is already almost 15:00 in Europe (and it is a friday), take a
guess ;) Also note the next line I wrote and the point to the google,
which you now have done for the person, who probably is also having a
lazy friday afternoon ;)

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature

Re: IPv4 ANYCAST setup

[Valdis . Kletnieks]

On Fri, 26 Mar 2010 09:40:39 EDT, Max Larson Henry said:

> - Yes but as for DNS, anycast is essentially used for user requests (UDP)
> not to perform zone transfer(TCP).

DNS uses TCP for more than just XFR.  For instance, if you're running a
resolver that doesn't do EDNS0, and you hit an (increasingly common) DNSSEC
signed reply, it's going to be over 512 bytes and the lack of EDNS0 will
cause it to re-ask via TCP.

Just mentioning it because the sort of sites that think TCP==XFR are the
sort most likely to be running firewalls that munch the EDNS0 bits, and
are setting themselves up for big surprises in the very near future.


pgpmOrfomH4mr.pgp
Description: PGP signature

RE: IPv4 ANYCAST setup

[Paul Ryland]

> > > has someone experience in anycast ipv4 networks (to support DNS)?
> >
> > "Never been done" "Dangerous" "TCP does not work" etc etc etc.
> 
> - Yes but as for DNS, anycast is essentially used for user requests (UDP)
> not to perform zone transfer(TCP).

How-to with working configurations for Linux+Quagga:



Further information is found in RFC3258:



Remember to disable PMTU discovery on your DNS servers if you are using this.


Paul

Re: IPv4 ANYCAST setup

[John Payne]

On Mar 26, 2010, at 9:24 AM, Jeroen Massar wrote:

> InterNetX - Lutz Muehlig wrote:
>> Hello,
>> 
>> has someone experience in anycast ipv4 networks (to support DNS)?
> 
> "Never been done" "Dangerous" "TCP does not work" etc etc etc.

Can't really tell if you're being serious here due to caffeine underrun.
http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf  
Slide 23 seems quite appropriate.

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-anycast.pdf
has links to other work on this.

It certainly seems to work "well enough".

> 
> I assume quite a number of people know how to do it, especially as
> several root DNS servers abuse it.
> 
> Simple recipe:
> - Box with:
>   - Your favourite OS
>   - Quagga or OpenBGPd
>   - Your favourite DNS server
> - Announce the IP of the anycast node in BGP
> - Monitor the DNS server, when it does not work kill your local BGPd
>   and notify the admins that it broke
> 
> That is it. Probably with the above couple of things, google a bit and
> find the rest.
> 
> Greets,
> Jeroen
> 

Re: NTP clock source

[Lamar Owen]

On Thursday 25 March 2010 12:46:23 pm Marty Anstey wrote:
> If you are of the DIY persuasion, check out the following project:

> http://www.febo.com/pages/soekris/

And if the OP (or any one else on list) is of that persuasion, and really 
wants to get into serious timing discussions, joining the time-nuts mailing 
list at febo.com would be a good idea.

And if Stratum 0 is a requirement, then looking at the time-nuts archives at 
least would be good preparation for running a real Stratum 0 time source.

Re: IPv4 ANYCAST setup

[Max Larson Henry]

> > has someone experience in anycast ipv4 networks (to support DNS)?
>
> "Never been done" "Dangerous" "TCP does not work" etc etc etc.
>

- Yes but as for DNS, anycast is essentially used for user requests (UDP)
not to perform zone transfer(TCP).

-M

Re: Call for papers (Deadline Extended): ISP-10, USA, July 2010

[Rich Kulawiec]

This is the same fake conference spammer who's been hitting a lot
of mailing lists and Usenet newsgroups -- best to blacklist the
sender address and the domain.

---Rsk

Re: IPv4 ANYCAST setup

[Jeroen Massar]

InterNetX - Lutz Muehlig wrote:
> Hello,
> 
> has someone experience in anycast ipv4 networks (to support DNS)?

"Never been done" "Dangerous" "TCP does not work" etc etc etc.

I assume quite a number of people know how to do it, especially as
several root DNS servers abuse it.

Simple recipe:
 - Box with:
   - Your favourite OS
   - Quagga or OpenBGPd
   - Your favourite DNS server
 - Announce the IP of the anycast node in BGP
 - Monitor the DNS server, when it does not work kill your local BGPd
   and notify the admins that it broke

That is it. Probably with the above couple of things, google a bit and
find the rest.

Greets,
 Jeroen



signature.asc
Description: OpenPGP digital signature

IPv4 ANYCAST setup

[InterNetX - Lutz Muehlig]

Hello,

has someone experience in anycast ipv4 networks (to support DNS)?


Regards
Lutz