none
Replacements of NDIS 5.1 LBFO routines in NDIS 6.0 RRS feed

  • Question

  • Curiously, what are replacements of following functions defined in NDIS 5.0? How can they be used in NDIS 6.0? Thanks!

    - NdisMSetMiniportSecondary

    - NdisMPromoteMiniport


     

    JH

    Monday, March 30, 2015 8:23 PM

Answers

  • There's a few reasons these APIs weren't carried forward to NDIS 6.

    • LBFO stands for Load Balancing + Failover.  But the APIs don't actually help with Load Balancing -- when you mark a miniport as "secondary", NDIS removes all bindings from the NIC.  In effect, the NIC is forced to be a "standby" NIC.
    • The Failover aspect doesn't work very well either.  In order to fail over, NDIS must build up all the bindings to the new miniport. This isn't seamless to applications; from their point of view, you just inserted a new network adapter, and need to acquire a new IP address, etc.
    • If failover decisions are made by the link partner (e.g., LACP) then you don't want to entirely disable the standby NIC.  You need to send out a heartbeat so the switch doesn't conclude the standby NIC has failed.
    • Since the API is called by the miniport, the LBFO logic needs to be driven from the miniport driver.  But modern LBFO architectures want to separate out the NIC and the LBFO logic.  In the extreme case of Windows Server NIC Teaming feature, the LBFO driver can team together NICs from unrelated vendors into the same team.

    Modern LBFO architectures layer a MUX-IM driver on top of the NICs.  That architecture doesn't need APIs like these.

    Are you asking because you have a solution that relies on this API, or just out of curiosity?

    Saturday, April 18, 2015 1:17 AM

All replies

  • I searched for above routines but failed to find anything in 6.x document. If you think there is no need for these functions in NDIS 6.x, could you explain the reason in detail? Thanks! 

    JH




    • Edited by Jiyang Tuesday, March 31, 2015 1:21 AM
    Monday, March 30, 2015 9:17 PM
  • There's a few reasons these APIs weren't carried forward to NDIS 6.

    • LBFO stands for Load Balancing + Failover.  But the APIs don't actually help with Load Balancing -- when you mark a miniport as "secondary", NDIS removes all bindings from the NIC.  In effect, the NIC is forced to be a "standby" NIC.
    • The Failover aspect doesn't work very well either.  In order to fail over, NDIS must build up all the bindings to the new miniport. This isn't seamless to applications; from their point of view, you just inserted a new network adapter, and need to acquire a new IP address, etc.
    • If failover decisions are made by the link partner (e.g., LACP) then you don't want to entirely disable the standby NIC.  You need to send out a heartbeat so the switch doesn't conclude the standby NIC has failed.
    • Since the API is called by the miniport, the LBFO logic needs to be driven from the miniport driver.  But modern LBFO architectures want to separate out the NIC and the LBFO logic.  In the extreme case of Windows Server NIC Teaming feature, the LBFO driver can team together NICs from unrelated vendors into the same team.

    Modern LBFO architectures layer a MUX-IM driver on top of the NICs.  That architecture doesn't need APIs like these.

    Are you asking because you have a solution that relies on this API, or just out of curiosity?

    Saturday, April 18, 2015 1:17 AM
  • Actually in NDIS 6.0 how MiniportInitialize() get all bundled NICs info (say I have 5 NICs but only 2 of them used for LBFO) ? In PnP notification event how can I promote/demote a NIC? Thanks!

    JH

    Monday, April 20, 2015 2:26 AM
  • The design of NDIS is that you do not get "bundled" NIC info.  The design is that each network port operates independently of the others.

    If you want to aggregate them (for LBFO, etc.) we suggest layering a MUX driver on top of the low-level miniport driver(s).

    Monday, April 20, 2015 7:31 PM