[c-nsp] BGP blackholling with communites

David Freedman david.freedman at uk.clara.net
Mon Mar 21 07:11:58 EST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Boehmer (oboehmer) wrote:
|>> On Mon, Mar 21, 2005 at 11:17:13AM +0000, David Freedman wrote:
|>>> I had assumed that it would bypass the "next-hop-self" action which
|>>> may be applied to the peering router's iBGP peers (countering the
|>>> ability to propogate the new next-hop around the network), there
|>>> are some mixed opinions about whether this should or should not
|>>> work to do this, (whether it actually works and is implemented is
|>>> another matter!)
|>>
|>> "Origin" has no influence on "next-hop-self" - it's only an
|>> attribute that will be used as a tie-breaker somewhere low in the
|>> BGP decision hierarchy.
|>>
|> Sure, but I would have hoped that cisco would have used some attribute
|> (this being the most sensible one) to decide on how to implement
|> next-hop-self.
|
| Why should we stop applying next-hop-self to routes marked with "origin
| IGP"? This would possibly break *many* customer configs..
|
No, I didn't say you should, I only said that if it were to be
implemented, it would be the most sensible attribute to choose.

| If "neighbor x.x.x.x next-hop-self" is not granular enough, just create
| a route-map and set the next-hop manually based on attributes of your
| choice (for instance "origin").
| Or you apply the same route-map inbound on all your iBGP sessions (as
| others suggested) or do it centrally on your RR's..
|

Then you spend extra CPU cycles with the additional processing of every
iBGP update (which, if you use iBGP to carry all your customer routes
could be interesting).

Also, the latter (inbound map) could be a bit vendor incompatible.


Dave.






| 	oli


- --
David Freedman
Network Engineering Department
Claranet UK Limited
http://www.clara.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCProDtFWeqpgEZrIRArXwAKCK0jnyDnkXSIsqamRqTpr76CFZVwCdF1D2
EtRz4aYNVtq32Z2i/3DWhyI=
=MD3d
-----END PGP SIGNATURE-----



More information about the cisco-nsp mailing list