NDIS IM MUX 1:n

I know it is an old topic but I would need to implement an IM MUX 1:n driver in order to act as a traffic aggregation system.

There are some threads about this matter in which they speak about a sample code from Microsoft. Is that code available in any place?

Really a MUX 1:n is as different (and difficult to implement) than the MUX n:1 sample? Is it a good staring point?

Thanks in advance.

Quite a long time ago Bob had forwarded me the discontinued sample and I am
attaching the same for your reference. Please rename the .dat to .zip…

regards

amit

On Sat, Jun 25, 2011 at 10:35 PM, wrote:

> I know it is an old topic but I would need to implement an IM MUX 1:n
> driver in order to act as a traffic aggregation system.
>
> There are some threads about this matter in which they speak about a sample
> code from Microsoft. Is that code available in any place?
>
> Really a MUX 1:n is as different (and difficult to implement) than the MUX
> n:1 sample? Is it a good staring point?
>
> Thanks in advance.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>



- ab

Hi Amit,

Thank you very much!

At first sight, it seems to me very similar to the N:1 sample. Really the
differences are so little? I have read in this list that the 1:N is quite
difficult to implement.

Best regards,
JV.

On Sat, Jun 25, 2011 at 11:43 PM, A B wrote:

> Quite a long time ago Bob had forwarded me the discontinued sample and I am
> attaching the same for your reference. Please rename the .dat to .zip…
>
> regards
>
> amit
>
> On Sat, Jun 25, 2011 at 10:35 PM, wrote:
>
>> I know it is an old topic but I would need to implement an IM MUX 1:n
>> driver in order to act as a traffic aggregation system.
>>
>> There are some threads about this matter in which they speak about a
>> sample code from Microsoft. Is that code available in any place?
>>
>> Really a MUX 1:n is as different (and difficult to implement) than the MUX
>> n:1 sample? Is it a good staring point?
>>
>> Thanks in advance.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
>
> - ab
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer



Un saludo,
Jos? Vicente.

well consider this…

N:1 you have one real adapter and N virtual ones, so it is mostly software
stuff like VLAN ID etc.
in contrast…
1:N will have different physical NIC hardwares which will be abstracted into
one adapter. These NICS can have very different capabilities and those would
have to be ironed out for the ‘team’. Example, if NIC1 has tcp offloading,
and NIC 2 doesnt, then probably the team consisting of these would probably
have to eliminate offloading. Also, you will need to handle a lot of other
things apart from ths…

good luck…

Amit

On Sun, Jun 26, 2011 at 3:58 PM, Jose Vicente Sanchez Ortega <
xxxxx@gmail.com> wrote:

Hi Amit,

Thank you very much!

At first sight, it seems to me very similar to the N:1 sample. Really the
differences are so little? I have read in this list that the 1:N is quite
difficult to implement.

Best regards,
JV.

On Sat, Jun 25, 2011 at 11:43 PM, A B wrote:
>
>> Quite a long time ago Bob had forwarded me the discontinued sample and I
>> am attaching the same for your reference. Please rename the .dat to .zip…
>>
>> regards
>>
>> amit
>>
>> On Sat, Jun 25, 2011 at 10:35 PM, wrote:
>>
>>> I know it is an old topic but I would need to implement an IM MUX 1:n
>>> driver in order to act as a traffic aggregation system.
>>>
>>> There are some threads about this matter in which they speak about a
>>> sample code from Microsoft. Is that code available in any place?
>>>
>>> Really a MUX 1:n is as different (and difficult to implement) than the
>>> MUX n:1 sample? Is it a good staring point?
>>>
>>> Thanks in advance.
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> –
>>
>> - ab
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
>
> Un saludo,
> Jos? Vicente.
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer



- ab

Hi Amit,

Thanks again. What I am trying to accomplish is to be able to decide the NIC
to use for a given set of traffic (for example, all HTTP traffic trough NIC
1, FTP traffic through NIC 2 and so).

Regarding the fact that every NIC would support a different set of
capabilities, the real situation in my case will be typically a pure 802.3
NIC and a NDISWAN (i.e. a 3G Modem).

Abusing from you kindness, I would like to ask you some additional
questions:

  • Could you please tell me the most important details that I should take
    into account?
  • Given that the approach is a 1:N, should I create just one miniport and
    attach it to every one of the NICs below?

Thanks in advance.

JV.

On Sun, Jun 26, 2011 at 7:08 PM, A B wrote:

> well consider this…
>
> N:1 you have one real adapter and N virtual ones, so it is mostly software
> stuff like VLAN ID etc.
> in contrast…
> 1:N will have different physical NIC hardwares which will be abstracted
> into one adapter. These NICS can have very different capabilities and those
> would have to be ironed out for the ‘team’. Example, if NIC1 has tcp
> offloading, and NIC 2 doesnt, then probably the team consisting of these
> would probably have to eliminate offloading. Also, you will need to handle a
> lot of other things apart from ths…
>
>
> good luck…
>
> Amit
>
> On Sun, Jun 26, 2011 at 3:58 PM, Jose Vicente Sanchez Ortega <
> xxxxx@gmail.com> wrote:
>
>> Hi Amit,
>>
>> Thank you very much!
>>
>> At first sight, it seems to me very similar to the N:1 sample. Really the
>> differences are so little? I have read in this list that the 1:N is quite
>> difficult to implement.
>>
>> Best regards,
>> JV.
>>
>>
>> On Sat, Jun 25, 2011 at 11:43 PM, A B wrote:
>>
>>> Quite a long time ago Bob had forwarded me the discontinued sample and I
>>> am attaching the same for your reference. Please rename the .dat to .zip…
>>>
>>> regards
>>>
>>> amit
>>>
>>> On Sat, Jun 25, 2011 at 10:35 PM, wrote:
>>>
>>>> I know it is an old topic but I would need to implement an IM MUX 1:n
>>>> driver in order to act as a traffic aggregation system.
>>>>
>>>> There are some threads about this matter in which they speak about a
>>>> sample code from Microsoft. Is that code available in any place?
>>>>
>>>> Really a MUX 1:n is as different (and difficult to implement) than the
>>>> MUX n:1 sample? Is it a good staring point?
>>>>
>>>> Thanks in advance.
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>
>>>
>>>
>>> –
>>>
>>> - ab
>>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>>> the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> –
>>
>> Un saludo,
>> Jos? Vicente.
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
>
> - ab
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>



Un saludo,
Jos? Vicente.

JV,

I really am not an NDIS expert, and it has been a while since I worked with
NDIS, but still, let me take a stab…

Thanks again. What I am trying to accomplish is to be able to decide the
NIC to use for a given set of >traffic (for example, all HTTP traffic
trough NIC 1, FTP traffic through NIC 2 and so).

Could you please tell me the most important details that I should take into
account?
There are quite a few:

  1. How will you report NIC status. Example if one of the adapters below you
    lose it’s connectivity, then would you show the entire link down, or would
    you just return error for packets of protocols for that adapter?
  2. you will need to swap the miniport edge function pointers in runtime
    depending on the protocol packet being handled. so you will have to store
    context abt that in the miniport
  3. it is it not only tcp/ip based protocols you want to route, then you will
    have to have multiple attachments too.
  4. you will also have to decouple your teamed adapters from the protocols
    programatically, you will need a coinstaller for that.

Given that the approach is a 1:N, should I create just one miniport and
attach it to every one of the NICs below?
When I did it, I used to query the miniports in my team and then save the
adapter protocol edge pointers in my driver and then pass on the packets to
the right adapters, I also had an LSP to help me in some of the heuristic
tasks.

You should also enroll your self to the yahoo group
xxxxx@yahoogroups.com

Thomas Divine is the best person to help you…

best regards

amit

On Sun, Jun 26, 2011 at 11:01 PM, Jose Vicente Sanchez Ortega <
xxxxx@gmail.com> wrote:

Hi Amit,

Thanks again. What I am trying to accomplish is to be able to decide the
NIC to use for a given set of traffic (for example, all HTTP traffic trough
NIC 1, FTP traffic through NIC 2 and so).

Regarding the fact that every NIC would support a different set of
capabilities, the real situation in my case will be typically a pure 802.3
NIC and a NDISWAN (i.e. a 3G Modem).

Abusing from you kindness, I would like to ask you some additional
questions:

  • Could you please tell me the most important details that I should
    take into account?
  • Given that the approach is a 1:N, should I create just one miniport
    and attach it to every one of the NICs below?

Thanks in advance.

JV.

On Sun, Jun 26, 2011 at 7:08 PM, A B wrote:
>
>> well consider this…
>>
>> N:1 you have one real adapter and N virtual ones, so it is mostly software
>> stuff like VLAN ID etc.
>> in contrast…
>> 1:N will have different physical NIC hardwares which will be abstracted
>> into one adapter. These NICS can have very different capabilities and those
>> would have to be ironed out for the ‘team’. Example, if NIC1 has tcp
>> offloading, and NIC 2 doesnt, then probably the team consisting of these
>> would probably have to eliminate offloading. Also, you will need to handle a
>> lot of other things apart from ths…
>>
>>
>> good luck…
>>
>> Amit
>>
>> On Sun, Jun 26, 2011 at 3:58 PM, Jose Vicente Sanchez Ortega <
>> xxxxx@gmail.com> wrote:
>>
>>> Hi Amit,
>>>
>>> Thank you very much!
>>>
>>> At first sight, it seems to me very similar to the N:1 sample. Really the
>>> differences are so little? I have read in this list that the 1:N is quite
>>> difficult to implement.
>>>
>>> Best regards,
>>> JV.
>>>
>>>
>>> On Sat, Jun 25, 2011 at 11:43 PM, A B wrote:
>>>
>>>> Quite a long time ago Bob had forwarded me the discontinued sample and I
>>>> am attaching the same for your reference. Please rename the .dat to .zip…
>>>>
>>>> regards
>>>>
>>>> amit
>>>>
>>>> On Sat, Jun 25, 2011 at 10:35 PM, wrote:
>>>>
>>>>> I know it is an old topic but I would need to implement an IM MUX 1:n
>>>>> driver in order to act as a traffic aggregation system.
>>>>>
>>>>> There are some threads about this matter in which they speak about a
>>>>> sample code from Microsoft. Is that code available in any place?
>>>>>
>>>>> Really a MUX 1:n is as different (and difficult to implement) than the
>>>>> MUX n:1 sample? Is it a good staring point?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> —
>>>>> NTDEV is sponsored by OSR
>>>>>
>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>> http://www.osr.com/seminars
>>>>>
>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>
>>>>
>>>>
>>>>
>>>> –
>>>>
>>>> - ab
>>>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>>>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>>> visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>>
>>>
>>> –
>>>
>>> Un saludo,
>>> Jos? Vicente.
>>>
>>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>> visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> –
>>
>> - ab
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
>
> Un saludo,
> Jos? Vicente.
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>



- ab

We have an IM Fault Tolerant Ethernet driver for our products, that I?ve worked on from NT5 through Win 7. The XP and older OS the driver is N:N where we can re-route packets out/in any of the physical NICs from/to any of the Application exposed miniports. For Vista and above the driver is a true 1:N MUX which saves on IP addresses if that is a problem.

The N:N driver is just a 1:1 driver that gets installed on all the stacks. The Notify Object is fairly simple but allows the driver to see all NICs. Since the driver is on all stacks the driver can move packets between the miniports and the physical NICs with some packet manipulation.

The 1:N driver hides all NICs below a Virtual Miniport. Applications can only see the Virtual Miniport and not the physical NICs. The Notify Object is complicated, in fact the NO has more ?lines of code? than the driver.

We could have done the N:N on Vista and above but since we had to rewrite the driver for NDIS 6 and we have customers that were running out of IP addresses we went with the true MUX of 1:N. From our experience I would suggest starting with the N:N version.

Honeywell holds patents, you can Goggle ?Fault Tolerant Ethernet ? if you are interested to get an idea of what it does.

Larry C

Larry,

by fault tolerant do you mean that if one of the NICs of a team go down, the
other takes up it’s load? In failover mode?

Amit

On Mon, Jun 27, 2011 at 11:43 PM, wrote:

> We have an IM Fault Tolerant Ethernet driver for our products, that I?ve
> worked on from NT5 through Win 7. The XP and older OS the driver is N:N
> where we can re-route packets out/in any of the physical NICs from/to any of
> the Application exposed miniports. For Vista and above the driver is a true
> 1:N MUX which saves on IP addresses if that is a problem.
>
> The N:N driver is just a 1:1 driver that gets installed on all the stacks.
> The Notify Object is fairly simple but allows the driver to see all NICs.
> Since the driver is on all stacks the driver can move packets between the
> miniports and the physical NICs with some packet manipulation.
>
> The 1:N driver hides all NICs below a Virtual Miniport. Applications can
> only see the Virtual Miniport and not the physical NICs. The Notify Object
> is complicated, in fact the NO has more ?lines of code? than the driver.
>
> We could have done the N:N on Vista and above but since we had to rewrite
> the driver for NDIS 6 and we have customers that were running out of IP
> addresses we went with the true MUX of 1:N. From our experience I would
> suggest starting with the N:N version.
>
> Honeywell holds patents, you can Goggle ?Fault Tolerant Ethernet ? if you
> are interested to get an idea of what it does.
>
>
> Larry C
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>



- ab

No teaming involved, both ports are used. Between any two Fault Tolerant Ethernet (FTE) nodes there are 4 paths. Naming the NICs A and B, the paths are A->A, A->B, B->A, and B->B. The driver sends out Diagnostic Messages (DM) on how it sees the network and receives DMs from all other FTE nodes so it can have a picture of the whole network. When a packet comes down the driver looks up the node that its to send the packet to and determines not only which NIC to send it out on but also determines which NIC on the receiving node to send it to. This is an implementation of what became the Fieldbus Foundation Specification for Redundant Highspeed Ethernet.

Goggle FTE and the Honeywell site will explain in better detail.

Larry C

Hi Larry,

Thank you very much for the information. I was reading older threads in OSR
about this matter and I see a lot of references to Honeywell.

If I understood you well, and given that I just need to implement an IM
which could re-route packets for a given adapter (based on some traffic
rules), the N:N approach is enough for me.

I am not a NDIS experts (if I were, I would not asking so basic questions
:wink: ) but I have more than seven years of experience in kernel mode
development (typically drivers for hardware devices and filters for whole
disk encryption, SMB and SCSI encryption and so. In the other hand, I have
implemented TDI filters and many other network drivers but NEVER an NDIS IM.
The fact is that I feel myself unable to evaluate the level of the changes
which should be accomplished in MUX + NotifyObject to implement a N:N
approach and accomplish the task that I have been put in charge.

Larry, please, based on your experience and in the fact that I am not new to
kernel development, do you think it could be a feasible task for me
implementing the described driver? Probably based on my unknownledge of this
matter I am still unable to foresee which problems I could find across
development process.

Thanks in advance.

JV.

On Mon, Jun 27, 2011 at 8:13 PM, wrote:

> We have an IM Fault Tolerant Ethernet driver for our products, that I?ve
> worked on from NT5 through Win 7. The XP and older OS the driver is N:N
> where we can re-route packets out/in any of the physical NICs from/to any of
> the Application exposed miniports. For Vista and above the driver is a true
> 1:N MUX which saves on IP addresses if that is a problem.
>
> The N:N driver is just a 1:1 driver that gets installed on all the stacks.
> The Notify Object is fairly simple but allows the driver to see all NICs.
> Since the driver is on all stacks the driver can move packets between the
> miniports and the physical NICs with some packet manipulation.
>
> The 1:N driver hides all NICs below a Virtual Miniport. Applications can
> only see the Virtual Miniport and not the physical NICs. The Notify Object
> is complicated, in fact the NO has more ?lines of code? than the driver.
>
> We could have done the N:N on Vista and above but since we had to rewrite
> the driver for NDIS 6 and we have customers that were running out of IP
> addresses we went with the true MUX of 1:N. From our experience I would
> suggest starting with the N:N version.
>
> Honeywell holds patents, you can Goggle ?Fault Tolerant Ethernet ? if you
> are interested to get an idea of what it does.
>
>
> Larry C
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>



Un saludo,
Jos? Vicente.

For the N:N driver use the “PassthruNDIS Intermediate Sample Driver” as a start. It is a 1:1 driver but once you put more than one NIC in the node and install the IM driver it becomes an N:N because the driver will get bound to all NICs with calls to the driver’s PtBindAdapter(). The driver needs to keep a list of the adapters to be able use them. You will need to change the packet if you send it out a different adapter than it was originally intended. You will need ARP processing to handle when you want your node to change the receiving adapter. You will also need to change a packet before sending it up the stack that was received on an adapter but is for an IP address on another adapter. The passthru sample has just about everything you need to get started.

Larry C

Larry,

Thanks again for the explanation. Just one additional question. If I
understood you OK, I should add the NotifyObject to passthru in order to
manage the linkages, shouldn’t I?

Best regards,
JV.

On Mon, Jun 27, 2011 at 11:10 PM, wrote:

> For the N:N driver use the “PassthruNDIS Intermediate Sample Driver” as a
> start. It is a 1:1 driver but once you put more than one NIC in the node and
> install the IM driver it becomes an N:N because the driver will get bound to
> all NICs with calls to the driver’s PtBindAdapter(). The driver needs to
> keep a list of the adapters to be able use them. You will need to change the
> packet if you send it out a different adapter than it was originally
> intended. You will need ARP processing to handle when you want your node to
> change the receiving adapter. You will also need to change a packet before
> sending it up the stack that was received on an adapter but is for an IP
> address on another adapter. The passthru sample has just about everything
> you need to get started.
>
> Larry C
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>



Un saludo,
Jos? Vicente.

We added an NO to manage connections and a property page for our driver to allow configuration changes when necessary. Our systems can have more NICs than what are used with our driver so we needed a way to manage that.

Larry C