North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: more-specifics via IX

  • From: John Payne
  • Date: Mon Oct 15 10:15:14 2007
  • Authentication-results: [email protected]; domainkeys=pass (testing)
  • Authentication-results:; dkim=pass (1024-bit key) [email protected]
  • Dkim-signature: v=1; a=rsa-sha1; c=simple/simple;; s=haybaler; t=1192457148; bh=nhE9cXq+pr5sSdZQY/Q1LZmRPUA=; h=In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc: Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=dUx76Of 3R9JXbevQ1axt4UDbOExd6nTPZecvyub2G/v2HHY4rt9FvGY0RXP6Lpi85lNgQWinXE cn+UQ5zwYdpxov9O7mS4VZy4VARLSAu8emORZEBUixhckqJW5WJbOFfYItGQ2NiccXl IP9aoxA+MUPaAMow8/DVVgibl5gBC0=
  • Domainkey-signature: a=rsa-sha1; s=haybaler;; c=nofws; q=dns; h=dkim-signature:in-reply-to:references:mime-version: content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=KG3Th2VQOldEZK9W2gsFIMD9x8i5IVbJTVtmiitD0vMkpPGnnnloEFZauMB0JVOq3 tLk6tn/Nj4qbU5ovpfq9MIirxxuRfcQEQV85PHYZ0lJhW5684h20aTQeq430gYV79rr 3FCHkn3/riYRFeeNyutBpGJEPqhOeThtvPnN+7w=

On Oct 15, 2007, at 9:48 AM, Mike Leber wrote:

On Mon, 15 Oct 2007, Bradley Urberg Carlson wrote:
I have a few customers' customers, who appear at a local IX.  Due to
the MLPA-like nature of the IX, I hear their prefixes both at the IX
and via my own transit customers.  I normally use localpref to prefer
customer advertisements over peers' advertisements.

There is a customer's customer who is advertising more-specifics at the
IX (and using a different source AS, to boot)

Time to time you will see this.

You could also hear the more specifics from another peer that is one of
their transit providers or you could hear them via one of your transit

I can think of a couple ways to prevent hearing these, but thought I
should ask for suggestions first.

You can do all kinds of things to other network's routes especially when
those routes aren't from your customers and what you are doing doesn't
break connectivity (or solves a capacity problem and improves
connectivity). However, if you tweak routes of a paying customer then you
will need to consider what your answer to your customer will be for
overriding their traffic engineering.

In this case it's his customer's customer... so no answer _necessary_ (as I've learnt from experience)