IXP

Fri Apr 24 21:41:17 UTC 2009

In a message written on Fri, Apr 24, 2009 at 04:22:49PM -0500, Paul Wall wrote:
> On the twelfth day of Christmas, NYIIX gave to me,
>         Twelve peers in half-duplex,
>         Eleven OSPF hellos,
>         Ten proxy ARPs,
>         Nine CDP neighbors,
>         Eight defaulting peers,
>         Seven broadcast floods,
>         Six maintenances notices,
>         Five flapping sessions,
>         Four Foundry crashes,
>         Three routing leaks,
>         Two forwarding loops,
>         And a BPDU from someone's spanning tree.

Let's group:

Problems that can/will occur with per-vlan peering:
          Twelve peers in half-duplex,
          Six maintenances notices,
          Five flapping sessions,
          Four Foundry crashes,
          Three routing leaks,
          Two forwarding loops,

Problems that if they affect your equipment, you're configuring it wrong,
and can/will occur with per-vlan peering:
          Eleven OSPF hellos,
          Nine CDP neighbors,

Problems that if they affect the exchange, the exchange is configuring
their equipment wrong, and can/will ocurr with per-vlan peering:
          Two forwarding loops,
          And a BPDU from someone's spanning tree.

Problems unique to a shared layer 2 network:
          Eight defaulting peers,
          Seven broadcast floods,

Leaving aside the particular exchanges, I'm going to guess you are not
impressed by the technical tallent operating the exchange switches from
the tone of your message.  Do you believe making the configuration for
the exchange operation 100 times more complex will:
   A) Lead to more mistakes and down time.
   B) Lead to less mistakes and down time.
   C) Have no effect?

I'm going with A.  I also think the downtime from A, will be an
order of magnitude more down time than the result of defaulting
peers (which, generally results in no down time, just theft of
service), or broadcast floods.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090424/e2a32bf6/attachment.sig>