Automate Peering Maintenance

[packetjockey at gmail.com (Rafael Rodriguez)]

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 at 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 at 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.
>
>
>