Communities
E.B. Dreger
eddy+public+spam at noc.everquick.net
Tue Oct 16 19:08:44 UTC 2001
> Date: Tue, 16 Oct 2001 18:30:05 +0200
> From: Niels Bakker <niels=nanog at bakker.net>
> > 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
Correct. It edits the *ix kernel's FIB, adding and deleting
routes. However, Zebra running on a single machine can have
multiple BGP processes running... which is along the same lines.
> 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.
Interesting. I was unaware of this.
> >> 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).
Whoa! Where did I say spoofed packets? If 701 is one of your
upstreams or peers, then I can exchange traffic with 701 all day
long. I never indicated using improper source addresses. Please
reread my post.
me <--> you <--> 701
me <--> you <--> 1239
Both are valid.
> > 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
In your scenario. But this is arbitrary; it is not borne of
necessity due to the technology.
> enforces this via a contract both parties enter in and A (presumably)
> pays B for.
Let's say that I'm strictly a Web host. Inbound traffic is
negligible. I send any and all 701-bound traffic via you; any
and all other traffic goes through <some other upstreams>. No
complaint there -- and I can do this in your aforementioned
scheme.
Why do you balk at a community that says "I dislike 1239"[1],
thus _preferring_ 701, when I could simply route _all_ non-701
traffic over another one of my upstreams? IMHO, your dislike
of tuning is illogical... I can sway the balance _far_ more
with coarse-grained routing when you don't provide fine-grained
controls.
Not providing fine-grained tuning accomplishes nothing positive,
and can be a negative thing. Offering it provides benefit, and
is not difficult.[2]
[1] Reminder: Hypothetical example. Interpret accordingly. I
used 701 and 1239 in my original example, and don't care to
change the scenario.
[2] Yes, more maintenance with communities. But a few dozen is
all it takes to handle many ASen with a few different lengths...
both the initial effort and upkeep are negligible. Search the
archives for this discussion.
Eddy
---------------------------------------------------------------------------
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots. Do NOT
send mail to <blacklist at brics.com>, or you are likely to be blocked.
More information about the NANOG
mailing list