1 Reply Latest reply on Sep 29, 2011 8:52 AM by dmease729

    Observations on SuperAgent with multiple NICs

    dmease729

      Hi,

       

      Due to a recent project I have been looking into the possibility of using multiple NICs on super agents.  After setting up in a VM environment, it would appear to work but was just wondering if I could get some form of clarification (especially on the one wierd thing that I have noted...).  The reason I am going down this path is not short to document - if you *really* need to know, then ask and I will update, but in the meantime, the following is what I have noted:

       

      Scenario 1: SuperAgent with 1 NIC

      ePO server (4.6): 192.168.1.203

      SuperAgent (MA4.6): 10.0.2.75

       

      When I send a superagent wake-up call manually from the ePO server, I see the following:

      ePO -> SuperAgent: connection initiated on 8081/tcp

      SuperAgent -> 255.255.255.255: broadcast wakeup on 8082/udp (source address of 10.0.2.75 - obvious - right?...)

       

      Scenario 2: SuperAgent with 2 NICs

      ePO server (4.6): 192.168.1.203

      SuperAgent (MA4.6): 10.0.2.75 (NIC1), 10.5.5.5 (NIC2)

       

      When I send a superagent wake-up call manually from the ePO server, I see the following on NIC2:

      SuperAgent -> 255.255.255.255: broadcast wakeup on 8082/udp (source address of 10.5.5.5) No wakeup call seen from ePO server as this particular traffic is seen on NIC1 only

       

      I see the following on NIC1:

      ePO -> SuperAgent: connection initiated on 8081/tcp

      SuperAgent -> 255.255.255.255: broadcast wakeup on 8082/udp (source address... ... ... of 10.5.5.5!) <- run this test a few times to confirm...

       

      Outstanding questions:

       

      1) Unless this is only happening in my environment, would the broadcast on NIC1 in the second scenario be considered a bug?  If anybody else has the time (...) could they check this?

      2) Shouldnt the broadcast be to the local bcast address (in the case of /24 nets, should be 10.0.2.255 and 10.5.5.255 respectively on the 2 SA NICs).   Note that I would have to check RFCs myself, not sure if 255.255.255.255 is acceptable.

      3) <drum roll>... short reason as to why I am doing this is to get around NAT.  Yes, I know thats what Agent Handlers are for, but there is a limit of 5 per ePO server.  And think of this requirement multiplied by 500 remote (NATted) nets.  Is there any other way to get a wakeup call to them, or are we going to have to accept that wake-up calls are not an option

      4) (slight tangent here) Note that I have seen a discussion chain that looks to involve McAfee support advising that wake-up calls will work through 1:1 NAT.  I have tested with the above (by NATting 10.0.2.0/24 to 10.100.2.0/24) and this does not work - is there anything I am missing or will wakeup calls *never* work through NAT (note that McAfee documentation refers to NAT, and it is not clear if it is referring to *all forms* of NAT such as NAT(1:1) and PAT(many:1)

       

      Gonna take a breather now :-)  Note that I have pcaps from the above tests if anybody wants to see them!

       

      Cheers,