Date: Tue, 16 Oct 2001 18:30:05 +0200 From: Niels Bakker <niels=nanog@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@brics.com> To: blacklist@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@brics.com>, or you are likely to be blocked.