Re: Routing policy in ASN database?

  • To: "Miguel A.L. Paraz" <map at iphil dot net>, apops at apnic dot net
  • Subject: Re: Routing policy in ASN database?
  • From: John Houlker <j.houlker at waikato dot ac dot nz>
  • Date: Thu, 3 Apr 1997 19:42:30 +1200
  • In-reply-to: <199704030642.OAA18280 at marikit dot iphil dot net>
  • Sender:
    • Miguel
      >Is the routing policy section in the ASN entries for the APNIC database in
      >use anywhere?
      I can't answer this one, but last I knew in any case MCI don't use routing
      information from any source apart from their own database, i.e. excluding
      the rest of the IRR (at least for their own directly connect customers so
      far as I can tell - comparing announcements on direct peering vs. those via
      BBNPlanet for example).  I guess this means that if you want to reduce the
      number of DB entries you need to load you might as well start with the MCI
      RR.  Note that you will need to inform ANS of your policy (i.e. what will
      be valid peers with ANS for paths to your origin ASes) - last time I had to
      do this it was a phone call to the ANS NOC; maybe it can be expressed in
      the IRR by now.
      >I am now preparing for a switch to BGP peering with Global One and MCI
      >when our new link comes in mid-May.
      >Given that we have will have a T1 to Global One and a 256K to MCI,
      >do you think we can get MCI customers to route through MCI, and the
      >rest to go through Global One, without saturating the 256K?  I'm
      >wondering what percentage of the Net would go through MCI.
      By default MCI set "local pref" on announcements from their clients to
      override other metrics such as BGP path length, hence MCI customers
      certainly will route through MCI.  A possible snag is that the "catchment"
      of the MCI backbone is considerable, so you may find the 256k link
      overloaded.  To seek a correct balance I suggest you look at setting the
      BGP community tag (ask the MCI NOC for what will be appropriate) to turn
      off the local_pref behaviour on some of your announcements (all if
      necessary).  When disabled you can control the load by path length (MEDs
      don't help here) - i.e. path stuff (again perhaps more on some
      announcements than others).  You could restrict traffic to that from the
      MCI AS alone with a no_export tag but that could be too little and would
      remove the potential for redundancy.
      >My alternative is to get some MCI address space and assign it to
      >a WWW proxy cache so that we get application-level routing.
      We have been balancing traffic from different providers with a mix of
      multi-homing, multilinks, and multi-circuit ebgp for some while - some
      traps (the worst was when there were mistakes in the bgp dampening
      configurations) but effective enough on the whole.
      To unsubscribe: send "unsubscribe" to apops-request at apnic dot net