[nsp] BGP filter issue
Sean Mathias
seanm at prosolve.com
Mon Feb 2 16:56:43 EST 2004
Well, it is always possible that a provider change can cause problems,
but does not seem likely in this case. Given the scenario you describe
below, I still see no reason to deliver anything more than a default
route to your two routers. They have no alternative as there is only
one provider.
That said, I realize it is not an explanation of, or solution to your
problem. Sometimes it is pretty hard to determine a soltion without
device access (for me anyways).
Good luck and if you do happen to determine the root problem, please do
let me know what it is.
Sean Mathias
CCIE# 12779
206-920-0301
seanm at prosolve.com
-----Original Message-----
From: Alban Dani [mailto:adani at stevens.edu]
Sent: Monday, February 02, 2004 1:32 PM
To: Sean Mathias; 'Danny McPherson'
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] BGP filter issue
Thanks to both of you for your messages.
I'll try to create a picture of our connection and explain the reason of
putting the filter in place.
We have a DS3 connection to Verizon. Two different pvc-s terminate in a
LS1010 and from there split to two separate routers.
One of them is the commercial internet and the other one is a special
inter educational regional connection. When the later was put in place
there were some concerns among some participants regarding the large
number of routes that the router would have to deal with. So we came up
with the filter I described in my previous message. This filter has been
in place on this interface for over a year now.
On the other hand we were using just a default route on our commercial
internet and that setup has also been in place for over a year.
We applied the filter on the commercial internet side of things at the
end of last year. However the problems started to manifest themselves
about two weeks ago.
Right now I can not do any more testing since we can not put the filter
in place, at least not right now.
The major question in my mind is: Applying this filter was the only
change made to our configuration in over a year and furthermore if the
filter was the problem why it took almost a month for things to start
braking?
Do you think some change on the provider's side could have caused this?
Thanks again
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: Saturday, January 31, 2004 10:57 PM
To: Alban Dani
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] BGP filter issue
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/
_______________________________________________
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