nanog mailing list archives

Re: Communities


From: Niels Bakker <niels=nanog () bakker net>
Date: Tue, 16 Oct 2001 18:30:05 +0200


* eddy+public+spam () noc everquick net (E.B. Dreger) [Tue 16 Oct 2001, 18:09 CEST]:
Let's say that I have a DS3 to 701 and a 4xDS1 to 7018.  I might
sell a DS1 to NetX, and advert their routes[1] to both upstreams.
If I sell a 15Mbps frac-DS3 to NetZ, I'd better use my 7018
connection for backup only on their routes.

In an ideal world.  Not sure how many networks engineer their external
connections so that each one equals the maximum amount of data sent out
on all of them, in case all except one fail...


In short, we start looking at multiple FIBs.  It's not really
that much more difficult; it's more of a scalability issue.  I
know that Zebra can run multiple router processes, but I've not
played with this feature... perhaps that's a start.

Zebra doesn't actually forward packets.  Ciscos with newer IOS can do
this (12.0T and onwards) with different VRFs.  I've seen companies who
have something like that in production; packets hit the same router a
few times in a row in a traceroute.


Or, if you want to get ugly, you could have your upstreams speak
multihop EBGP selectively with your downstreams. *ducking and
running*

The "less hassle" part of having a limited amount of upstream providers
to deal with certainly diminishes in this particular scenario, yes.


Frankly, if I were B I'm not sure I'd be all that happy with customers
influencing my routing decision process.  They hand me their packets
(or not); that should be it.
I disagree.  Let's say that you sell me transit, and purchase
yours from 701 and 1239.  Would you complain if I fill my pipe to
you with traffic to/from 701?  No.  If I fill it with traffic
to/from 1329?  No.

Yes, I would complain if you sent me packets with source addresses you
shouldn't be sourcing (i.e., not your own).  Traffic from 701 or 1239
should not pass you to reach me (if I were B and you customer A).


Why, then, would you complain if I set a community to _prefer_ 
701 over 1239 or vice-versa?  By giving your downstreams fine-
grained tuning, you allow them to tinker for a system that they
like... and you don't reach the extreme cases that are possible
even without fine-grained tuning.

This is about packets from the world via me to you, not from you to the
outside world.  The case you just described already exists; I wrote so
before (albeit in a bit broken English).

The only routing decision customer A can force upon B is "Send packets
destined for these netblocks <here's a BGP announcement> to me," and
enforces this via a contract both parties enter in and A (presumably)
pays B for.

Regards,


        -- Niels.


Current thread: