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

[Bob Tinkelman]

> On Fri, Mar 02, 2007 at 03:00:45PM -0400, Bob Tinkelman wrote:
> > 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.

> "Full routing table" is as subjective and meaningless as "full
> usenet feed".


I suppose.  I'd like to think that "Things will work as
expected so long as nobody needs to aggregate someone else's
routes beyond /24s."  But maybe that's just wishful thinking.

But obviously, the situation I was worried about was the
common one where someone (yahoo in this instance) has
upstream feeds of "default plus customer routes".  I know
that's a common configuration.  (We recommend it for some
of our customers.)  I was surprised to discover that yahoo
was configured this way, as I thought of them as "one of
the big guys" (with big routers that could handle full
routing tables).



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

> There are more routing policies across the globe than you
> or I can think of, and they all change.  Assuming anything
> about any of them is folly.  Deaggregation-based  "load
> balancing" assumes much about remote topologies, and can
> only ever be guarenteed affective as far as the customer-
> provider relationship extends.  As such, NO-EXPORT (or
> for those who support is, NO-PEER) tagged deaggregates
> are a useful tool.  Otherwise,spewing deaggregates just
> violates being conservative in what you send.



If your point was that our customer shouldn't expect to
be able to totally control which path packets take to
arrive on his net, then I agree.  However, I would like
to be able to let the customer try to control this, as
much as possible, without creating reachability issues,
certainly for important parts of the net like yahoo.


Summarizing from prior posts:

   The "quick work-around" was to have the customer router
   announce the /24 to both upstreams.

   The "next-day config change" was to have the customer
   router use our communities to instruct us to
      o  Use the /24, but
      o  announce it to no upstreams, peers or customers

   The "work-on-it-this-weekend task" was to write some
   scripts to notice this sort of situation proactively.

Thanks to everyone who replied, on or off list.
--
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