Danny McPherson <danny@tcb.net> writes:
> Setting NEXT_HOP to 'self' also affords you the ability
> to not carry external NEXT_HOPs if you chose, thereby
> alleviate the chance being prey to theft of network
> services (e.g. stealing network services by tunneling
> across your network between NAPs isn't unheard of).
I've seen it happen. :-)
> As for the 'no-export' & redistribution thing, I'd
> propose a slightly more failsafe model. That is,
> explicitly deny external advertisement of more specific
> 'internal' prefixes as a matter of standard policy
> on all external peerings.
We use 'aggregate-address <foo> summary-only' statements
on border routers, to I guess we're sort of already doing
what you suggest,
> Then again, an even more fail-safe model is to only
> allow specific communities to be advertised externally
> .. obviously a separate set for peers & transit customers.
> This allows you to avoid problems that occur when a
> new routers in inadvertently not configured to send
> communities to a peer.
Good idea - although the well-known community 'internet'
(advertise to internet) seems to have disappeared from
IOS since the documentation I looked at which mentioned
it:
route-sj3.cam.ac.uk(confi)#set community ?
<1-4294967295> community number
aa:nn community number in aa:nn format
additive Add to the existing community
local-AS Do not send outside local AS (well-known community)
no-advertise Do not advertise to any peer (well-known community)
no-export Do not export to next AS (well-known community)
none No community attribute
<cr>
Obviously I could make up a community, but I thought
'internet' was a well-known community to do external
advertisement.
M.
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:22 EDT