[6bone] IPv6 route server

[John Fraizer]

On Thu, 8 Aug 2002, Pekka Savola wrote:

> On Thu, 8 Aug 2002, John Fraizer wrote:
> > I am currious what soft-reconfiguration has to do with bestpath selection
> > and redistribution?
> 
> There is a feature/bug [in Cisco (noticed on GSR 12.0(22)S) at least] that
> unless you have soft-reconfiguration inbound, 'sh bgp ipv6 xxx' shows only 
> the best path.
> 

Ahhh... Well, with Zebra, we try very hard not to emulate the BUGS in IOS
while still maintaining the look/feel. ;-)

The only advantage to running soft-reconfiguration inbound on a peer with
zebra is that you can do a "sh ip bgp nei [x.x.x.x | xx::xx]
received-routes" and display all prefixes that the peer sent you,
INCLUDING prefixes that were filtered by any inbound policy you may have
established on the peer.

Most people running Zebra that I know use soft-reconfiguration to achieve
the ability to do "clear bgp [neighbor] soft in" on peers that don't
support route-refresh.

It is not needed if your peer supports route-refresh and will save memory
if you disable it (on peers that support route-refresh).


> Looked quite similar to me, but perhaps I was taking conclusions too far
> :-)

Hehehe.  It is pretty close, isn't it?

I think the root cause of it only showing one prefix originally in this
case was that it was configured as an iBGP peer, on top of the fact that
bestpath selection on the two border routers is preventing them from
sending all paths they see to the route-server.

I have thought about this a bit and may have come up with a solution that
will give the route-server a "full" view of what the borders have.

On the borders, if Nicholas were to do like this:


!This is the MAIN view, the one for bestpath selection that will be used
!by the border router.
router bgp 65501
 neighbor a::a remote-as AAAA
 no neighbor a::a activate
 neighbor b::b remote-as BBBB
 no neighbor b::b activate
 neighbor c::c remote-as CCCC
 no neighbor c::c activate
!
 address-family ipv6
 network [announce your networks here]
 neighbor a::a activate
 neighbor b::b activate
 neighbor c::c activate
 exit-address-family
!
!This is the AAAA view for the route-server
router bgp 65501 view AAAA
 neighbor a::a remote-as AAAA
 no neighbor a::a activate
 neighbor route::server remote-as 65501
 no neighbor route::server activate
!
 address-family ipv6
 neighbor a::a activate
 neighbor a::a filter-list 2 out
 neighbor route::server activate
 neighbor route::server attribute-unchanged
!
!This is the BBBB view for the route-server
router bgp 65501 view BBBB
 neighbor b::b remote-as BBBB
 no neighbor b::b activate
 neighbor route::server remote-as 65501
 no neighbor route::server activate
!
 address-family ipv6
 neighbor b::b activate
 neighbor b::b filter-list 2 out
 neighbor route::server activate
 neighbor route::server attribute-unchanged
!
!This is the CCCC view for the route-server
router bgp 65501 view CCCC
 neighbor c::c remote-as CCCC
 no neighbor c::c activate
 neighbor route::server remote-as 65501
 no neighbor route::server activate
!
 address-family ipv6
 neighbor c::c activate
 neighbor c::c filter-list 2 out
 neighbor route::server activate
 neighbor route::server attribute-unchanged
!
ip as-path access-list 2 deny .*


We're simply creating a "view" for each of our eBGP peers.  Since it is
the only peer (besides the route-server) in that view, it will always be
the bestpath to any prefixes it sends us.  Since the route-server is
peered in all "views" but, not in the MAIN (bestpath) view, it will get
everything that the border router(s) get.  We use filter-list 2 (deny
*) outbound on the peers within our special views because we are already
announcing our routes to them in our MAIN view.

This *should* give the route-server *full* views of all your eBGP peers
(at least the ones you set up views for).  IMHO, this makes it a much more
useful utility to the general community since they will then get to see
ALL of the paths you see to a particular path vs just the selected
bestpath on each border router.

Note: You shouldn't have to change ANY of the configuration on the
route-server itself.  Simply remove the route-server from the MAIN view on
the border routers and create a view for each peer you want to appear in
route-server queries with [peer] and [route-server] being the only
configured neighbors in that view.

I've really got to cut back on the caffine!



---
John Fraizer              | High-Security Datacenter Services |
EnterZone, Inc            | Dedicated circuits 64k - 155M OC3 |
http://www.enterzone.net/ | Virtual, Dedicated, Colocation    |