From: Joseph Brunner (joe@affirmedsystems.com)
Date: Sun Mar 09 2008 - 02:38:35 ARST
Wow! I'm impressed. I wasn't even thinking of confederations. yes, it just
labbed it up.. It does work indeed. ONLY 65500 is visible in the path.
Nice work, thanks!
The only issue in my particular client's topology is they have many things
peering directly with 65020 for RTR1, (which I can't change), but otherwise,
excellent idea!
Joe
_____
From: Ed Lui [mailto:edwlui@gmail.com]
Sent: Saturday, March 08, 2008 10:30 PM
To: Joseph Brunner
Subject: Re: Real world bgp issues
Hey Joe,
Would the below config a possible solution in your case?
RTR1
router bgp 65020
bgp confederation id 65500
bgp confederation peer 65501
RTR2
router bgp 65501
bgp confederation id 65500
bgp confederation peer 65020
neighbor RTR3 remote-as 414
Cheers,
Lui
On Sat, Mar 8, 2008 at 1:22 PM, Joseph Brunner <joe@affirmedsystems.com>
wrote:
Good afternoon,
Today I was working on a BGP request and came across the following issues; I
consider them sparsely documented and perhaps interesting.
Consider the topology -
RTR1 (AS 65020) - RTR2 (AS 65500) - RTR3 (AS 414)
RTR1 is an extranet router putting static routes into BGP with the network
command.
RTR2 is learning those routes from RTR1 and advertising them on to RTR3
(with a registered AS#)
The routes were previously ONLY advertised from RTR2 as a single /24 with a
static route to RTR1 and put into BGP on RTR2 with a network command.
I was asked today to advertise some of the longer prefixes (a few /29's)
subnets within the /24 that was originated by
RTR2 already. The goal was for AS414 and its peers to know all /29's being
advertised not just the single /24 as they have peers that can't take the
single /24
for fear of an overlap, that could blackhole the entire /24 when not all of
it should be routing back to RTR1.
I removed my "deny all" from RTR1 on the RTR1-RTR2's bgp session and allowed
the /24 to come through and all the /29's
within that /24. "ip prefix-list RTR1 permit 198.74.60.0/24 le 29"
Obviously ALL the routes from RTR1 to RTR2 are going to have 65020 as the
first AS in the path.
AS414's administrator asked me to filter 65020 from the path as he may be
using that for other things, or will at a future point and does not want
private AS conflict.
They previously gave us 65500 from their list of private AS's people can use
to peer up with them who don't have a registered AS #.
So here are the interesting issues I encountered.
1. I tried on RTR2 "neighbor RTR1 remove-private-as" but this didn't work -
I'm guessing you can't REMOVE a PRIVATE AS when you are USING A private AS -
????
2. I tried on RTR2 "aggegrate-address 198.74.60.8 255.255.255.0" to cause
RTR2 create an aggregate of the SAME EXACT NETWORK its learning FROM RTR1,
for the purpose of removing the 65020 from the path when the aggregate is
generated - but this failed, RTR2 kept on sending routes with the path
"65020 65500" to AS 414. Apparently, unless you really ARE aggregating the
router knows to do nothing with the aggregate-address command.
3. My last instinct was to use "neighbor RTR2 local-as 65500 replace-as" on
RTR1 (and have RTR2 peer with "65500" for its session with RTR1), but alas,
RTR1 was running code from so long ago, this was not an option.
In the end, defeated and deflated I went back to creating six /29 static
routes on RTR2 with RTR1 as the next hop. I then advertised them into BGP on
RTR2 with the
Network command ;(
OH, well, it was a worthy lesson for an "advanced beginner"
-Joe
#19366
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART