On 4/18/06, Peter Memishian <[EMAIL PROTECTED]> wrote: > > > I am working on a project that includes the use of both IPMP and VLAN > > tagging. An interesting point of discussion that has come up consists > > of what is the official supported configuration by Sun. > > Ron, > > We support both configurations. However, if you put the test addresses on > the physical interface, you run a much greater risk of applications > (especially third-party) using the test addresses as data addresses, which > will appear to work until the interface fails (and the application fails > along with it). This is because SIOCG[L]IFCONF will return the addresses > in order (on each interface), and IPMP-unaware applications will simply > use the first IFF_UP|IFF_RUNNING address, which will be the test address > if you put it on the physical interface.
This is the first time I have heard an explanation for this. Just out of curiosity, is there a general category of application that will do this? My assumption was that the vast majority of code out there simply called one of the following combinations: socket() connect(remoteaddr) OR socket() bind(INADDR_ANY, port) listen() I further assumed that this combination would make efforts to avoid deprecated interfaces. Is this a reasonable assumption? Presumably an application running in a local zone would only be presented with failover (and virtual) interfaces so an effective protection against this would be to run said applications in zones. I suspect, however, that the class of applications that really care about which interface they are talking on holds a significant membership in the class of applications that can't run in local zones. > Thus, for now, I'd recommend putting the test addresses on the logical > interface instead. However, the IPMP Rearchitecture will render this > issue moot, since IPMP-unaware applications will no longer discover the > test addresses via SIOCG[L]IFCONF. At that point, we will recommend > putting the test address on the physical interface since it will lead to a > slightly simpler configuration (otherwise, the physical interface would > end up with a 0.0.0.0 placeholder address). So, what happens now if probe-based detection is used with VLANs? For example: # native vlan - these interfaces need to work with dhcp for # network based installation/recovery bge0: 0.0.0.0 deprecated,nofailover,(!up) group 10.0.0.0 bge1: 0.0.0.0 deprecated,nofailover,(!up) group 10.0.0.0 bge0:1: 10.0.0.1 up group 10.0.0.0 # vlan 1 bge1000: 0.0.0.0 deprecated,nofailover,(!up) group 10.0.1.0 bge1001: 0.0.0.0 deprecated,nofailover,(!up) group 10.0.1.0 bge1000:1 10.0.1.1 up group 10.0.1.0 # vlan 2 bge2000: 0.0.0.0 deprecated,nofailover,(!up) group 10.0.2.0 bge2001: 0.0.0.0 deprecated,nofailover,(!up) group 10.0.2.0 bge2001:1 10.0.2.1 group 10.0.2.0 I this case, if a link failure is found on bge0, I fully expect that 10.0.0.1 will fail over to bge1. Will 10.0.1.1 recognize the link failure as well and fail over to bge1001? This is what makes sense to me but have not yet had a chance to test. FWIW, my initial focus on this would be with the current architecture(s) found in S10 1/06 and possibly S9 9/05. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ networking-discuss mailing list [email protected]
