[j-nsp] BGP Prefix-Limit On A Session
bbird at epik.net
bbird at epik.net
Thu Feb 26 09:41:50 EST 2004
#From: Richard A Steenbergen [mailto:ras at e-gerbil.net]
#Sent: Wednesday, February 25, 2004 9:47 PM
#Are there any operators out there who place the importance of prefix
#limits providing protection of routing resources from someone
#million routes above or anywhere near the importance of using prefix
#limits to catch "common" leaks by peers/customers/etc which
#in suboptimal routing?
I have to partially disagree with you Richard. I support the JunOS behavior
here, and do implement both an explicit prefix-list (aka.
policy-statement/route-filter) based on IRR data, and a prefix-limit based
on registered routes +overhead. This is for the reasons already mentioned.
As far as the BGP session bounce when adding the prefix-limit, I completely
understand your point.
There is also much pain involved when a BGP group contains multiple peers
who share a common export-policy, but adding a prefix-limit to one of the
peers, where it didn't exist before causes unchanged peers' BGP session to
reset as well.
I am aware that this will always happen wrt to export-policy changes, and
how JunOS internally groups based on a common set of attributes that control
export policy (for scalability). However, It didn't make much sense that
this would be related to prefix-limits as well. I am told that behavior was
a bug, and was due to be fixed at some point? Can anyone at Juniper confirm
#Is this particular disconnect between developers and operators
#of the reasons why every operator I know would LOVE to see
#prefix limits that follow the "normal" number of prefixes
#announced by a
#peer, and yet no vendor has ever tried to implement it (that I know of
This is a wonderful idea! Obviously not difficult, either.
More information about the juniper-nsp