Re: weird BGP cisco-ism? [problem resolved]
What was happening is that, about a week ago, another provider got a request from a customer to route them a single /24 from the middle of our (non-portable) block. Because there was no IGP route for that customer, but a network line was in place, the other provider was, every 5-20 minutes, announcing the route for about 30 seconds, and then withdrawing it. but a network line was in place, the other provider was, every 5-20 minutes, announcing the route for about 30 seconds, and then withdrawing it.
We peer with that provider directly, and can also see them via our transit provider
The assumption here is that the advertisement from the BGP peer in question was being rec'd by you and installed in the routing table, ie: you accepted a BGP advertisement in your own address space from another (untrusted) peer? I hate to state the obvious, but don't you filter your own blocks from your other BGP peers? Inbound, I mean. Very simple: router bgp 1 neighbor 10.1.1.1 remote-as 2 neighbor 10.1.1.1 filter-list 99 in as-path access-list 99 deny ^$ as-path access-list 99 deny ^1_ [etc -- however you want to set it up] Isn't this akin to wearing a condom nowadays in the 'net BGP routing warz. Before I left my last job, I was on my way to installing anal as-path access lists for our own customers who did BGP to prevent the above and also prevent another Florida fiasco. The idea was that we would only accept explicit addresses from those BGP peers. All that was need was to add a list for each peer: neighbor 10.1.1.1 distribute-list 10 in access-list 10 permit 172.16.0.0 or even worse, enforce CIDR/prevent subnets by only accpeting the specific block advertisement: distribute-list 101 permit 172.16.0.0 0.0.0.0 255.255.0.0 0.0.0.0 Just good practice to me :) Hopefully everybody else is doing the same??? Rob Gutierrez / 3Com - GIS Internet Security
On Fri, 11 Jul 1997, Robert Gutierrez wrote:
I hate to state the obvious, but don't you filter your own blocks from your other BGP peers? Inbound, I mean. Very simple:
Isn't this akin to wearing a condom nowadays in the 'net BGP routing warz.
Depends. Consider the following scenario: You have a customer X that is dual homed to provider A and provider B. X is numbered out of provider A's CIDR block. If the connection between X and provider A drops, and provider A filters A's own blocks, then while the connections remains lost, there is no connectivity between X and A. So simply filtering one's own blocks from peers can cause problems. The most rational thing to do is to block all except the specifics of dual homed customers, but whether one does that or not depends on level of configuration automation one has achieved, I think. -dorian
Not to totally go off the subject, but if you have a ruleset like this implemented for all of your customers, what type of extra load does the route filtering impose on a router? We're a rather small ISP, and we don't use BGP at all, I'm just curious what type of impact this has. Thanks, Charles On Fri, 11 Jul 1997, Robert Gutierrez wrote:
your other BGP peers? Inbound, I mean. Very simple:
router bgp 1 neighbor 10.1.1.1 remote-as 2 neighbor 10.1.1.1 filter-list 99 in
as-path access-list 99 deny ^$ as-path access-list 99 deny ^1_ [etc -- however you want to set it up]
Isn't this akin to wearing a condom nowadays in the 'net BGP routing warz.
Before I left my last job, I was on my way to installing anal as-path access lists for our own customers who did BGP to prevent the above and also prevent another Florida fiasco. The idea was that we would only accept explicit addresses from those BGP peers. All that was need was to add a list for each peer:
neighbor 10.1.1.1 distribute-list 10 in access-list 10 permit 172.16.0.0
or even worse, enforce CIDR/prevent subnets by only accpeting the specific block advertisement:
distribute-list 101 permit 172.16.0.0 0.0.0.0 255.255.0.0 0.0.0.0
Just good practice to me :) Hopefully everybody else is doing the same???
Rob Gutierrez / 3Com - GIS Internet Security
participants (3)
-
Charles Sprickman
-
Dorian R. Kim
-
Robert Gutierrez