[c-nsp] Problems with peers that don't have full routing tables

[Bob Tinkelman]

I'd like some advice regarding a problem we ran into earlier
this week.  It occured on our peering link with Yahoo, but I
think it could happen with any peer which does not keep a
full routing table.

This is the topology:

       yahoo---------.
       |             |
    level3--ntt      |(peering)
       |     |       |
    uunet  ispnet----'
      701   22691
       |     |
      customer
       17017

The problem involved routing between yahoo and a /24
controlled by the customer.

These are the relevant bgp-announcements:

  customer was bgp announcing:
     165.254.64.0/20  to uunet and ispnet
     165.254.65.0/24  to uunet only

  ispnet was hearing
     165.254.64.0/20  from customer and ntt
     165.254.65.0/24  from ntt only

  isp was announcing to yahoo
     165.254.64.0/20  yes
     165.254.65.0/24  no  (just to our direct customers)


>From my email exchange with the Yahoo NOC, this is my
understanding:

   yahoo gets a partial feed from level3 which includes
   a default route and does not include either of the
   /20 or /24 listed above.

   yahoo (of course) prefers the /20 it's hearing from
   ISPnet over the 0.0.0.0/0 from level3.

   So, yahoo routes packets to the /24 through ISPnet.

However,

   When ISPnet gets traffic for the /24, it routes it
   through NTT, and

   NTT filters based on source address and, if it gets
   traffic from ISPnet with a yahoo source ip address,
   it just drops it on the floor.


Our quick work-around was to get our customer to bgp-
announce the /24 to both their upstreams.  This cleared
the problem but isn't giving them the inbound routing
policy they wanted.


   
I'm not sure of the right solution.

  I don't want to drop peering with yahoo, as we send them
  *lots* of traffic.

  I don't expect I'll get a positive response from NTT if I
  request that they stop filtering our outbound traffic (though
  I guess I'm willing to spent time trying that approach).

  I don't want to tell the customer to not announce the /20
  but instead announce lots of /24s, though that would solve
  this particular issue.

  I don't want to do nothing, and wait for this situation to
  come up again.


I'm sure others must have dealt with this before.
Thanks in advance for any advice.


PS  I included real ip addresses above.  
    You could figure out who the customer is and bug him. 
    Please don't.
--
Bob Tinkelman          <bob at tink.com>
ISPnet, Inc.  http://www.ispnetinc.net

+1 (718) 464-4747  office
+1 (800) 806-NETS  toll free
+1 (718) 217-9407  fax