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 <mrodrig...@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.rodrig...@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. > > >
