[f-nsp] Foundry Router Software Wishlist

[Vinny Abello]

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.

I have definitely experienced this and had it catch me off guard. I'm
careful now about how sessions are brought up. I think what's more
annoying is that even if you paste in a config, you have to clear the
peer afterwards so you'll still have this problem if you forget to clear
the peer after adding it to a peer-group.

> * 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?! :)

One major gripe for me is line wrapping. On Cisco if you type beyond the
end of the line, it keeps going and shifts the text. On Foundry it jumps
to the next line which is fine, but if you hit the up arrow to repeat a
command, you cannot backspace and further than the beginning of the
second line! :(

-- 

Vinny Abello
Network Engineer
vinny at tellurian.com
(973)940-6100
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0  E935 5325 FBCB 0100 977A

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN

"Courage is resistance to fear, mastery of fear - not absence of fear"
-- Mark Twain