Re: [apops] Asia Pacific Weekly Routing Report

  • To: apops at lists dot apnic dot net
  • Subject: Re: [apops] Asia Pacific Weekly Routing Report
  • From: Danny McPherson <danny at ambernetworks dot com>
  • Date: Fri, 29 Dec 2000 10:05:58 -0700
  • Reply-to: danny@ambernetworks.com
  • Sender: owner-apops@lists.apnic.net
    • 
      > So the problem is not one of de-aggreagtion down to say /24 but rather
      > leaking of prefixes >>/24 to peers (the theory being that such long
      > prefixes belong securely in IGPs and not in eBGP)?
      
      I don't think anyone said that, at least, I hope not.  IMO,
      you only want to put as much in your IGP as you have to, and 
      that's it.
      
      At a previous employer we actually saw something similar to 
      this (i.e., leaking of more-specifics that should have been 
      denied by egress policies).  It turned out that the folks 
      doing to configuration management were rewriting most all of
      the routing/redistribution policies (e.g., route-maps and 
      prefix filters) and because some were rather large, they'd 
      take quite a bit of time to load.  In the mean time, the BGP 
      redistribution process would run, detect absence of the 
      prescribed policy, and pass all routes through while NOT
      tagging the routes with one of the NON-transit BGP 
      communities.  
      
      In short, the quick fix was to simply permit advertisement of 
      prefixes with explicitly tagged with transit communities, and 
      implicitly deny all other prefixes.  As well, we modified the 
      configuration automation stuff so that policies were only 
      touched if actual updates occurred [duh!]. 
      
      The one thing we never did completely figure out is why some 
      of the more-specifics hung around in other networks for 
      sometimes hours, or even days, as the next iteration of the 
      redistribute process contained the newly modified policy and 
      the routes [should have been] withdrawn.  I can only assume 
      that some implementation bug resulted in this.
      
      I guess I should state that I'm not at all a fan of 
      redistribution of information into another protocol, it was 
      inherited, really!
      
      -danny
      
      
      
      
      
      
      *             APOPS: Asia Pacific Operations Forum              *
      * To unsubscribe: send "unsubscribe" to apops-request at apnic dot net *