[nsp] BGP filter issue

Sean Mathias seanm at prosolve.com
Sat Jan 31 22:56:44 EST 2004


So here are some thoughts.  First, I am a bit curious as to what the
original goal was for implementing a filter to restrict the AS
'diameter' of your BGP table.  Understanding that may help a bit in
understanding the problem and what your filter was trying to accomplish.

Secondly, it is a bit tedious, but to determine where/why routing was
failing, I would suggest a manual recursive route lookup for one of the
routes that was failing.  For instance, the 67.83.204.0 network.
Working backwards, can your router resolve a path all the way to that
destination hop by hop?  

Typically, filters I have seen have accepted default and AS from peers,
but not from an AS that is a peer of a peer.  I am not sure what the
advantage might be in doing this.  Also, to state the obvious, if you
are single-homed, you need nothing more than a default, and if you are
multi-homed to the same provider, all you need is their AS routes and a
default.  I can't see a reason to extend that out one more AS.

Sean Mathias
CCIE# 12779
206-920-0301
seanm at prosolve.com

-----Original Message-----
From: Alban Dani [mailto:adani at stevens.edu] 
Sent: Friday, January 30, 2004 12:28 PM
To: Sean Mathias
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] BGP filter issue


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)

Thanks again,

Alban 

-----Original Message-----
From: Sean Mathias [mailto:seanm at prosolve.com] 
Sent: Friday, January 30, 2004 10:57 AM
To: Alban Dani
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] BGP filter issue

What would be an example of the networks for both remote clients the
fail and succeed?  Maybe include a sh ip bgp x.x.x.x for the networks as
well.  I will be traveling all day and will not be back on email until
tomorrow.

Sean Mathias
CCIE #12779
206-920-0301
seanm at prosolve.com


-----Original Message-----
From: Alban Dani [mailto:adani at stevens.edu] 
Sent: Friday, January 30, 2004 6:19 AM
To: Sean Mathias
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] BGP filter issue


Hi Sean,

Here is some of the output from the command you suggested.
This output is taken from another router that has the same filter
applied. For the moment I can not put the filter back on the original
router.

router#sh ip bgp regexp   ^19262 [0-9]+$
BGP table version is 79535136, local router ID is xxx.xxx.xxx.xxx Status
codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 128.6.0.0        130.156.250.93           0             0 19262 46 i
*> 128.235.0.0      130.156.250.93           0             0 19262 4246
i
*> 128.235.160.0/20 130.156.250.93           0             0 19262 4246
i
*> 128.235.240.0/23 130.156.250.93           0             0 19262 4246
i
*> 130.68.0.0/17    130.156.250.93           0             0 19262 205 i
*> 130.68.128.0/18  130.156.250.93           0             0 19262 205 i
*> 130.68.192.0/19  130.156.250.93           0             0 19262 205 i
*> 130.156.17.0/24  130.156.250.93           0             0 19262 18794
i
*> 130.156.142.0/23 130.156.250.93        2654             0 19262 26635
i
*> 130.156.144.0/22 130.156.250.93        2654             0 19262 26635
i
*> 130.156.148.0/24 130.156.250.93        2654             0 19262 26635
i
*> 130.219.0.0/19   130.156.250.93           0             0 19262 11094
?
*> 130.219.0.0      130.156.250.93           0             0 19262 11094
i
*> 130.219.32.0/21  130.156.250.93           0             0 19262 11094
?
*> 130.219.40.0/21  130.156.250.93           0             0 19262 11094
?
*> 130.219.48.0/20  130.156.250.93           0             0 19262 11094
?
*> 130.219.64.0/19  130.156.250.93           0             0 19262 11094
?
*> 130.219.96.0/20  130.156.250.93           0             0 19262 11094
?

Thanks for your help,

Alban 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Sean Mathias
Sent: Thursday, January 29, 2004 5:48 PM
To: Alban Dani; cisco-nsp at puck.nether.net
Subject: RE: [nsp] BGP filter issue

With the filter in place, can you look at the output of show ip bgp
regexp ^19262 [0-9]+$ to see if it is matching as you expected it to?  

Sean Mathias
CCIE #12779
206-920-0301
seanm at prosolve.com


-----Original Message-----
From: Alban Dani [mailto:adani at stevens.edu] 
Sent: Thursday, January 29, 2004 1:14 PM
To: cisco-nsp at puck.nether.net
Subject: [nsp] BGP filter issue


Hello,

 

Recently I experienced a weird issue with our internet connection.

 

We have a Cisco 7200 connected to our ISP ( Verizon).

A month ago we applied a bgp filter on the inbound that would accept bgp
routing updates only from our neighbor AS and the one next to it.

 

ip as-path access-list 6 permit ^19262$

ip as-path access-list 6 permit ^19262 [0-9]+$

ip as-path access-list 6 deny .*

 

Last week we started having issues with the internet connection for
several employees that connected remotely to our network. After some
research we figured that people that were connected to ISP-s that were
no more then two AS hops from us were having the problem ( and we could
find their networks in the bgp table ). On the other hand people who
were more then two AS hops away were just fine. Their networks could not
be found in the bgp table (as excpected  because of the filter ) and
they were taking the default route outside.

 

We took the filter out today and everything is back to normal.

 

Can anybody explain this? Is it a bug? A design flow? Is it the ISP?

 

 

Thanks in advance

 

Alban 

 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/





More information about the cisco-nsp mailing list