We have considered the options carefully and decided to announce a
covering /23 to get around the problem spotted by Randy and the folks in
Oregon. We considered the /24+/25 soloution but decided against that
because it makes little sense when we are considering to eventually
remove as much of th
> Maybe I'm missing something, but the core issue is that the NO-
> EXPORT'ed anycast instance has a higher localpref inside the AS it's
> being advertised to, and as such supressing the non-NO_EXPORT'ed
> prefix. The "exportable" prefix gets suppressed at a point on the
> network such that
Maybe I'm missing something, but the core issue is that the NO-
EXPORT'ed anycast instance has a higher localpref inside the AS it's
being advertised to, and as such supressing the non-NO_EXPORT'ed
prefix. The "exportable" prefix gets suppressed at a point on the
network such that the peer
> Is it an idea to have anycasted instances using NO_EXPORT
> announce /25's instead of /24's?
many many folk filter on /24, so the /25 would not be seen.
> Another possibility is for $LARGE_ISP to localpref the
> NO_EXPORTED down to $LOW value
and then how will the down-preffed prefix be seen
On Mon, Oct 31, 2005 at 12:19:58PM -1000, Randy Bush wrote:
Hi,
> this implies that a non-trivial part of the net can not see
> anycast services for which some of the servers are marking
> their announcements as NO_EXPORT.
Is it an idea to have anycasted instances using NO_EXPORT announce /25's
fwiw, i have just added
and if you choose to work for some enterprise clueless enough to
think that they can force this silliness on the world, use gmail,
hotmail, ...
to my anti-legal notice
randy
Sam Crooks wrote:
One of those pesky legal notice on all my outgoing email gets filtered
by Randy's mail ... (the outgoing addition is not under my control)
maybe someone could tell him for me (as I can't email him...)
>you have sent a message to me which seems to contain a legal
>w
One of those pesky legal notice on all my outgoing email gets filtered by Randy's mail ... (the outgoing addition is not under my control) maybe someone could tell him for me (as I can't email him...)
>you have sent a message to me which seems to contain a legal
>warning on who can read i
On Tue, 1 Nov 2005, Sam Crooks wrote:
> Pardon my stupidity, but could someone point to a good explanation of
> Anycast (vs uni, broad and multi...)?
Well, it's not a _good_ explanation, since it's mostly visuals intended to
accompany a talk, but:
http://www.pch.net/resources/tuto
rfc 1546 is a good start
i did not see sam's original query and he's not in my .procmailrc
wonder why
randy
On Tue, 1 Nov 2005, Stephen J. Wilcox wrote:
> ok sure, but is this not just normal transit issues, these are not
special
> because they are a) anycast b) root-servers?
Correct.
> if any networks peers leak they
> should be reprimanded
Well, I might phrase that in a di
On 1-Nov-2005, at 17:52, Etaoin Shrdlu wrote:
Sam Crooks wrote:
Pardon my stupidity, but could someone point to a good explanation of
Anycast (vs uni, broad and multi...)?
{mutter, mumble, google is your friend}
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=anycast+definition
Also
Sam Crooks wrote:
>
> Pardon my stupidity, but could someone point to a good explanation of
> Anycast (vs uni, broad and multi...)?
{mutter, mumble, google is your friend}
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=anycast+definition
--
There are two ways, my friend, that you can be ri
On 1-Nov-2005, at 15:15, Stephen J. Wilcox wrote:
ok sure, but is this not just normal transit issues, these are not
special
because they are a) anycast b) root-servers?
You're right -- these are normal issues that any multi-homed AS might
see. The effectiveness of knuckle-rapping after
Pardon my stupidity, but could someone point to a good explanation of
Anycast (vs uni, broad and multi...)?
>
>
>
> On Tue, 2005-11-01 at 10:48 -0800, Steve Gibbard and a variety of
> others wrote about anycast issues:
>
CONFIDENTIALITY NOTICE:
This message, and any attachments, are intende
> Here's what we do on the PCH anycast network
steve:
could you tell us more about the pch anycast network so we
can take a look at how its prefixes propagate?
randy
> ok sure, but is this not just normal transit issues, these are
> not special because they are a) anycast b) root-servers? if any
> networks peers leak they should be reprimanded
rofl!
thanks, i needed a good laugh
randy
> Contrary to popular belief, leaks through peers in remote regions do
> not always result in huge AS_PATHs which are never selected by the
> rest of the network. For example, some of the most remote and poorly-
> connected ISPs that F is announced to from local nodes are transit
> customer
On Tue, 1 Nov 2005, Joe Abley wrote:
> On 1-Nov-2005, at 14:19, Stephen J. Wilcox wrote:
>
> > or am i naive too?
>
> I think you underestimate the tendencies of ISPs all over the world
> to leak peering routes towards their transit providers.
>
> Contrary to popular belief, leaks through pe
On 1-Nov-2005, at 14:19, Stephen J. Wilcox wrote:
or am i naive too?
I think you underestimate the tendencies of ISPs all over the world
to leak peering routes towards their transit providers.
Contrary to popular belief, leaks through peers in remote regions do
not always result in hug
On Tue, 1 Nov 2005, Randy Bush wrote:
> my naive view of your current deployment means that k can not
> be seen from any multi-homed sites unless one or more of their
> upstreams (recurse for tier-n) is even more clever and
> implements "t0 is our customer and we ignore NO_EXPORT toward
> custome
On Tue, 1 Nov 2005, Daniel Karrenberg wrote:
We are considering to add a covering prefix announced from global nodes
relatively quickly. This should solve the particular problem and we
cannot (yet) see any problems it would create. But this is more complex
than the current state and thus bring
On 01.11 05:41, Randy Bush wrote:
> mornin' daniel:
ev'nin randy:
Of course the NCC takes resposibility for the K anycast deployment
including the way we announce BGP routes to K. We also clearly describe
and announce what we do. We cannot take responsibility for what others
do with that routin
mornin' daniel:
> You also describe the rationale correctly by saying "it would
> be good if a server in Kenya did not take load from nyc".
> I'll expand a little more on that. K does anycast with two
> objectives: primarily to increase robustness of the service
> in the face of serious load inc
Randy's description of the issue with NO_EXPORT is correct.
It has never appeared to be particularly widespread.
It is not specific to anycast.
You also describe the rationale correctly by saying "it would be good if
a server in Kenya did not take load from nyc". I'll expand a little
more on th
On 31-Oct-2005, at 17:49, Bill Woodcock wrote:
Which leaves the question of why F, and now K, appear to be trying
to do
it.
F's covering prefix, 192.5.5.0/24, is advertised to peers of F-root
local nodes with NO_EXPORT. 192.5.5.0/24 is advertised to peers of AS
3557 without NO_EXPORT.
On Mon, 31 Oct 2005, Joe Maimon wrote:
> Isnt this the standard problem?
Correct.
> Why does anycast have any special bearing on the problem?
It doesn't, except that Vixie decided to do it anyway with F, and it
sounds like now K is doing it as well.
I have no clue why. The pro
Randy Bush wrote:
so a few of us are still looking at routing through the anycast
sunglasses. a particular probe is seeing instability [0] for
k.root-servers.net [1]. so we hop on to a router nearby, and
o this obscures their path to k1
o and, as they obey k0's NO_EXPORT, they can
so a few of us are still looking at routing through the anycast
sunglasses. a particular probe is seeing instability [0] for
k.root-servers.net [1]. so we hop on to a router nearby, and
have some fun looking at things. we discover an anomaly which
takes a while to sort out
o some of the anyc
29 matches
Mail list logo
