[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[6bone] IPv6 route server
On Thu, 8 Aug 2002, Andy Furnell wrote:
> On Thu, Aug 08, 2002 at 04:30:12PM +0200, Nicolas DEFFAYET wrote:
> > >
> > > 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 can't do that for more than 50 neighbors...
> > If you check route servers on
> > http://www.traceroute.org/#Route%20Servers, the route server display
> > only best-paths of the remote routers or the best path from the
> > route-server...
> > Best Regards,
> > Nicolas DEFFAYET
> Maybe it's time to 'man peer-group'? *g*
> Andy Furnell
> [email protected]
Border2-BGP# man peer-group
% Unknown command.
I am very familiar with peer-groups and use them to great extent. They
would NOT work in this situation though. Peer-groups are view
specific. Since to achieve the ultimate goal (full views of each peer on
the route-server), we have to create individual views for each eBGP peer
that contain just that peer and the route-server, the use of the
peer-group statement would simply add additional config statements.
I realize that configuring individual views for each eBGP peer is a pain
in the behind and uses more memory than having a single "bestpath" main
view. The memory issue shouldn't be a problem though. We're under 500
prefixes in the v6 tables so, for 50 peers, that would be 25500 (25000 in
individual views and 500 selected in the MAIN view) for Zebra to keep
track of. Compared to 115K prefixes for each v4 view, this is nothing!
Additionally, adding a view and inserting a peer into that view is a
non-destructive task - IE; the peer will never know it happened, no
peering session bounce, blah blah blah. So, it's a matter of config
hassle. If you're "collecting tunnels" I guess this could be a daunting
task. If you peer with some disgression, it shouldn't be too bad. It's a
one-time task to convert existing peers and a few extra lines of config to
add a view for each new peer from that point forward.
John Fraizer | High-Security Datacenter Services |
EnterZone, Inc | Dedicated circuits 64k - 155M OC3 |
http://www.enterzone.net/ | Virtual, Dedicated, Colocation |