From: jimi@dxcoms.cern.ch (Jean-Michel Jouanigot) Tony, Sorry to bother you, but I have two questions concerning BGP4 and 9.21 (Feb5). I think I've discovered something odd. You should use bgp4-support instead, please. I have nothing to do with BGP4. Firstly, I'm currently playing with BGP4 on our DMZ, on which we used to run BGP3 for a while. I configured one test box as talking BGP4 with all the other boxes, some of them being in the same AS (513), some other in different ASes (1755). When I did this, I kept all the defaults in the BGP4 configurations. 2043 | | +----+ +----+ +----+ +-----+ |EBS | |H3 | |H2 | |TEST | |1755| |513 | |513 | |513 | ...... +----+ +----+ +----+ +-----+ | | | | | | | | 192.65.185.0 -------------------------------------------------- All boxes but TEST peer using BGP3. The next hop for them is always on 192.65.185.0 when they want to reach a net connected thru onother router. For TEST, things are different. Suppose TEST wants to route to 192.87.45.1: ctest1>sh ip bgp 192.87.45.1 BGP routing table entry for 192.87.45.0/255.255.255.0, version 5684 Paths: (2 available, best #1) 2043 1103 1104 193.172.24.9 from 192.65.185.5, weight 0 Origin IGP, valid, internal, best 1755 1128 1103 1104 192.65.185.4 from 192.65.185.4, metric 8481, weight 0 Origin IGP, valid, external The Prefered path is the shortest, 2043 1103 1104, but the next hop is 193.172.24.9, which happens to be the interface of 2043, but ctest1>sh ip ro 193.172.24.9 Routing entry for 193.172.24.0 (mask 255.255.255.0) Known via "bgp 513", distance 20, metric 8481 Tag 1755 Last update from 192.65.185.4 1:42:07 ago Routing Descriptor Blocks: * 192.65.185.4, from 192.65.185.4, 1:42:07 ago Route metric is 8481, traffic share count is 1 That's a bug. The routing table should always reflect the "best" route. since ctest1>sh ip bgp 193.172.24.9 BGP routing table entry for 193.172.24.0/255.255.255.0, version 8755 Paths: (1 available, best #1) 1755 1128 2043 192.65.185.4 from 192.65.185.4, metric 8481, weight 0 Origin IGP, valid, external, best OK, your going to tell me that 2043 should announce 193.172.24.0 to H3, or that we can fix this using next-hop-self or route maps, but still, it's not what I understand from the BGP4 draft: "A BGP speaker can advertise any external border router as the next hop [1], provided that the IP address of this border router was learned from one of the BGP speaker's peers, [2] and the interface associated with the IP address of this border router (as specified in the NEXT_HOP path attribute) shares a common subnet with the local and remote BGP speakers [3]." [1] this is our case [2] yes, from 1755 [3] No, the interconnection network is 192.65.185.0, and the interconnection between 2043 and 513 is in 193.172.24.0 Am I wrong ? Of course, the routes received from 1755 were all indicating a NEXT_HOP on 192.65.185.0. This question only concerns routes within 513. Another question I have is why is this new concept introduced in BGP4? What's the idea behind this? Who's using it? This is very dangerous in the sense that if a network is not announced by an external peer (2043 in my case), then all the routing is gone... Another point: the previous drafts of BGP4 were introducing a "BGP path attribute" which was carried together with the route. In some recent extensions of Ripe-81, and after some discussions with Peter Lothberg and Tony Bates, it appeared to us that this could be used to "color" network advertisements and carry this information thru the Internet. Any reason why you've dropped the idea ? Yes, it tends to break aggregation. Since you can't aggregate colored routes together, it would cause people to not aggregate. This would increase the size of the routing tables. Tony -- Jean-Michel