[nsp] BGP filter issue

[Danny McPherson]

Alban,
My first guess would be something regarding BGP next_hop
reachability.  However, your messages seem to implicitly
suggest that this behavior occurs when you filter *all but
some subset* of routes learned via your ISP via the as_path
filter list you described.

When you are not filtering routes via the as_path filter
list are you accepting full routes or using default and
accepting none?

If full routes, then does the filter policy specification
(e.g., via route-map or the like) manipulate any other
attributes?

Finally, you noted that connectivity still existed when
this problem occurred, it was just severely degraded.
If this were indeed a BGP next_hop issue perhaps internal
load-balancing is resulting in some intermediate node
forwarding the packets appropriately, while others don't
have a completely populated forwarding information base
(as a result of synchronization issues, BGP next_hop
reachability or the like -- Though I suspect the problem
is actually much simpler than this :-)

-danny

On Jan 30, 2004, at 1:28 PM, Alban Dani wrote:

> Hi,
>
> Sean the following are some Notes I took when the filter was 
> implemented
> and the output of the commands is somewhat modified but the main chunks
> are there.
>
>
> The output for a network that was not in the table is as below.
>
> router#sh ip bgp 64.0.199.0
> % Network not in table
>
> This network was three AS hops away and was using the default route and
> connecting just fine.
>
> vgw#sh ip bgp 67.83.204.0
> BGP routing table entry for 67.83.204.0/24, version 79530961
>     19262(Verizon) 6128 (Cablevision)
>
> This network (ie our people using Cablevisions Cable Service) which is
> two AS-s away had major problems connecting. We ran some MTR-s and we
> were constantly getting over 80% packet loss to these guys)