05 Jun, 2018

1 commit


29 Oct, 2017

2 commits

  • This is very similar to the Macvlan VEPA mode, however, there is some
    difference. IPvlan uses the mac-address of the lower device, so the VEPA
    mode has implications of ICMP-redirects for packets destined for its
    immediate neighbors sharing same master since the packets will have same
    source and dest mac. The external switch/router will send redirect msg.

    Having said that, this will be useful tool in terms of debugging
    since IPvlan will not switch packets within its slaves and rely completely
    on the external entity as intended in 802.1Qbg.

    Signed-off-by: Mahesh Bandewar
    Signed-off-by: David S. Miller

    Mahesh Bandewar
     
  • IPvlan has always operated in bridge mode. However there are scenarios
    where each slave should be able to talk through the master device but
    not necessarily across each other. Think of an environment where each
    of a namespace is a private and independant customer. In this scenario
    the machine which is hosting these namespaces neither want to tell who
    their neighbor is nor the individual namespaces care to talk to neighbor
    on short-circuited network path.

    This patch implements the mode that is very similar to the 'private' mode
    in macvlan where individual slaves can send and receive traffic through
    the master device, just that they can not talk among slave devices.

    Signed-off-by: Mahesh Bandewar
    Signed-off-by: David S. Miller

    Mahesh Bandewar
     

03 Jul, 2017

1 commit

  • In the IPVLAN documentation there is an example command line where the
    master and slave interface names are inverted.
    Fix the command line and also add the optional `name' keyword to better
    describe what the command is doing.

    v2: added commit message

    Signed-off-by: Matteo Croce
    Signed-off-by: David S. Miller

    Matteo Croce
     

19 Sep, 2016

1 commit

  • In a typical IPvlan L3 setup where master is in default-ns and
    each slave is into different (slave) ns. In this setup egress
    packet processing for traffic originating from slave-ns will
    hit all NF_HOOKs in slave-ns as well as default-ns. However same
    is not true for ingress processing. All these NF_HOOKs are
    hit only in the slave-ns skipping them in the default-ns.
    IPvlan in L3 mode is restrictive and if admins want to deploy
    iptables rules in default-ns, this asymmetric data path makes it
    impossible to do so.

    This patch makes use of the l3_rcv() (added as part of l3mdev
    enhancements) to perform input route lookup on RX packets without
    changing the skb->dev and then uses nf_hook at NF_INET_LOCAL_IN
    to change the skb->dev just before handing over skb to L4.

    Signed-off-by: Mahesh Bandewar
    CC: David Ahern
    Reviewed-by: David Ahern
    Signed-off-by: David S. Miller

    Mahesh Bandewar
     

29 Apr, 2016

1 commit


25 Nov, 2014

1 commit

  • This driver is very similar to the macvlan driver except that it
    uses L3 on the frame to determine the logical interface while
    functioning as packet dispatcher. It inherits L2 of the master
    device hence the packets on wire will have the same L2 for all
    the packets originating from all virtual devices off of the same
    master device.

    This driver was developed keeping the namespace use-case in
    mind. Hence most of the examples given here take that as the
    base setup where main-device belongs to the default-ns and
    virtual devices are assigned to the additional namespaces.

    The device operates in two different modes and the difference
    in these two modes in primarily in the TX side.

    (a) L2 mode : In this mode, the device behaves as a L2 device.
    TX processing upto L2 happens on the stack of the virtual device
    associated with (namespace). Packets are switched after that
    into the main device (default-ns) and queued for xmit.

    RX processing is simple and all multicast, broadcast (if
    applicable), and unicast belonging to the address(es) are
    delivered to the virtual devices.

    (b) L3 mode : In this mode, the device behaves like a L3 device.
    TX processing upto L3 happens on the stack of the virtual device
    associated with (namespace). Packets are switched to the
    main-device (default-ns) for the L2 processing. Hence the routing
    table of the default-ns will be used in this mode.

    RX processins is somewhat similar to the L2 mode except that in
    this mode only Unicast packets are delivered to the virtual device
    while main-dev will handle all other packets.

    The devices can be added using the "ip" command from the iproute2
    package -

    ip link add link type ipvlan mode [ l2 | l3 ]

    Signed-off-by: Mahesh Bandewar
    Cc: Eric Dumazet
    Cc: Maciej Żenczykowski
    Cc: Laurent Chavey
    Cc: Tim Hockin
    Cc: Brandon Philips
    Cc: Pavel Emelianov
    Signed-off-by: David S. Miller

    Mahesh Bandewar