>
> 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?
Usually, applications that work at the interface-level, such as routing
daemons, DHCP servers, and so forth.
> 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?
Yes, that's correct.
> 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.
That's probably true.
> 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.
First, I'm a bit confused about your use of `!up' above -- all test
addresses should be IFF_UP. Second, you asking about probe-based failure
detection, but then propose that a link failure is detected. Those are
two different cases:
* In the case where the link remains up but probes are no longer
answered, in.mpathd will detect this failure independently on all
three IP interfaces using the link (bge0, bge1000, and bge2000),
and trigger failovers to bge1, bge1001, and bge2001 (though
nothing will happen when bge2000 fails since it doesn't host any
data addresses in your example above).
* In the case where the link goes down, the bge driver will call
mac_link_update() on the bge0 mac, which will cause GLDv3's
str_notify() function to be called on each stream that has
attached to a PPA that uses the bge0 mac. Since bge0, bge1000,
and bge2000 all use the bge0 mac (see dld_str_attach()), all
three IP interfaces will receive a DL_NOTE_LINK_DOWN DLPI
notification.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
