Hi Mauricio, thanks for the reply. I believe there are quite a few folks who automate their peering up keep with the help of the data contained within the IRRs. With the IRRs providing a mechanism for validating routing information and RPSL providing a common language for describing routing policy - automating the creation of prefix and AS-Path filters for peering sessions becomes attractive. Check out http://www.irr.net/docs/faq.html for additional reasons for using IRR data to generate routing policy. IRRToolSet is a tool that can create router configurations based on IRR data. The portion I'm trying to figure out is the 'pushing' of these configurations. From what I gather, it seems that this is usually something thats homegrown. Anyone willing to share their homegrown tools? :) Cheers, RR On Sat, Jan 7, 2012 at 6:20 PM, Rodriguez, Mauricio <mrodriguez@fletnet.com>wrote:

Rafael,

Hello! Nice to see you post on the list...

This sounds like a nice idea. Do you know of anyone that's currently running such an automated system? If you end up finding something, or rolling it yourself, I would suggest being careful with his approach. You're assuming that your peers are actually keeping the IRR records up to date or that the information contained therein is appropriate for non-transit peering sessions. If you have the right leverage, perhaps you can make that a condition for peering. If you're manually keeping prefix-list filters for each of your peers now, consider the return on that level of detailed configuration. Is the risk mitigated really worth the overhead?

I would recommend that you keep your peer filters as simple as possible. Inbound, certainly filter bogons, martians, your own prefixes, and any prefixes received from other peers. Try using communities vs. individual prefix entries as much as possible. Perhaps enforce the peer ASN with an AS Path filter on the leading ASN on each prefix received. If you're concerned about FIB size explosion, decide on a bit boundary for prefixes to be accepted and filter on that. Certainly agree on a prefix-limit with your peer and configure that on the peering session. You may have to be diligent on monitoring sessions that drop due to prefix-limit violations (SNMP Traps, syslog) and follow up to correct those as needed, since most peers won't keep you informed on changes in their quantity of advertised prefixes. Juniper routers can be configured to send warnings on certain thresholds so you can catch normal growth vs. a fat-fingered configuration by a peer. You can then take care of those proactively before sessions start dropping.

Outbound, don't let anything out other than your own prefixes or those advertised to you by your customers. Otherwise, you may be providing free transit to your upstreams and other peers.

Just my $0.02, others will likely disagree and recommend that you keep your prefix filters in place. I digress if there's some BCP out there that I don't know about that indicates that prefix filters be used in this case.

Regards, Mauricio Rodriguez Owner / Principal Engineer Fletnet Network Engineering

Mauricio.Rodriguez@fletnet.com http://www.fletnet.com

***** Email confidentiality notice *****

This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.