Communities

Tue Oct 16 16:30:05 UTC 2001

* eddy+public+spam at 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.