Hi,
Great to hear some feedback, hope that this will go into discussion.
Please see below my comments/opinions.
3. Agree for filtering long AS-path - will update the document.
Striping down all inbound communities is something individual to certain
companies, I don't this this has to be recommended in scope of BCOP.
Moreover for operator in many cases it is required to preserve incoming
communities at least from customers and peers.
4. a. Rejecting bogons is included in current document from early beginning.
b. By means of prefix length I think we should accept everything shorter
or equal to /24. It is rule of thumb for everyone that one can advertise
/24 and it will be accepted by all players.
c. Agree on AS-path length - will update the document.
d. Communities 'no-advertise'/'no-export' are by default implemented in
routers (at least with most common ones). I don't think that we should
reject incoming prefixes with such communities or to do any action.
e. Maybe it is good in certain conditions to prepend routes which are
"out of region" but this can't be a common recommendation. It is very
common situation that a company advertises part or all of it's resources
from different places over the world.
f. In my opinion it is not normal to advertise private ASn into public
Internet, that is why I recommend to reject prefixes with private ASn in
AS-Path. While rejecting there is no need to remove private ASN.
g. Stripping all communities from prefixes is not a common case. Service
provider should forward prefixes preserving communities, because it's
customer can send community for network behind the provider.
Regards.
/Alex Saroyan
On 02/03/2015 06:32 PM, Rick Casarez wrote:
Hello,
After speaking with Bill Armstrong after the BCOP session I wanted to
share some information I have found when troubleshooting various
issues with Juniper over the years. I was unsure about sharing it at
first since I did not know what level of detail we wanted to go into
on these.
1. Section 4.1.6 - I believe a note should be added explaining that
Juniper does something peculiar that results in the algorithm being
run more than once. The reason behind that is Juniper will group paths
based on left most AS number. If any group has more than one path
JunOS will execute the algorithm within that group to find the best
path in that group. Then it will take the best path from every group,
and any singles, and then perform the algorithm for a final time to
get the best path overall.
We found this behavior when working with the Juniper BGP Dev on a
local-preference bug.
2. Unsure which section (if any) - Something else to note would be
that by default JunOS sets a MSS of 500 for BGP. This is getting a
little into vendor specific detail but the MSS setting does affect
convergence once eBGP or iBGP is established.
3. Section 4.3.2.2 - For inbound filtering we filter out anything that
has an AS-Path length longer than 100. This was due to vendor issues
when some routes were learned with AS-Path lengths of 250 or more. In
addition as a non-ISP we strip all communities on routes coming in.
Just a suggestions for additional protection on the inbound policy.
4. Section 4.3.4 - So I can add some notes for outbound route
filtering as well. In general we perform the following on all eBGP
sessions to outside entities:
a. Reject bogons (IPv4/IPv6)
b. Reject /0-/7 and anything smaller than /23
c. Reject anything with an AS length of over 100
- These are to ensure we remain a good netizen by not leaking anything
out that should not go out.
d. Reject anything marked with internal 'no-advertise'/'no-export'
communities
e. Prepend routes that are out of region for us
- Our regions are essentially the RIR boundaries. We want routes going
out all exit points but with a preference for those routes that
originate in region.
f. Remove Private ASN from AS-Path
g. Strip all communities from the prefixes.
Anyways, just some quick notes so far.
-------------------
Cheers, Rick
Experiences not things.
_______________________________________________
BCOP mailing list
BCOP@nanog.org
http://mailman.nanog.org/mailman/listinfo/bcop
_______________________________________________
BCOP mailing list
BCOP@nanog.org
http://mailman.nanog.org/mailman/listinfo/bcop
