[f-nsp] Foundry Router Software Wishlist

[Mike Leber]

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 |
+-----------------------------------------------------------------------+