From sebastien.roy@oracle.com Mon Apr 12 13:17:28 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CKHRlX026613 for ; Mon, 12 Apr 2010 13:17:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CKHOa1009957 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Apr 2010 15:17:27 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00E095P2ZK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 13:17:26 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S008VF5P2BOD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 13:17:26 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3CKHQ8M021718 for ; Mon, 12 Apr 2010 20:17:26 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3CKHPiw016662 for ; Mon, 12 Apr 2010 20:17:25 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 168298041271103443; Mon, 12 Apr 2010 13:17:23 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Apr 2010 13:17:22 -0700 Date: Mon, 12 Apr 2010 16:17:20 -0400 From: Sebastien Roy Subject: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] To: PSARC-ext@sun.com Cc: sowmini.varadhan@oracle.com Message-id: <4BC37FD0.3090301@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BC37FD5.0202:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 11100 I'm sponsoring this fast-track for Sowmini Varadhan, it times on on 04/19/2010. ipadm(1m) tunables for setting End-System Model. Requested release binding: Minor Summary: ------- This case proposes a solution for 6938553 Support user-friendly ipadm tunables for configuring end-system model by adding a new 'hostmodel' property to ipadm(1m). Details: -------- The fix for CR 4173841 ("Packet goes out with source IP address of another interface") provides kernel support for the tunables that control transmit/receive side behavior for IP packets as defined in Section 3.3.4.5 of [RFC1122]. In addition to providing tunables for supporting strong and weak end-system models, the tunables introduced by CR 4173841 allow for a number of intermediate settings through six separate permutations for source and destination multihoming tunables in ndd. These ndd tunables are low-level knobs that cover many more choices than the anticipated common use-case, and while they allow for possible feature additions in the future, the common use-cases should be made accessible through Stable ipadm tunables. This case proposes a new "hostmodel" property for the IP module that can have 3 settings: strong, weak and src-priority. Some sample incantations for setting the tunable are provided in the Examples section. The Stability of the 'hostmodel' property is "Committed". The semantics for the value of the hostmodel property are hostmodel semantics ----------------------------------------------------------------------------- strong strong ES as defined in Section 3.3.4.2 of [RFC 1122]. In particular, this corresponds to the setting of ip_strict_dst_multihoming = 1 through ndd, with the additional requirement that packets originated from the host will only be sent out on interfaces where the IP source address of the outgoing packet is an address configured on the outgoing interface. weak weak ES as defined in Section 3.3.4.2 of [RFC 1122]. In particular, this is equivalent to setting ip_strict_dst_multihoming = 0 through ndd on Solaris 10 and earlier releases. src-priority Equivalent to the weak end-system model in receive behavior, i.e., a packet will be accepted on any interface, as long as the IP destination of the packet is configured on one of the host's interfaces. When transmitting a packet, if the multiple routes for the IP destination in the packet are available, the system will prefer routes where the IP source address in the packet is configured on the outgoing interface. If no such route is available, the system will fall back to selecting the "best" route as with the weak ES case. Examples -------- On a machine with addresses # ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 ce0/_a static ok 20.1.1.124/24 ce1/? dhcp ok 10.8.57.124/24 lo0/v6 static ok ::1/128 ce1/? static ok fe80::203:baff:fe75:79a7/10 ce1/? addrconf ok 2002:a08:39f0:1:203:baff:fe75:79a7/64 ce1/? dhcp ok 2001:db8:1:2::4585/128 # ipadm show-prop ip PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE ipv4 forwarding rw off -- off on,off ipv4 ttl rw 255 -- 255 1-255 ipv6 forwarding rw off -- off on,off ipv6 hoplimit rw 255 -- 255 1-255 ipv6 hostmodel rw weak -- weak strong, src-priority, weak ipv4 hostmodel rw weak -- weak strong, src-priority, weak The current settings for hostmodel for IPv4 packets is (default setting) 'weak'. In this mode, if the currently available IPv4 default routes are: # netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- : default 20.1.1.1 UG 1 0 default 10.8.57.248 UG 2 8 ce1 : A packet sent to an offlink destination could be sent to either 20.1.1.1 (through ce1) or to 10.8.57.248 (through ce0) in this configuration. e.g., the command # traceroute -s 20.1.1.124 12.1.2.3 results in the packet trace: # snoop -d ce1 -r 20.1.1.124 -> 12.1.2.3 UDP D=33437 S=35231 LEN=20 Similarly, a packet with IPv4 destination address 20.1.1.124 would be accepted on either ce1 or ce0. However, in the strong ES mode: # ipadm set-prop -p hostmodel=strong ipv4 # ipadm show-prop -p hostmodel ipv4 PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE ipv4 hostmodel rw strong strong weak strong, src-priority, weak an incoming packet with an IPv4 destination of 20.1.1.124 would only be accepted if, and only if, it was received on ce1. Similarly, an outgoing packet with IPv4 src 20.1.1.124 would only be sent out if a route to the IPv4 destination existed on ce1. Thus, if the only routes available were # netstat -rnf inet Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 10.8.57.248 UG 1 2354 ce1 10.8.57.0 10.8.57.124 U 2 1946 ce1 20.1.1.0 20.1.1.124 U 2 0 ce0 127.0.0.1 127.0.0.1 UH 2 2996 lo0 the following would be observed: # traceroute -s 20.1.1.124 12.1.2.3 traceroute to 12.1.2.3 (12.1.2.3) from 20.1.1.124, 30 hops max, 40 byte packets 1 traceroute: sendto: No route to host traceroute: wrote 12.1.2.3 40 chars, ret=-1 The traceroute fails because the outgoing packet with IPv4 src 20.1.1.124 cannot find any route for 12.1.2.3 through ce1. The src-priority hostmodel can be set by the command # ipadm set-prop -p hostmodel=src-priority ipv4 # ipadm show-prop PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE ipv4 forwarding rw off -- off on,off ipv4 ttl rw 255 -- 255 1-255 ipv6 forwarding rw off -- off on,off ipv6 hoplimit rw 255 -- 255 1-255 ipv6 hostmodel rw weak -- weak strong, src-priority, weak ipv4 hostmodel rw src-priority src-priority weak strong, src-priority, weak In this model, the command # traceroute -s 20.1.1.124 12.1.2.3 will first attempt to find a route for 12.1.2.3 through ce0, and when none is found, route selection will fall back to sending the packet through ce1. The default route through ce0 will be selected for packets having source address 20.1.1.124. The property value may be reset as follows. # ipadm reset-prop -p hostmodel ipv4 # ipadm show-prop -p hostmodel ipv4 PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE ipv4 hostmodel rw weak -- weak strong, src-priority, weak Proposed man page changes: -------------------------- --- ipadm.1m.txt.orig Thu Apr 1 12:58:39 2010 +++ ipadm.1m.txt.new Fri Apr 9 17:27:47 2010 @@ -866,7 +866,9 @@ The current value of the property. If the value is not set, it is shown as --. If it is unknown, the value is - shown as ?. + shown as ?. If the current value of the property is not + in the set of listed POSSIBLE values, the keyword + "custom" will be displayed. PERSISTENT @@ -880,8 +882,9 @@ POSSIBLE - A comma-separated list of the values the property can - have. If the values span a numeric range, min - max + A comma-separated list of the values for the property + setting to be used with the 'set-prop' sub-command. + If the values span a numeric range, min - max might be shown as a shorthand. If the possible values are unknown, ? will be shown or if they are unbounded, -- will be shown. @@ -922,6 +925,22 @@ The following protocol properties are supported: + hostmodel(ipv4), hostmodel(ipv6) + Control send/receive behavior for IP packets on a multihomed + system. The value of 'hostmodel' may be set to + 'strong' or 'weak', corresponding to the equivalent end-system + model definitons of RFC 1122. In addtion, a third + value of 'src-priority' is also supported. In the 'src-priority' + hostmodel, a packet will be accepted on any interface, as long as + the packet's destination IP address is configured and marked UP + on one of the host's interfaces. When transmitting a + packet, if the multiple routes for the IP destination in + the packet are available, the system will prefer routes + where the IP source address in the packet is configured on + the outgoing interface. If no such route is available, the + system will fall back to selecting the "best" route as + with the weak ES case. + ttl(ipv4), hoplimit(ipv6) Specifies the value that will be set for ttl/hoplimit field of IPv4 or IPv6 header. Can be used to prevent the system from reaching @@ -1343,3 +1362,8 @@ S. Routhier, Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006 + + Braden, R., RFC 1122, Requirements for Internet Hosts - Com- + munication Layers, Information Sciences Institute, Univer- + sity of Southern California, October 1989. + References: ---------- [RFC1122] Braden, R., RFC 1122, Requirements for Internet Hosts - Communication Layers, Information Sciences Institute, University of Southern California, October 1989. From carlsonj@workingcode.com Mon Apr 12 13:48:08 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3CKm8Mr027246 for ; Mon, 12 Apr 2010 13:48:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3CKm7xM019740 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Apr 2010 13:48:08 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00709747MT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 14:48:07 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S007A0747F700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 14:48:07 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3CKjNRZ029801 for ; Mon, 12 Apr 2010 20:48:07 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-4054710 for PSARC-ext@sun.com; Mon, 12 Apr 2010 20:48:06 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-84828244 for PSARC-ext@sun.com; Mon, 12 Apr 2010 20:48:06 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-29859043 for PSARC-ext@sun.com; Mon, 12 Apr 2010 20:48:05 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3CKlwCG003255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2010 16:47:59 -0400 (EDT) Date: Mon, 12 Apr 2010 16:47:58 -0400 From: James Carlson Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC37FD0.3090301@oracle.com> To: Sebastien Roy Cc: PSARC-ext@sun.com, sowmini.varadhan@oracle.com Message-id: <4BC386FE.5090106@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.128sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC37FD0.3090301@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2133 Sebastien Roy wrote: > This case proposes a new "hostmodel" property for the IP module that > can have 3 settings: strong, weak and src-priority. Some sample > incantations for setting the tunable are provided in the Examples > section. It looks like there's a fourth (reportable, not settable) value documented in the man page changes: "custom". > weak weak ES as defined in Section 3.3.4.2 of [RFC > 1122]. In particular, this is equivalent to > setting ip_strict_dst_multihoming = 0 through ndd > on Solaris 10 and earlier releases. > > src-priority Equivalent to the weak end-system model in > receive behavior, i.e., a packet will be accepted > on any interface, as long as the IP destination > of the packet is configured on one of the host's It may be necessary to document (somewhere, perhaps not completely in man pages) the complicated things that can happen when you use anything other than "weak." > interfaces. When transmitting a packet, if the > multiple routes for the IP destination in the > packet are available, the system will prefer > routes where the IP source address in the packet > is configured on the outgoing interface. If no Just for clarity: what defines the "multiple routes" case? I suspect that the answer is that we search for best match first and *then* select one route from a set of equivalent ones. If there's only one best route, then we pick that without regard to source address. In other words, if hme0 has only a default route, and hme1 has a specific subnet route, we'll send out hme1 when we match the specific subnet route destination, even if the source address is hme0's. Correct? If this is the case, then why not just make src-priority the default? It doesn't seem to have any effect on correctness from a routing point of view, and potentially affects only load-spreading in some narrow cases when not using vni interfaces. -- James Carlson 42.703N 71.076W From sowmini.varadhan@oracle.com Mon Apr 12 17:33:33 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3D0XXqj001799 for ; Mon, 12 Apr 2010 17:33:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3D0XXnJ013966 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Apr 2010 19:33:33 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0S00905HJX2K00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 18:33:33 -0600 (MDT) Received: from quasimodo.East.Sun.COM ([129.148.174.94]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0S007TEHJWSL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Apr 2010 18:33:33 -0600 (MDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3D0R7Nw012047; Mon, 12 Apr 2010 20:27:07 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3D0R6W3012046; Mon, 12 Apr 2010 20:27:06 -0400 (EDT) Date: Mon, 12 Apr 2010 20:27:06 -0400 From: sowmini.varadhan@oracle.com Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC386FE.5090106@workingcode.com> To: James Carlson Cc: Sebastien Roy , psarc-ext@sun.com, sowmini.varadhan@oracle.com Message-id: <20100413002706.GC11987@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@oracle.com using -f User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 3335 On (04/12/10 16:47), James Carlson wrote: > > Sebastien Roy wrote: > > This case proposes a new "hostmodel" property for the IP module that > > can have 3 settings: strong, weak and src-priority. Some sample > > incantations for setting the tunable are provided in the Examples > > section. > > It looks like there's a fourth (reportable, not settable) value > documented in the man page changes: "custom". Yes, I believe that was flagged in the man page updates (no?). In case it was missed in the fast-track, here's what was intended: --- ipadm.1m.txt.orig Thu Apr 1 12:58:39 2010 +++ ipadm.1m.txt.new Fri Apr 9 17:27:47 2010 @@ -866,7 +866,9 @@ The current value of the property. If the value is not set, it is shown as --. If it is unknown, the value is - shown as ?. + shown as ?. If the current value of the property is not + in the set of listed POSSIBLE values, the keyword + "custom" will be displayed. Were you looking of some more specific wording? > > It may be necessary to document (somewhere, perhaps not completely in > man pages) the complicated things that can happen when you use anything > other than "weak." yes, good suggestion. We'll put that into the Sys Admin docs.. > > interfaces. When transmitting a packet, if the > > multiple routes for the IP destination in the > > packet are available, the system will prefer > > routes where the IP source address in the packet > > is configured on the outgoing interface. If no > > Just for clarity: what defines the "multiple routes" case? I suspect > that the answer is that we search for best match first and *then* select > one route from a set of equivalent ones. "Multiple routes" implies multiple, (otherwise) equivalent routes and perhaps the man page and associated docs should say multiple equivalent routes. However, in src-priority mode, the definition of "best" match is modified thus: - first look up the longest match that also satisifes the source-address/interface constraint (i.e., routing table lookup as in the strong ES mode). - if that fails, then remove the source-address/interface constraint and find the longest match for the dst. > If there's only one best > route, then we pick that without regard to source address. > In other words, if hme0 has only a default route, and hme1 has a > specific subnet route, we'll send out hme1 when we match the specific > subnet route destination, even if the source address is hme0's. Correct? no, in the example above, the first lookup would find hme0 because it is the longest match that also satisfies the interface constraint. And the documentation should make sure to clarify this with an example.. > If this is the case, then why not just make src-priority the default? > It doesn't seem to have any effect on correctness from a routing point > of view, and potentially affects only load-spreading in some narrow > cases when not using vni interfaces. Well, in addition to the load-spreading problem, the longest match may be rejected in preference for a src-match, so we've not made it the default, in the interest of being cautious. --Sowmini From carlsonj@workingcode.com Tue Apr 13 05:06:27 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DC6RAU029856 for ; Tue, 13 Apr 2010 05:06:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DC6QdC009265 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Apr 2010 07:06:27 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T0030HDMQDI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 05:06:26 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00H5EDMO3V20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 05:06:25 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3DBuceG011268 for ; Tue, 13 Apr 2010 12:06:24 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-1651304 for PSARC-ext@sun.com; Tue, 13 Apr 2010 12:06:24 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-128934828 for PSARC-ext@sun.com; Tue, 13 Apr 2010 12:06:23 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-23355537 for PSARC-ext@sun.com; Tue, 13 Apr 2010 12:06:23 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3DC6IPn016778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 08:06:19 -0400 (EDT) Date: Tue, 13 Apr 2010 08:06:18 -0400 From: James Carlson Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <20100413002706.GC11987@quasimodo.East.Sun.COM> To: sowmini.varadhan@oracle.com Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <4BC45E3A.6060304@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-1.1/5.0, scanned in 0.177sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 3931 sowmini.varadhan@oracle.com wrote: > On (04/12/10 16:47), James Carlson wrote: >> Sebastien Roy wrote: >>> This case proposes a new "hostmodel" property for the IP module that >>> can have 3 settings: strong, weak and src-priority. Some sample >>> incantations for setting the tunable are provided in the Examples >>> section. >> It looks like there's a fourth (reportable, not settable) value >> documented in the man page changes: "custom". > > Yes, I believe that was flagged in the man page updates (no?). In case > it was missed in the fast-track, here's what was intended: That's all that was missed. In the quoted text above, it says "3" settings, but there are actually 4. It's just a nit on the fast-track materials. > However, in src-priority mode, the definition of "best" match is modified > thus: > - first look up the longest match that also satisifes the > source-address/interface constraint (i.e., routing table lookup as in > the strong ES mode). > - if that fails, then remove the source-address/interface constraint > and find the longest match for the dst. I might be straying outside of ARC review (and feel free to redirect this to networking-discuss), but that doesn't sound quite right to me. Consider this network: +--------+ +--------+ | | | | <---A--->+ Host 1 +<---B--->+ Host 2 | | | | | +--------+ +--------+ Network A is x.x.x.0/24, and connects to "the Internet." Network B is an internal network, say x.x.y.0/24. This means that Host 1 will have a default route pointing somewhere on network A, and an interface route pointing to x.x.y.0/24 for network B. Host 2 will have a default route pointing to Host 1's address on network B. What happens if Host 2 sends a packet to Host 1's address on network A, and then Host 1 goes to respond? It sounds like you're saying that we'll discover the default route _before_ the interface route, and we'll see that the interface address matches and thus send the packet (erroneously) out on interface A. This will cause forwarding loops with normal routing protocols. Does the definition of "src-priority" mode mean that I can't get "source preference" behavior with the existing variables? It's "source preference" (i.e., if there are multiple matching routes that are exactly equivalent -- same prefix length -- then choose the one with an interface with the same source, and if no such interface, then choose one with the same subnet configured as the source, and if no such, then pick any) that I was hoping for, not "source first." For what it's worth, I think it's "source preference" that fixes the dual-homed problem. >> If there's only one best >> route, then we pick that without regard to source address. >> In other words, if hme0 has only a default route, and hme1 has a >> specific subnet route, we'll send out hme1 when we match the specific >> subnet route destination, even if the source address is hme0's. Correct? > > no, in the example above, the first lookup would find hme0 because it > is the longest match that also satisfies the interface constraint. > > And the documentation should make sure to clarify this with an example.. Indeed. It doesn't sound like a generally usable mode to me. >> If this is the case, then why not just make src-priority the default? >> It doesn't seem to have any effect on correctness from a routing point >> of view, and potentially affects only load-spreading in some narrow >> cases when not using vni interfaces. > > Well, in addition to the load-spreading problem, the longest match > may be rejected in preference for a src-match, so we've not made > it the default, in the interest of being cautious. Rejecting longest match means that it just doesn't work with IP routing. -- James Carlson 42.703N 71.076W From sowmini.varadhan@oracle.com Tue Apr 13 06:09:50 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DD9nAc000782 for ; Tue, 13 Apr 2010 06:09:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3DD9ll0051247 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Apr 2010 07:09:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00J93GKDF000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 06:09:49 -0700 (PDT) Received: from quasimodo.East.Sun.COM ([129.148.174.94]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00HFKGK93T60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 06:09:46 -0700 (PDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3DCuvPl013598; Tue, 13 Apr 2010 08:56:57 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3DCuvGS013597; Tue, 13 Apr 2010 08:56:57 -0400 (EDT) Date: Tue, 13 Apr 2010 08:56:57 -0400 From: sowmini.varadhan@oracle.com Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC45E3A.6060304@workingcode.com> To: James Carlson Cc: Sebastien Roy , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <20100413125657.GA13579@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@oracle.com using -f User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 2972 On (04/13/10 08:06), James Carlson wrote: > > > > Yes, I believe that was flagged in the man page updates (no?). In case > > it was missed in the fast-track, here's what was intended: > > That's all that was missed. In the quoted text above, it says "3" > settings, but there are actually 4. It's just a nit on the fast-track > materials. Ok, nit shall be fixed. > > However, in src-priority mode, the definition of "best" match is modified > > thus: > > - first look up the longest match that also satisifes the > > source-address/interface constraint (i.e., routing table lookup as in > > the strong ES mode). > > - if that fails, then remove the source-address/interface constraint > > and find the longest match for the dst. > > I might be straying outside of ARC review (and feel free to redirect > this to networking-discuss), but that doesn't sound quite right to me. > Consider this network: > > +--------+ +--------+ > | | | | > <---A--->+ Host 1 +<---B--->+ Host 2 | > | | | | > +--------+ +--------+ > > Network A is x.x.x.0/24, and connects to "the Internet." Network B is > an internal network, say x.x.y.0/24. > > This means that Host 1 will have a default route pointing somewhere on > network A, and an interface route pointing to x.x.y.0/24 for network B. > Host 2 will have a default route pointing to Host 1's address on network B. > > What happens if Host 2 sends a packet to Host 1's address on network A, > and then Host 1 goes to respond? It sounds like you're saying that Host 2 would presumably have used the src address x.x.y.host2. So when host1 go to respond, we'd look up a route in the strong-es mode first, and assuming that there are no bugs in the src-address selection (there were none when I tested this!) code, host1 would pick x.x.y.host1 as the src address, B as the outgoing interface, and lookup a route for dst/mask = x.x.y.host2/24, interface = B. And we would find the interface route over the default route. > we'll discover the default route _before_ the interface route, and we'll > see that the interface address matches and thus send the packet > (erroneously) out on interface A. I don't see how this would happen. Could you clarify? > preference" (i.e., if there are multiple matching routes that are > exactly equivalent -- same prefix length -- then choose the one with an > interface with the same source, and if no such interface, then choose But that *is* exactly what it is. Note that, if, for whatever reason, host1 was trying to send out a packet to x.x.y.host2 with src address x.x.x.host1, then yes, we would send it out on A instead of B. But then again, when you pick a src of x.x.x.host1 and send it on B, how would you know that there are no ingress filters on B that will drop your packet because your src address looks spoofed as defined in rfc 3704? --Sowmini From carlsonj@workingcode.com Tue Apr 13 07:01:17 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DE1H3l001490 for ; Tue, 13 Apr 2010 07:01:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DE1HRo008797 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Apr 2010 07:01:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00D1HIY4JJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 07:01:16 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T000D0IY4XIE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 07:01:16 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3DDwrb4013267 for ; Tue, 13 Apr 2010 14:01:16 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-1659509 for PSARC-ext@sun.com; Tue, 13 Apr 2010 14:01:16 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-131474589 for PSARC-ext@sun.com; Tue, 13 Apr 2010 14:01:15 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-23670711 for PSARC-ext@sun.com; Tue, 13 Apr 2010 14:01:15 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3DE0TF2018485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 10:00:30 -0400 (EDT) Date: Tue, 13 Apr 2010 10:00:29 -0400 From: James Carlson Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <20100413125657.GA13579@quasimodo.East.Sun.COM> To: sowmini.varadhan@oracle.com Cc: Sebastien Roy , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <4BC478FD.80109@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.294sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> <20100413125657.GA13579@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 4340 sowmini.varadhan@oracle.com wrote: > On (04/13/10 08:06), James Carlson wrote: >> This means that Host 1 will have a default route pointing somewhere on >> network A, and an interface route pointing to x.x.y.0/24 for network B. >> Host 2 will have a default route pointing to Host 1's address on network B. >> >> What happens if Host 2 sends a packet to Host 1's address on network A, >> and then Host 1 goes to respond? It sounds like you're saying that > > Host 2 would presumably have used the src address x.x.y.host2. Yes. > So when host1 go to respond, we'd look up a route in the strong-es mode > first, and assuming that there are no bugs in the src-address selection > (there were none when I tested this!) code, host1 would pick x.x.y.host1 > as the src address, B as the outgoing interface, and lookup a route for > dst/mask = x.x.y.host2/24, interface = B. And we would find the > interface route over the default route. No. If Host 2 is using either TCP, SCTP, or ICMP, this isn't true. It's also not true if Host 1 has an actually RFC 1122 compliant implementation of UDP, and sets its source IP address in its replies to match the destination in the original request. The obvious problem, though, is with TCP. There's no way Host 1 gets to choose a new source address with any connection-oriented protocol, so this can't work. >> we'll discover the default route _before_ the interface route, and we'll >> see that the interface address matches and thus send the packet >> (erroneously) out on interface A. > > I don't see how this would happen. Could you clarify? TCP? >> preference" (i.e., if there are multiple matching routes that are >> exactly equivalent -- same prefix length -- then choose the one with an >> interface with the same source, and if no such interface, then choose > > But that *is* exactly what it is. If it's at all possible to choose a shorter prefix instead of a longer one due to the operation of this "src-priority" mode, then I disagree. The only sort of "src" mode I would like to use (and that I expected to see implemented one day) is one where we always pick the longest prefix -- so that routing still works properly and doesn't result in unexpected forwarding loops -- but which is able to choose wisely among multiple prefixes of exactly the same length. That's exactly the multi-homing problem. I have two addresses (call them "A" and "B") from two different ISPs, and these are configured through two separate interfaces. I have default routes pointing to both interfaces, because both of those interfaces go to "the Internet." All default routes are equal in prefix length (zero), so when I hit the default, I see I have two of them. I would like to prefer that when I'm sending from the "A" address, I send packets out through the "A" interface. (More generally, when the source is anywhere inside the "A" subnet, I want to send through the "A" interface if possible.) When I match a single more specific route, I expect the packet to go there, regardless of source. I would be shocked to see the packet hijacked and sent out some other interface merely because the source address happens to be equal. I have a hard time understanding how such a mode would be useful. (And why someone wanting behavior like this wouldn't just configure Strong ES instead, as it sounds like that's what they're really after.) > Note that, if, for whatever reason, host1 was trying to send out a > packet to x.x.y.host2 with src address x.x.x.host1, then yes, we would > send it out on A instead of B. But then again, when you pick a src > of x.x.x.host1 and send it on B, how would you know that there are > no ingress filters on B that will drop your packet because your src > address looks spoofed as defined in rfc 3704? I'm not sure I follow. What's the difference between spoofing and normal IP routing? Can you clarify how that's an issue here? In any event, what you're suggesting leads directly to a forwarding loop. If Host 1 sends the packet out on network A, then the router it sends it to will find that Host 2 is reachable only through Host 1. It'll send the packet back to Host 1, which will then erroneously forward it back out on network A -- looping until the TTL expires. -- James Carlson 42.703N 71.076W From sowmini.varadhan@oracle.com Tue Apr 13 07:57:11 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DEvA7C006404 for ; Tue, 13 Apr 2010 07:57:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3DEvAfW005592 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Apr 2010 08:57:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00G09LJAE100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 07:57:10 -0700 (PDT) Received: from quasimodo.East.Sun.COM ([129.148.174.94]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T00EQILJ9F420@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 07:57:10 -0700 (PDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3DEiLFN013858; Tue, 13 Apr 2010 10:44:21 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3DEiLMI013857; Tue, 13 Apr 2010 10:44:21 -0400 (EDT) Date: Tue, 13 Apr 2010 10:44:21 -0400 From: sowmini.varadhan@oracle.com Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC478FD.80109@workingcode.com> To: James Carlson Cc: Sebastien Roy , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <20100413144421.GC13579@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> <20100413125657.GA13579@quasimodo.East.Sun.COM> <4BC478FD.80109@workingcode.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@oracle.com using -f User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 3879 On (04/13/10 10:00), James Carlson wrote: > > So when host1 go to respond, we'd look up a route in the strong-es mode > > first, and assuming that there are no bugs in the src-address selection > > (there were none when I tested this!) code, host1 would pick x.x.y.host1 > > as the src address, B as the outgoing interface, and lookup a route for > > dst/mask = x.x.y.host2/24, interface = B. And we would find the > > interface route over the default route. > > No. If Host 2 is using either TCP, SCTP, or ICMP, this isn't true. > It's also not true if Host 1 has an actually RFC 1122 compliant > implementation of UDP, and sets its source IP address in its replies to > match the destination in the original request. : > If it's at all possible to choose a shorter prefix instead of a longer > one due to the operation of this "src-priority" mode, then I disagree. : > When I match a single more specific route, I expect the packet to go > there, regardless of source. I would be shocked to see the packet > hijacked and sent out some other interface merely because the source > address happens to be equal. I have a hard time understanding how such > a mode would be useful. (And why someone wanting behavior like this > wouldn't just configure Strong ES instead, as it sounds like that's what > they're really after.) Even in strong ES mode, if the sending host (for whatever reason) picked a src of x.x.x.host1, and dst x.x.x.host2 for a packet it originated, why wouldn't we end up with the routing loop that you flag below? > > Note that, if, for whatever reason, host1 was trying to send out a > > packet to x.x.y.host2 with src address x.x.x.host1, then yes, we would > > send it out on A instead of B. But then again, when you pick a src > > of x.x.x.host1 and send it on B, how would you know that there are > > no ingress filters on B that will drop your packet because your src > > address looks spoofed as defined in rfc 3704? > > I'm not sure I follow. What's the difference between spoofing and > normal IP routing? Can you clarify how that's an issue here? Sitting on host1, if I have a packet with src = x.x.x.host1, dst = x.x.y.host2, how do I know that there is no ingress filter in the path "B" that would drop my packet (per rfc 3704) because x.x.x.host1 is not an address on subnet "B"? the intended purpose of the "src-priority" model is this: if there are multiple routes for the same dst/prefix, we prefer the routes that give a src-addr match first. If no such routes are available, instead of dropping the packet, we pick a route as in the weak hostmodel case. In the case where there is a shorter matching route that allows a srcaddr match (the default route in your example), we prefer that over a possible longer-matching prefix on the assumption that the shoter-matching/default router may have other paths for the dst that would not be choked by rfc3704-based filters. > In any event, what you're suggesting leads directly to a forwarding > loop. If Host 1 sends the packet out on network A, then the router it > sends it to will find that Host 2 is reachable only through Host 1. > It'll send the packet back to Host 1, which will then erroneously > forward it back out on network A -- looping until the TTL expires. Not actually. Since this is hostmodel behavior, it does not apply to forwarded packets- thus if/when the packet loops back to host1 the first time (host1 -> rtr -> host1) it's a forwarded packet, as far as host1 is concerned. Thus it would not be subject to the hostmodel solution proposed here, and would instead get forwarded down B (based on longest prefix match). If there was an ingress filter on B, the packet would get dropped, but that would happen only if the default router for host1 itself did not have any other path for x.x.y.0/24 other than the doomed one through host1 itself. --Sowmini From carlsonj@workingcode.com Tue Apr 13 08:31:43 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3DFVhWW010450 for ; Tue, 13 Apr 2010 08:31:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3DFOvDb000353 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Apr 2010 10:31:40 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0T00515N4RI000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 08:31:39 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0T0000SN4QFT20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Apr 2010 08:31:38 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3DFT3m1019174 for ; Tue, 13 Apr 2010 15:31:38 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-4116333 for PSARC-ext@sun.com; Tue, 13 Apr 2010 15:31:38 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-131706119 for PSARC-ext@sun.com; Tue, 13 Apr 2010 15:31:38 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-10183210 for PSARC-ext@sun.com; Tue, 13 Apr 2010 15:31:37 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3DFUvBw019767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 11:30:58 -0400 (EDT) Date: Tue, 13 Apr 2010 11:30:57 -0400 From: James Carlson Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <20100413144421.GC13579@quasimodo.East.Sun.COM> To: sowmini.varadhan@oracle.com Cc: Sebastien Roy , PSARC-ext@sun.com, networking-discuss@opensolaris.org Message-id: <4BC48E31.50003@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-1.1/5.0, scanned in 0.132sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> <20100413125657.GA13579@quasimodo.East.Sun.COM> <4BC478FD.80109@workingcode.com> <20100413144421.GC13579@quasimodo.East.Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 7043 sowmini.varadhan@oracle.com wrote: > On (04/13/10 10:00), James Carlson wrote: >> When I match a single more specific route, I expect the packet to go >> there, regardless of source. I would be shocked to see the packet >> hijacked and sent out some other interface merely because the source >> address happens to be equal. I have a hard time understanding how such >> a mode would be useful. (And why someone wanting behavior like this >> wouldn't just configure Strong ES instead, as it sounds like that's what >> they're really after.) > > Even in strong ES mode, if the sending host (for whatever reason) > picked a src of x.x.x.host1, and dst x.x.x.host2 for a packet it > originated, why wouldn't we end up with the routing loop that you flag > below? I'm confused about the case you're suggesting, but I don't think it happens. Host2 (connected only to network B in my example) sending to Host1's A-side address would find that its packets are dropped because they don't exactly match the address on the local receiving interface (on network B), and Strong ES disallows that. I think you're talking about a case where Host1 chooses to bind its A-side address and then talk to Host2. Such a packet would (I expect) ordinarily be sent through the B network to reach Host2, but then replies from Host2 would be dropped as above. Strong ES guarantees a lack of connectivity (if nothing else). If Host1 were set up for Strong ES and really did erroneously send a packet destined for Host2 out onto network A (I don't see why it would do that), then the next hop router on network A would forward that back to Host1. At that point, it's unclear to me if we get a drop or a loop, because I don't understand why Host1 would ignore its own routing table even with Strong ES enabled. Ignoring standard IP routing seems like a mistake to me. >>> Note that, if, for whatever reason, host1 was trying to send out a >>> packet to x.x.y.host2 with src address x.x.x.host1, then yes, we would >>> send it out on A instead of B. But then again, when you pick a src >>> of x.x.x.host1 and send it on B, how would you know that there are >>> no ingress filters on B that will drop your packet because your src >>> address looks spoofed as defined in rfc 3704? >> I'm not sure I follow. What's the difference between spoofing and >> normal IP routing? Can you clarify how that's an issue here? > > Sitting on host1, if I have a packet with src = x.x.x.host1, dst = x.x.y.host2, > how do I know that there is no ingress filter in the path "B" that would > drop my packet (per rfc 3704) because x.x.x.host1 is not an address on > subnet "B"? You can't know. But it doesn't matter. If such a filter were installed, then Host2 would be unable to communicate with ANYBODY outside of network B. Such a filter would make all routed packets destined for Host2 drop, and network B (in the diagram I gave) was Host2's only connection to the world. No communication == you got what you wanted (or deserved) for configuring such a filter. > the intended purpose of the "src-priority" model is this: if there are > multiple routes for the same dst/prefix, we prefer the routes that give > a src-addr match first. If no such routes are available, instead of > dropping the packet, we pick a route as in the weak hostmodel case. That's how you've defined it to operate. It doesn't describe to me how it might be used. Can you give an example where it would work properly, but the "source preference" model I suggested would not work? > In the case where there is a shorter matching route that allows > a srcaddr match (the default route in your example), we prefer that > over a possible longer-matching prefix on the assumption that the > shoter-matching/default router may have other paths for the dst that > would not be choked by rfc3704-based filters. I still don't get what problem this mechanism solves. An RFC 3704 filter would naturally exist at some sort of network administrative boundary, when you (the filtering party) *know* that the guy on the other side shouldn't be doing any routing. He's a stub network to you, so you know his source addresses are constrained. In the "source preference" case I cited, that's neatly solved by having two default routes -- equal prefix length -- pointing at two different ISPs, each possibly doing RFC 3704 filtering on our source addresses. When we send packets (either generated locally or forwarded) to the Internet, we see the two default routes, equal prefix, and choose among them properly based on source address. Packets we send always end up on the right interface. If there are any more specific routes then either (a) the user knows what he's doing and points those routes where they go, (b) the user provides multiple such specific routes so that the source preference is obeyed, or (c) the user is clueless and gets what he asked for, but not what he wanted. I don't see how you can save the user from RFC 3704 issues by forwarding in direct contradiction of the standard IP forwarding rules, but I *do* see how you can form long-lived forwarding loops or really confused routing by doing so. Thus, I don't think the current design makes sense. >> In any event, what you're suggesting leads directly to a forwarding >> loop. If Host 1 sends the packet out on network A, then the router it >> sends it to will find that Host 2 is reachable only through Host 1. >> It'll send the packet back to Host 1, which will then erroneously >> forward it back out on network A -- looping until the TTL expires. > > Not actually. Since this is hostmodel behavior, it does not apply > to forwarded packets- thus if/when the packet loops back to host1 the > first time (host1 -> rtr -> host1) it's a forwarded packet, as far as > host1 is concerned. Thus it would not be subject to the hostmodel > solution proposed here, and would instead get forwarded down B (based > on longest prefix match). If there was an ingress filter on B, the > packet would get dropped, but that would happen only if the > default router for host1 itself did not have any other path for > x.x.y.0/24 other than the doomed one through host1 itself. So locally-emitted packets are forwarded differently than those received from elsewhere? That's new RFC 791 / 1812 behavior, and makes even less sense to me. Consider another router/host, call it "myhome," that is connected to two ISPs for redundancy, and that has subnets configured behind it on another interface. When "myhome" originates packets to the Internet using the scheme you're advocating, it'll always pick the right interface. But when it forwards packets from the internal networks to the Internet, it'll do so incorrectly. It won't obey the source address restrictions, merely because these packets are forwarded, and they'll end up on arbitrary output interfaces, and be sometimes dropped on RFC 3704 filters. I think this feature may need to be rethought. -- James Carlson 42.703N 71.076W From sowmini.varadhan@oracle.com Fri Apr 16 08:42:23 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GFgNBd015676 for ; Fri, 16 Apr 2010 08:42:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3GFgMFf028427 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 10:42:23 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z005037MMLF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:42:22 -0600 (MDT) Received: from quasimodo.East.Sun.COM ([129.148.174.94]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00MDO7MMPC50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:42:22 -0600 (MDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3GFZsdv020915; Fri, 16 Apr 2010 11:35:54 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3GFZsQZ020914; Fri, 16 Apr 2010 11:35:54 -0400 (EDT) Date: Fri, 16 Apr 2010 11:35:54 -0400 From: sowmini.varadhan@oracle.com Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC45E3A.6060304@workingcode.com> To: James Carlson Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <20100416153554.GB20849@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@oracle.com using -f User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1124 On (04/13/10 08:06), James Carlson wrote: > > > That's all that was missed. In the quoted text above, it says "3" > settings, but there are actually 4. It's just a nit on the fast-track > materials. Wrapping up this thread for ARC.. I've updated the ARC materials and placed the latest copy at http://cr.opensolaris.org/~sowmini/hostmodel.txt > I might be straying outside of ARC review (and feel free to redirect > this to networking-discuss), but that doesn't sound quite right to me. Jim and I had a long-ish discussion about the implementation details of src-priority, and I think we both agree on the commonly anticipated host behavior, but have different expectations about how the implementation should deal with forwarded packets. Since the hostmodel feature (and esp the strong version and its variants) by its very name is not intended for use for routing/forwarding, and, due to various post-IPDR implementation details, the proposed changes will in fact naturally not be involved in the forwarding path, so I don't believe there are any outstanding issues for the ARC review at this point. --Sowmini From carlsonj@workingcode.com Fri Apr 16 09:08:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GG8i9K016342 for ; Fri, 16 Apr 2010 09:08:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3GG8h5w014999 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 11:08:44 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z008098UJ8R00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 10:08:43 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00MUD8UFP760@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 10:08:39 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3GG2HIM005679 for ; Fri, 16 Apr 2010 16:08:39 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-81798 for PSARC-ext@sun.com; Fri, 16 Apr 2010 16:08:38 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-91702513 for PSARC-ext@sun.com; Fri, 16 Apr 2010 16:08:37 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-3023523 for PSARC-ext@sun.com; Fri, 16 Apr 2010 16:08:37 +0000 (Z) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3GG8SdH026005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Apr 2010 12:08:29 -0400 (EDT) Date: Fri, 16 Apr 2010 12:08:28 -0400 From: James Carlson Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <20100416153554.GB20849@quasimodo.East.Sun.COM> To: sowmini.varadhan@oracle.com Cc: Sebastien Roy , PSARC-ext@sun.com Message-id: <4BC88B7C.5050807@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 1.287sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> <20100416153554.GB20849@quasimodo.East.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 988 On 04/16/10 11:35, sowmini.varadhan@oracle.com wrote: > should deal with forwarded packets. Since the hostmodel feature (and > esp the strong version and its variants) by its very name is not > intended for use for routing/forwarding, and, due to various post-IPDR > implementation details, the proposed changes will in fact naturally not > be involved in the forwarding path, so I don't believe there are any > outstanding issues for the ARC review at this point. I'm quite uncomfortable with that for the same reason that I'm always uncomfortable with host-versus-router distinctions: they always seem far too arbitrary to me. That applies in this case -- I don't think "hostmodel" is really the right label to apply and that the underlying behavior is hazardous to use. But I also know when I'm failing to make progress, so if you're comfortable with this, then drive on. It'll just be unusable for me. -- James Carlson 42.703N 71.076W From Nicolas.Williams@oracle.com Fri Apr 16 10:19:55 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GHJtEl017608 for ; Fri, 16 Apr 2010 10:19:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3GHJs2I032528 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 11:19:54 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00A09C56JT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 10:19:54 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z001GQC555H30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 10:19:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3GHJqxC006949 for ; Fri, 16 Apr 2010 17:19:53 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3G47DJJ006473; Fri, 16 Apr 2010 17:19:48 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 166738571271438329; Fri, 16 Apr 2010 10:18:49 -0700 Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 10:18:48 -0700 Date: Fri, 16 Apr 2010 12:18:43 -0500 From: Nicolas Williams Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC88B7C.5050807@workingcode.com> To: James Carlson Cc: sowmini.varadhan@oracle.com, Sebastien Roy , PSARC-ext@sun.com Message-id: <20100416171843.GG10389@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BC89C35.0186:SCFMA4539814,ss=1,fgs=0 References: <4BC37FD0.3090301@oracle.com> <4BC386FE.5090106@workingcode.com> <20100413002706.GC11987@quasimodo.East.Sun.COM> <4BC45E3A.6060304@workingcode.com> <20100416153554.GB20849@quasimodo.East.Sun.COM> <4BC88B7C.5050807@workingcode.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1382 On Fri, Apr 16, 2010 at 12:08:28PM -0400, James Carlson wrote: > On 04/16/10 11:35, sowmini.varadhan@oracle.com wrote: > > should deal with forwarded packets. Since the hostmodel feature (and > > esp the strong version and its variants) by its very name is not > > intended for use for routing/forwarding, and, due to various post-IPDR > > implementation details, the proposed changes will in fact naturally not > > be involved in the forwarding path, so I don't believe there are any > > outstanding issues for the ARC review at this point. > > I'm quite uncomfortable with that for the same reason that I'm always > uncomfortable with host-versus-router distinctions: they always seem far > too arbitrary to me. That applies in this case -- I don't think > "hostmodel" is really the right label to apply and that the underlying > behavior is hazardous to use. I agree that if there's any way to apply the strong host multi-homed model in such a way that it does not result in routing loops when the host is actually _also_ a router, that'd be a good thing. > But I also know when I'm failing to make progress, so if you're > comfortable with this, then drive on. It'll just be unusable for me. I don't see why we actually need the strong host multi-homed model + router functionality at the same time in any of our products, so I think Sowmini is on solid ground. Nico -- From carlsonj@workingcode.com Sat Apr 17 10:01:03 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3HH125C001528 for ; Sat, 17 Apr 2010 10:01:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3HH12tO024343 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 17 Apr 2010 11:01:02 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1100I075XQJG00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 17 Apr 2010 11:01:02 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L11007QU5XPBSB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Sat, 17 Apr 2010 11:01:01 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3HGqpSm028662 for ; Sat, 17 Apr 2010 17:01:01 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-4392114 for psarc-ext@sun.com; Sat, 17 Apr 2010 17:01:00 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-140225735 for psarc-ext@sun.com; Sat, 17 Apr 2010 17:01:00 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-35371455 for psarc-ext@sun.com; Sat, 17 Apr 2010 17:01:00 +0000 (Z) Received: from [192.168.1.104] (c-98-236-56-14.hsd1.pa.comcast.net [98.236.56.14]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3HH0khk017525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Apr 2010 13:00:48 -0400 (EDT) Date: Sat, 17 Apr 2010 13:00:44 -0400 From: James Carlson Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: To: Nicolas Williams Cc: psarc-ext@sun.com, sowmini.varadhan@oracle.com Message-id: <4BC9E93C.5020702@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.222sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 3269 On 04/16/10 01:18 PM, Nicolas Williams wrote: > I agree that if there's any way to apply the strong host multi-homed > model in such a way that it does not result in routing loops when the > host is actually _also_ a router, that'd be a good thing. There are three modes here: Weak ES, Strong ES, and "source priority." By saying "strong host," you seem to be talking about Strong ES, but I'm not. I don't care how broken Strong ES with routing may be, because Strong ES is already _known_ to break routing. That's uninteresting. I'm talking about the "source priority" mode. My argument is that there's no need at all to make source matching take precedence over longest prefix search, regardless of whether the feature is intended to be used with "routing." In other words there are two issues: - Does source address match take priority over prefix length or is prefix length checked first and then source address? - Does the source address checking work for forwarded packets or only for locally originated packets? For the first question, I see no point in making source address take priority over prefix length. Doing so does break routing protocols -- regardless of whether the local host is actually FORWARDING, it can LISTEN to routing protocols -- including the "protocol" of static routing. That's right; this feature even breaks static routes, by violating the basic rules of IP interface selection. There appears to be no need for this breakage, as checking length first is formally equivalent: any situation you could support using source-dominates is trivially translatable into a configuration using normal length-first matching with source preference. For the second question, that's where actual forwarding (what I think you're referring to as "routing") gets involved. I think it's substantially suboptimal to make the output interface selection mechanism used by locally-generated packets differ from the selection performed by IP forwarding, but I can see how code changes may have made this distinction unavoidable. > > But I also know when I'm failing to make progress, so if you're > > comfortable with this, then drive on. It'll just be unusable for me. > > I don't see why we actually need the strong host multi-homed model + > router functionality at the same time in any of our products, so I think > Sowmini is on solid ground. I don't share that view. Note that "routing" (running routing protocols) is really quite different from "forwarding" (receiving packets on one interface and resending them on another, possibly based on learned routing information). Confusing the two terms is a big part of the problem here. The feature described is incompatible with actual routing, regardless of whether forwarding is enabled or in use, and Sun's products have (historically at least) supported that form of routing. For example, see OSPF-MP -- a rather intentional Sun product that could benefit from a source preference mechanism. I realize that product-related issues really aren't proper on this list, but I don't think the assertion you're making really matches either the basis of my objections or the extant set of products. -- James Carlson 42.703N 71.076W From sowmini.varadhan@oracle.com Mon Apr 19 12:07:27 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3JJ7QmM014113 for ; Mon, 19 Apr 2010 12:07:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3JJ7Fb2028136 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 19 Apr 2010 14:07:16 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1500701143UY00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 19 Apr 2010 12:07:15 -0700 (PDT) Received: from quasimodo.East.Sun.COM ([129.148.174.94]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L15002WB142ZA40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 19 Apr 2010 12:07:15 -0700 (PDT) Received: from quasimodo.East.Sun.COM (localhost [127.0.0.1]) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o3JJ0huY026337; Mon, 19 Apr 2010 15:00:43 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o3JJ0gdU026336; Mon, 19 Apr 2010 15:00:42 -0400 (EDT) Date: Mon, 19 Apr 2010 15:00:42 -0400 From: sowmini.varadhan@oracle.com Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC9E93C.5020702@workingcode.com> To: James Carlson Cc: Nicolas Williams , psarc-ext@sun.com Message-id: <20100419190042.GG25718@quasimodo.East.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4BC9E93C.5020702@workingcode.com> X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to sowmini.varadhan@oracle.com using -f User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1917 I spent some time thinking about your points, and here's the conclusion I came to: (i) what you are proposing is essentially weak ES (with longest prefix match), with a variant to the "cost" used for ECMP: within a set of equal prefix length routes, the ones that have a src addr match are considered "lower cost". (ii) Whereas what I'm defining as src-priority is (like strong ES) not the longest prefix match- its saying "first try strong ES, and if that fails, fall back to weak ES". For the common case of a host having equal length routes (typically the default) for the dst, it turns out that both definitions will result in the exact same behavior. for the less common cases e.g., host participates in routing, but not forwarding, resulting in unequal prefix length routes for the target subnet, e.g., target longer path : | rtr1 rtr2 \ / A B sender there will be some differences between (i) and (ii). In the above example, (ii) would have a better shot of getting past ingress filters by going through the longer path (unless some other routing table massaging is applied). I'm not currently proposing variations in today's ECMP algorithm for weak ES model such as those suggested in (i). If the variations needed to ECMP for weak ES in (i) are seen as a solution to some problem that's not covered by the common case (which is covered by (ii)), then as Jim points out this proposal does not provide that solution. But given that the "common case" is actually covered by (ii), *if* the "uncommon case" scenario is really found to be a rampant one, we'd have to modify the ECMP algorithm for weak ES to implement (i). I'm suggesting that we should defer that ECMP extension until we have enough data on how rampant this scenario is. --Sowmini From garrett.damore@oracle.com Thu Apr 29 17:06:45 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3U06jBj016513 for ; Thu, 29 Apr 2010 17:06:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3U06j5b007730 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 29 Apr 2010 17:06:45 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1N00A05XN9E000@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 29 Apr 2010 17:06:45 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1N002XZXN86160@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 29 Apr 2010 17:06:44 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3U06iDW014442 for ; Fri, 30 Apr 2010 00:06:44 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3U06hXs003775 for ; Fri, 30 Apr 2010 00:06:43 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 222881541272585949; Thu, 29 Apr 2010 17:05:49 -0700 Received: from [129.153.2.5] (/129.153.2.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Apr 2010 17:05:48 -0700 Date: Thu, 29 Apr 2010 17:05:44 -0700 From: "Garrett D'Amore" Subject: PSARC 2010/127 To: psarc-ext@sun.com Message-id: <4BDA1ED8.3050304@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BDA1F13.019D:SCFMA4539814,ss=1,fgs=0 User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 595 I promised to review this case. I've reviewed the materials, and I see some dissension between James and Sowmini. Personally, I don't have a strong opinion about the difference in approaches. I do think Sowmini has thought about Jim's comments, and I'm comfortable that the distinction between the two behaviors is unlikely to be significant to the majority of our customers. So for now, I am giving this case a +1. If it turns out later that we need to rethink the src-priority setting, then we can do so at that time. (I don't think it will be necessary, however.) - Garrett From sebastien.roy@oracle.com Tue May 4 12:25:24 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44JPOj9015506 for ; Tue, 4 May 2010 12:25:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o44JPMv2004238 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 13:25:23 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1W0021BTYBXD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 12:25:23 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1W00JHXTYABUC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 12:25:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o44JPL3x029183 for ; Tue, 04 May 2010 19:25:21 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44GFVsM013642 for ; Tue, 04 May 2010 19:25:21 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 213984041273001103; Tue, 04 May 2010 12:25:03 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 12:25:02 -0700 Date: Tue, 04 May 2010 15:25:01 -0400 From: Sebastien Roy Subject: Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010] In-reply-to: <4BC37FD0.3090301@oracle.com> To: PSARC-ext@sun.com Cc: sowmini.varadhan@oracle.com Message-id: <4BE0748D.2010305@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE074A1.0095:SCFMA4539814,ss=1,fgs=0 References: <4BC37FD0.3090301@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 127 The timer on this case having expired, and the case having received adequate review, I'm marking it as closed approved. -Seb