RE: Route Reflector architecture and how to get small customer blocks in to BGP?
Yep, that is a good strategy... No announcement without the right communities sure makes it much harder to leak. We redistribute lots of static routed stuff into BGP, but only announce globally using network statements with route map applying the right communities. So far, we have never leaked internal routes to customers, peers or transit that we are aware of. John :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Provo Sent: Sunday, January 28, 2007 1:12 PM To: NANOG Subject: Re: Route Reflector architecture and how to get small customer blocks in to BGP? On Sun, Jan 28, 2007 at 10:59:50AM -0700, Danny McPherson wrote: [snip] > o If you're going to use redistribution - or not - ensure that all > external advertisement policies require explicit match of advertise > communities and default is to deny This should be just good security policy. I think of it as a network-level instance of "that which is not expressly permitted is denied" which everyone applies for services on their hosts, right :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Route Reflector architecture and how to get small customer blocks in to BGP?
On Sun, Jan 28, 2007 at 10:59:50AM -0700, Danny McPherson wrote: [snip] > o If you're going to use redistribution - or not - ensure that all > external advertisement policies require explicit match of advertise > communities and default is to deny This should be just good security policy. I think of it as a network-level instance of "that which is not expressly permitted is denied" which everyone applies for services on their hosts, right :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Route Reflector architecture and how to get small customer blocks in to BGP?
On 1/28/07, Danny McPherson <[EMAIL PROTECTED]> wrote: o If you're going to use redistribution - or not - ensure that all external advertisement policies require explicit match of advertise communities and default is to deny I'll second that recommendation. I learned early in life that this can be a mess otherwise. We employed that technique at BBN/Genu and it kept us from leaking quite nicely. If a provisioning person forgot a customer inbound route-map or something, we didn't accidentally hose ourselves. -- -Steve
Re: Route Reflector architecture and how to get small customer blocks in to BGP?
On Jan 28, 2007, at 9:06 AM, Joe Provo wrote: Select the latter. Modifying networks statements for move/add/changes invites trouble. Carefully constructed policies to redistribute your connected or static routes into iBGP and tagged appropriately are a win. At the very least, you can limit to subnets of "my network's prefixes"; If possible, leverage the nice aggregation and limit to "my network's local prefixes" and you scope potential future havoc. I'm not a big fan of redistribution as I've been bitten by it a few times. One of the biggest issues is that if a policy is being updated and some periodic redistribution process runs the policy at that instant is applied and things not in the policy at that snapshot are not applied (intuitive enough - now). For example, if you're redistributing routes into BGP and coloring with a community based on a route match policy and some of those routes aren't in the policy snapshot then they won't be "colored" with communities or the like and may be leaked or not advertised otherwise. This is particularly ugly when you've employed "implicit permit" external advertisement policies where routes that aren't tagged with some value are passed by default. Two lessons learned for me: o If you're going to use redistribution - or not - ensure that all external advertisement policies require explicit match of advertise communities and default is to deny o Don't unnecessarily touch policies or blindly overwrite them periodically, utilize incrementally updated prefix lists as much as possible Given the two conditions above I'm not as wary of redistribution and it may ease configuration managed as Joe suggests. -danny
Re: Route Reflector architecture and how to get small customer blocks in to BGP?
On Sat, Jan 27, 2007 at 01:39:54PM -0500, Pete Crocker wrote: [snip] > First, they've got a BGP full mesh of all their routers. They're > considering moving towards route reflectors. There's 2 core routers > per-POP. And anywhere between 5 and 15 edge/aggregation routers in a > POP. The current thought is to move to a route-reflector full mesh > between all the dual-core routers in each POP. The other alternative > is to deploy just 2 route reflectors for the entire network. Can > anyone point me towards real-world info on the pros and cons of each > approach? There seems to be little public info on why people do what > they do, it's more info on how to do it. Data missing above: how many sites in this design overall? What is the fragility of the inter-site links? What are the growth plans? If "few", "robust" and "none-to-low" are the answers then yes only a pair or quartet of network wide RRs make sense. I wouldn't want to have to maintain it, nor really recommend it. For any kind of growth, failure condition coverage, or many POP sites, then you'll want all the individual sites' core routers in the core iBGP mesh and a pair of RR trees per site, each rooted in the core router. I'll leave the whole confederation issue aside for now. > Assume that there are /29s assigned to customers. It would be a > beautiful world if these /29s could be easily rolled up in to /24s, [snip] > router. Also, there's /22s to /19s per-pop in nice little > aggregatable subnets, so at least that's good. [snip] > - Should he use a static route which would be withdrawn if the link > went down? This would mean traffic to a down customer would be > dropped quicker, but flaps cause more BGP churn. Select the latter. Modifying networks statements for move/add/changes invites trouble. Carefully constructed policies to redistribute your connected or static routes into iBGP and tagged appropriately are a win. At the very least, you can limit to subnets of "my network's prefixes"; If possible, leverage the nice aggregation and limit to "my network's local prefixes" and you scope potential future havoc. > - Would confederations help? Seems like overkill, but he could > aggregate at the POP level instead of the router level. There is no need for small slices of the nice aggregatable local site prefixes to leave the site in eithe a confederation or an RR model. Think of what device owns the tie-down route for the site-level, and how it is hearing that route, and how it is redistributing to the rest of your network. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: who was the last legit spammer?
On Sun, 28 Jan 2007, Travis H. wrote: Hey, was discussing something from the long distant past recently. Specifically it was my memory of the last legitimate spamhaus, and how (IIRC) their backbone was DDoS'd as an act of pseudo-vigilante justice. I also seem to remember their backbone as spinning it as a content-neutral free-speech kind of thing, but they buckled and the Internet was probably better off. "Legit spammer"? Perhaps you're thinking of Sanford Wallace's cyberpromo and AGIS? http://www.cctec.com/maillists/nanog/historical/9710/msg00018.html -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
who was the last legit spammer?
Hey, was discussing something from the long distant past recently. Specifically it was my memory of the last legitimate spamhaus, and how (IIRC) their backbone was DDoS'd as an act of pseudo-vigilante justice. I also seem to remember their backbone as spinning it as a content-neutral free-speech kind of thing, but they buckled and the Internet was probably better off. This isn't the kind of thing where one can make an easy google query, but I'll bet you that someone here remembers a name that would lead to a URL that I could forward to the person asking for more info. TIA. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- http://www.subspacefield.org/~travis/> For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpTVUD61y909.pgp Description: PGP signature
