Skip to content

nat sample MAC address not correct #4

Description

@vincentmli

Hi Asim

I might may have misconfigured something for the NAT sample, so here again is my test example, let me know if I missed anything :)

client <---->dpdk0 mOS dpdk1 <---->server

client (IP 10.0.0.7, MAC 00:1b:21:50:bc:38 )
mOS (dpdk0 10.0.0.9 MAC a0:36:9f:a1:4d:6c, dpdk1 10.0.1.9 MAC A0:36:9F:A1:4D:6D)
server (IP 10.0.0.8, MAC 00:15:60:0e:3d:0a )

1, nat mos.conf

mos {
forward = 1

    #######################
    ##### I/O OPTIONS #####
    #######################
    # number of memory channels per socket [mandatory for DPDK]
    nb_mem_channels = 4

    # devices used for MOS applications [mandatory]
    netdev {
            dpdk0 0x00FF
            dpdk1 0x00FF
    }

    #######################
    ### LOGGING OPTIONS ###
    #######################
    # NICs to print network statistics per second
    # if enabled, mTCP will print xx Gbps and xx pps for RX and TX
    stat_print = dpdk0 dpdk1

    # A directory contains MOS system log files
    mos_log = logs/

    ########################
    ## NETWORK PARAMETERS ##
    ########################
    # This to configure static arp table
    # (Destination IP address) (Destination MAC address)
    arp_table {
    }

    # This is to configure static routing table
    # (Destination address)/(Prefix) (Device name)
    route_table {
    }

    # This is to configure static bump-in-the-wire NIC forwarding table
    # DEVNIC_A DEVNIC_B ## (e.g. dpdk0 dpdk1)
    nic_forward_table {
            dpdk0 dpdk1
    }

2, add server MAC in client and client MAC in server

client: #arp -i p1p1 -s 10.0.0.8 00:15:60:0e:3d:0a

server:

arp -i eth0 -s 10.0.0.7 00:1b:21:50:bc:38

arp -i eth0 -s 10.0.0.9 A0:36:9F:A1:4D:6D ( Note I had to add dpdk1 MAC for NAT IP 10.0.0.9 on server)

3, run nat

./nat -i 10.0.0.9

4, run curl on client

curl http://10.0.0.8/

client side capture:

09:42:47.809727 00:1b:21:50:bc:38 > 00:15:60:0e:3d:0a, ethertype IPv4 (0x0800), length 74: 10.0.0.7.37680 > 10.0.0.8.80: Flags [S], seq 1791631497.....

09:42:47.809987 a0:36:9f:a1:4d:6c > a0:36:9f:a1:4d:6d, ethertype IPv4 (0x0800), length 74: 10.0.0.8.80 > 10.0.0.7.37680: Flags [S.], seq 3146701557, ack 1791631498, ...

Note the problem here is:

SYN+ACK from mOS has source MAC of dpdk0 and destination MAC of dpdk1, instead of source MAC of dpdk0 and destination MAC of client, thus this result in SYN+ACK dropped by client.

4 server side capture:

09:45:56.065765 a0:36:9f:a1:4d:6d > 00:15:60:0e:3d:0a, ethertype IPv4 (0x0800), length 74: 10.0.0.9.1027 > 10.0.0.8.80: Flags [S], seq 1791631497...........

09:45:56.065865 00:15:60:0e:3d:0a > a0:36:9f:a1:4d:6d, ethertype IPv4 (0x0800), length 74: 10.0.0.8.80 > 10.0.0.9.1027: Flags [S.], seq 3146701557, ack 1791631498.............

server side source MAC and destination MAC looks ok for both SYN and SYN+ACK.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions