[f-nsp] Foundry Router Software Wishlist

Thu Jun 28 06:26:36 EDT 2007

Hi Mike,
 excellent list.. Ive a few things and I'll probably email more when I have time.

I mentioned the BGP timer problem with Foundry 3 yrs ago I'm not sure why its not implemented. FYI it wont bring the session up until you enter a remote ASN, so the workaround I use is to put in the peer-group and other lines dfirst and ASN last.

One big bug bear that I havent seen as fixed (but I dont have the latest code so perhaps you can confirm) is that route-maps wont allow you to add more than 6 communities [in the route-map statement, the prefix can carry more if you append to a prefix that already has some communities].

They also need to be smarter with handling major BGP reset problems - so if you have 200 sessions on a box and something bad happens to reset most of them the box thinks it is okay to max out CPU to bring them all back up at once and has this weird thing where if for example you have customer sessions you see the 'announced prefix' counter take an age to drop to zero from 220000 before it will allow it to restart the session, as config allows you to deconfigure and reconfigure the peer in a second there must be a way to shortcut that and presumaly reduce the CPU usage that multiple thrashing customer BGP sessions (or iBGP sessions) can cause.

Steve

On Sat, Jun 23, 2007 at 10:53:26PM -0700, Mike Leber wrote:
> 
> I've been collecting together items for a Foundry wishlist and thought I'd
> send it to the list to help either get new ideas or plant the ideas in
> other peoples heads.  I know there are ugly work arounds for a lot of
> these, however the ugly workarounds aren't as clean as proper solutions.  
> Remember, it's a wishlist...
> 
> I've given you mine, what items would be on your wishlist?
> 
> * "no ipv6 source-route" command
> 
> Currently, source route is on by default for IPv6.  It's really bad, and
> should be able to be turned off router wide.  Cisco implements this
> command, Foundry should too ASAP.  For the sake of not having a security
> flaw on by default, it would also be great if the default was changed to
> "no ipv6 source-route".
> 
> * same newly configured session timer as cisco to avoid leaks
> 
> Foundry routers bring up BGP sessions insanely fast (which is cool), so
> fast as to cause leaks if you try to manually type in neighbor x.x.x.x
> remote-as y followed by a neighbor x.x.x.x peer-group blah.  If the peer
> is already configured the session will come up before the peer-group is
> applied and leaks will occur.  While we've overcome this by immediately
> shutting sessions and never ever typing new peer configurations into the
> router, it would be great if newly configured sessions had a long timer
> before they came up.  However, any fix shouldn't affect how quickly
> existing sessions come up.
> 
> I'm sure there will be some poor new to BGP + foundry networks that leak
> every time they set up a session, as a transit customer they probably will
> be prevented from causing damage by their providers prefix filters or as
> long as their peer didn't setup the other side of the session first.  
> However, we don't need people shooting themselves and others in the foot
> repeatedly with this.
> 
> * scp of configs with keys so you can automatically backup configurations
> 
> Currently there is no way to scp configs automatically without a password
> prompt even if you precopy ssh keys.  Why bother to implement scp only for
> people that want to manage their network via monkeys pounding keyboards
> (omg lol wtf!!!)?!?!?!
> 
> * ssh for remote command execution
> 
> On Ciscos you can rsh commands and get results back very cleanly without
> having to set terminal length and hard coding what a prompt looks like to
> figure out the end of the data.
> 
> We've got ssh, except missing the part of the RFC that specifies remote
> command execution, please fix asap.  Also remember the solution can't
> prompt for login in the middle of script.
> 
> * scp of partial config changes
> 
> On Ciscos you can rcp partial config changes to automate configuration
> management to add customers etc.
> 
> Without triangulating muliple servers please (SNMP, TFTP, and my uncles
> dog), lets be able to automatically upload small changes like adding a
> customer.  Also remember the solution can't prompt for login in the middle
> of a script.
> 
> * true subinterfaces
> 
> vlan interfaces interfaces are global and visible to all interfaces facing
> the Foundry "router", implicitly any 802.1q tagged physical interface ends
> up propagating any vlan tagged traffic to all vlan interfaces, which
> probably can be fixed via very care explicit denies, however this is not
> the same as non switch oriented Cisco routers such as GSRs.  This
> eliminates the potential for bleeding of vlans to between trunks, and
> makes for a very simple config.
> 
> For example on a GSR, it is trivial to have two different physical gige
> ports that both have switch trunks facing them, and to have the same
> 802.1q vlan number be used completely separately in a very simple and easy
> to understand format.
> 
> Example from a GSR:
> 
> interface GigabitEthernet3/1.100
>  encapsulation dot1Q 100
>  ip address a.a.a.a b.b.b.b
> 
> interface GigabitEthernet10/6.100
>  encapsulation dot1Q 100
>  ip address x.x.x.x y.y.y.y
> 
> * netconf
> 
> Heh, I've included all that, why not go for something that would be even
> nicer.  Oh, and remember, it must be able to be done from scripts running
> automated tasks on unix systems.
> 
> http://www.ops.ietf.org/netconf/
> 
> * more than 500 BGP sessions
> 
> Both IPv4 and IPv6 sessions count towards this limit, at major exchange
> points like AMS-IX and LINX, etc that have alot of members and use /23
> exchange prefixes (because they just have that many participants), you can
> expect to need more than 500 sessions on the attached routers in the
> future.  Oh and BTW, this needs to be handled gracefully and correctly so
> that BGP sessions don't timeout due to the large number of sessions (just
> saying this needs to be stress tested, since we've noticed that the route
> processor gets very loaded down starting up at just below 500 sessions,
> such that you can't log in for a while longer after a reboot than on
> routers without as many sessions (still insanely quick and nice compare to
> Cisco)).
> 
> 
> 
> weeeee...  thats my quick list so far.  whats on your list?! :)
> 
> Mike.
> 
> +----------------- H U R R I C A N E - E L E C T R I C -----------------+
> | Mike Leber           Direct Internet Connections   Voice 510 580 4100 |
> | Hurricane Electric     Web Hosting  Colocation       Fax 510 580 4151 |
> | mleber at he.net                                       http://www.he.net |
> +-----------------------------------------------------------------------+
> 
> 
> 
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

----- End forwarded message -----