Communities
E.B. Dreger
eddy+public+spam at noc.everquick.net
Mon Oct 15 19:48:12 UTC 2001
> Date: Mon, 15 Oct 2001 19:56:02 +0200 (CEST)
> From: Iljitsch van Beijnum <iljitsch at muada.com>
(This is more like two messages in one... I'm posting as a
single message in sort of a "self digest" mode.)
[ snip ]
*** Message #1 ***
> I don't understand what you mean. Redistributing upstream
> routes where/into what? How can this be "despite" as-path
> length?
Hypothetical example with real names:
Let's say that I have transit from 6347 and 2914. Now let's say
that I'm stupid, and start advertising routes that I learn from
2914 into 6347, and that 6347 isn't filtering my as-paths or
netblocks. [Note: 6347 does know better in the real world.]
Now a customer ("Network X") of 6347 and 1239 will see 2914
netblocks via
6347 19358 2914
6347 { 701 | 1239 | 3561 } 2914
1239 2914
assuming that:
+ 1239/2914 directly connect
+ 6347/2914 do not directly connect
+ 6347 obtains transit to 2914 via 701, 1239, and 3561.
6347 learns 2914 routes from 701; 1239; 3561; and (wrongly) me,
19358... then chooses a best route to redistribute. Because 6347
sells transit to me, they'll give my routes higher local-pref
than their peers or upstreams. Thus, for any 2914 netblock, I
become the preferred egress from 6347. Problem #1.
Now lets say that Network X uses local-pref to penalize
_1239_.*_2914
Network X sees:
6347 19358 2914
1239 2914
Network X's local-pref policies in their route-maps makes the
latter one undesirable. Problem #2, and the [extreme] example
in my prior post.
Some old-timers help me out: IIRC, 3561 got blackholed in 1997
by bad BGP from another well-known network... but I don't want
to say more in case my memory is bad.
*** Message #2 ***
> Well, let me provide a real-world example. It's not really
> congestion, but close enough for these purposes.
>
> When Telehouse had problems in Manhattan after the attacks on
[ snip ]
> So a community that indicates "you don't want to use this route
> unless you absolutely have to--trust us" would have been very
> welcome. Such a community would be especially useful in the
> face of congestion:
I see and agree. Good idea, IMHO.
> But is it worth the trouble to try to "standardize" communities
> for this?
I should think that this would be trivial. 0x0000:* and 0xffff:*
are reserved per RFC1997... release a new RFC with your "you
don't want this route!" communities added, participants would
benefit, non-participants would observe no change, and there
would be no interoperability troubles.
I think I like this better than my prior geography-based post...
you're suggesting that MED-like info be advertised via standard
communities. And who would know better than the originating
provider? Makes sense to me...
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