North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Customer AS
- From: Nick Williams
- Date: Fri Aug 23 17:23:51 1996
[DISCLAIMER: I have not read all or even most articles in this thread,
so perhaps what I write below has already come up]
About a year ago I had a chat over e-mail with a Cisco engineer where I
proposed a new feature which would allow a simple solution to the
problem of 'multi-homing with two providers for backup while using PA
space' and yet would allow carriers to apply a policy like Sprint's.
This came up because at the time I was working with an ISP that was
multi-homed, but which, at the time, experienced AS splits very often;
at those times I wanted to drop some of the aggregates to reflect the
split and so allow users in either half of the AS to continue to have
access to the rest of the AS and the Internet. But I wanted this to
So what I proposed was that route-maps be allowed to match conditions
where other routes are or are not known to the router. The way to
implement this would be to take these special match clausesand apply them
to any new/withdrawn routes heard via BGP or added/removed to the routing
table by other protocols. Thus a router could be configured to stop
suppressing certain routes heard from outside if those routes became
unavailable internally, or could stop suppressing the announcement of
certain routes if .... and so on. Thus if a carrier's (let's call it A)
customer (C) multi-homes to a second carrier (B), A can suppress all
announcements of C's routes heard at A's border with B, but stop
suppressing those routes if C's connection to A went down, causing the
router at the A-B border to lose its internal route to C; thus when the
A-C link goes down A learns how to route to C via B automatically.
Other benefits of such a feature would be to allow A and B to peer a
many exchanges but exchange routes at only one of them; if the exchange
went down or one or both of the ASes partitioned, then A and B could
automatically start exchange some routes wherever necessary.
There are some drawbacks. The BGP process must keep track of suppressed
routes, it can't just drop them, which of course requires more memory.
But then, this only applies to suppressed routes that should be
automatically unsuppressed. Another drawback is that AS partitioning
events would add to the route flapping normally experienced (though this
would be a function of the frequency of such events). On the other hand
this could reduce the costs of redundancy; the costs of implementing
this feature and using it could be made up for by charging multi-homed
sites for implementing it for them.
I am not sure if this is worth considering at all or not. It may be that
someone already implements something like the above using syslog to keep
track of route flapping and expect scripts to change filters on the fly.
- - - - - - - - - - - - - - - - -