Sebastien Roy writes: > I'm sponsoring this fast-track for Erik Nordmark, the timer expires on > June 9th.
Looks good, but some nits: > We are introducing a new RTF_INDIRECT in <net/route.h>. This flag is useful > for routing daemons that do BGP plus OSPF/IS-IS since it can make handling > routing changes a lot more efficient. Great to hear, but can we have some detail on how to use this? Is it the network routes from BGP that must use this flag (to make the specified next hop address be "indirect"), or is it a flag set by the BGP (or even the IGP) to specify that a given entry is a special "host route" intended as a target for BGP routes? What exactly does the flag do? How is a route with this flag different? > We are adding an informational RTF_KERNEL flag for routes, for instance > interface routes, that are added by the kernel as part of configuring an IP > interface. Such routes can not be accidentally deleted by applications. RTF_KERNEL doesn't appear for ICMP redirect, even though that's processed by the kernel, right? > | EXPER_IP_DCE | Uncommitted | <inet/mib2.h> | There's probably a new MIB data structure that goes with this symbol. > No IRE_CACHE entries (UHA) entries will appear in netstat -ra, since the > implementation no longer has IRE_CACHE entries. > This project adds a new IRE_IF_CLONE type of routes. Those routes appear in > netstat -ra (but not without the 'a' option) with the new 'C' flag. Are these like the BSD clone entries (i.e., effectively ARP cache entries, with *only* on-link addresses represented), or are they something else? > The new implementation no longer has a ire_max_frag field, hence the output of > Maxfrg/PMTU in the netstat -rv output is no longer useful. We are removing > that > output. (Note that the details of the netstat output is not a stable > interface.) > > Currently Solaris handles IP interface MTU in odd ways in that it can be > set differently for local IP address prefix; this leaves it quite undefined > in what MTU is applied to multicast packets. > This project fixes that by applying the IP interface MTU per interface. As a > result ifconfig bge0:N mtu 1400 will fail with EINVAL. There's certainly been some customer confusion around routes and addresses with specified MTU. It's sometimes the case that users must deal with remote networks that have restricted MTUs *but* that don't support PMTU properly. What should those users be doing? (Reporting bugs against our PMTU implementation? Asking for an RFE? Yelling at the admin for that remote network?) > ENXIO will be returned to the sendto() system call. And received packets will > be dropped since they can't possibly match the interface index specified in > the > IP_BOUND_IF when the interface has been unplumbed. However, when the IP > address > (or interface index) which was use by the application reappears, then the > application's setting will be fully functional again. Interface indices can't normally disappear and then reappear, can they? (If they can, then I'd call that a "bug" rather than a "feature." SNMP requires that ifIndex is unique for a given engine invocation.) > The project extends the kernel's ability to handle multiple routes for the > same > prefix; currently the kernel only does some form of round robin for default > routes and the project extends that to all off-link routes (default, prefix, > and > host routes). We are adding an undocumented knob should there be a reason to > switch back to the old behavior in the field. Yay! What happens on forwarding? Round-robin is a bad answer for forwarding, as it ends up reordering packets. ECMP is a better answer for that case. (I agree that round-robin is best _if_ you can preserve state ... local connections can do that, but forwarding cases generally cannot.) > The project removes the usage of multidata from TCP/IP, but the interfaces > specified in PSARC/2004/594 and PSARC/2002/276 remain in the system. This part is confusing; could you please elaborate? Does the stack still generate MDT messages? If not, then how are those two previous projects not affected? (Doesn't this project just obsolete those two ... ?) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
