Mahesh Bandewar | 2ad7bf3 | 2014-11-23 23:07:46 -0800 | [diff] [blame] | 1 | |
| 2 | IPVLAN Driver HOWTO |
| 3 | |
| 4 | Initial Release: |
| 5 | Mahesh Bandewar <maheshb AT google.com> |
| 6 | |
| 7 | 1. Introduction: |
| 8 | This is conceptually very similar to the macvlan driver with one major |
| 9 | exception of using L3 for mux-ing /demux-ing among slaves. This property makes |
| 10 | the master device share the L2 with it's slave devices. I have developed this |
Eric Engestrom | edb9a1b | 2016-04-25 07:36:56 +0100 | [diff] [blame] | 11 | driver in conjunction with network namespaces and not sure if there is use case |
Mahesh Bandewar | 2ad7bf3 | 2014-11-23 23:07:46 -0800 | [diff] [blame] | 12 | outside of it. |
| 13 | |
| 14 | |
| 15 | 2. Building and Installation: |
| 16 | In order to build the driver, please select the config item CONFIG_IPVLAN. |
| 17 | The driver can be built into the kernel (CONFIG_IPVLAN=y) or as a module |
| 18 | (CONFIG_IPVLAN=m). |
| 19 | |
| 20 | |
| 21 | 3. Configuration: |
| 22 | There are no module parameters for this driver and it can be configured |
| 23 | using IProute2/ip utility. |
| 24 | |
Mahesh Bandewar | 4fbae7d | 2016-09-16 12:59:19 -0700 | [diff] [blame] | 25 | ip link add link <master-dev> <slave-dev> type ipvlan mode { l2 | l3 | l3s } |
Mahesh Bandewar | 2ad7bf3 | 2014-11-23 23:07:46 -0800 | [diff] [blame] | 26 | |
| 27 | e.g. ip link add link ipvl0 eth0 type ipvlan mode l2 |
| 28 | |
| 29 | |
| 30 | 4. Operating modes: |
| 31 | IPvlan has two modes of operation - L2 and L3. For a given master device, |
| 32 | you can select one of these two modes and all slaves on that master will |
| 33 | operate in the same (selected) mode. The RX mode is almost identical except |
| 34 | that in L3 mode the slaves wont receive any multicast / broadcast traffic. |
| 35 | L3 mode is more restrictive since routing is controlled from the other (mostly) |
| 36 | default namespace. |
| 37 | |
| 38 | 4.1 L2 mode: |
| 39 | In this mode TX processing happens on the stack instance attached to the |
| 40 | slave device and packets are switched and queued to the master device to send |
| 41 | out. In this mode the slaves will RX/TX multicast and broadcast (if applicable) |
| 42 | as well. |
| 43 | |
| 44 | 4.2 L3 mode: |
Eric Engestrom | edb9a1b | 2016-04-25 07:36:56 +0100 | [diff] [blame] | 45 | In this mode TX processing up to L3 happens on the stack instance attached |
Mahesh Bandewar | 2ad7bf3 | 2014-11-23 23:07:46 -0800 | [diff] [blame] | 46 | to the slave device and packets are switched to the stack instance of the |
| 47 | master device for the L2 processing and routing from that instance will be |
| 48 | used before packets are queued on the outbound device. In this mode the slaves |
| 49 | will not receive nor can send multicast / broadcast traffic. |
| 50 | |
Mahesh Bandewar | 4fbae7d | 2016-09-16 12:59:19 -0700 | [diff] [blame] | 51 | 4.3 L3S mode: |
| 52 | This is very similar to the L3 mode except that iptables (conn-tracking) |
| 53 | works in this mode and hence it is L3-symmetric (L3s). This will have slightly less |
| 54 | performance but that shouldn't matter since you are choosing this mode over plain-L3 |
| 55 | mode to make conn-tracking work. |
Mahesh Bandewar | 2ad7bf3 | 2014-11-23 23:07:46 -0800 | [diff] [blame] | 56 | |
| 57 | 5. What to choose (macvlan vs. ipvlan)? |
| 58 | These two devices are very similar in many regards and the specific use |
| 59 | case could very well define which device to choose. if one of the following |
| 60 | situations defines your use case then you can choose to use ipvlan - |
| 61 | (a) The Linux host that is connected to the external switch / router has |
| 62 | policy configured that allows only one mac per port. |
| 63 | (b) No of virtual devices created on a master exceed the mac capacity and |
Eric Engestrom | edb9a1b | 2016-04-25 07:36:56 +0100 | [diff] [blame] | 64 | puts the NIC in promiscuous mode and degraded performance is a concern. |
Mahesh Bandewar | 2ad7bf3 | 2014-11-23 23:07:46 -0800 | [diff] [blame] | 65 | (c) If the slave device is to be put into the hostile / untrusted network |
| 66 | namespace where L2 on the slave could be changed / misused. |
| 67 | |
| 68 | |
| 69 | 6. Example configuration: |
| 70 | |
| 71 | +=============================================================+ |
| 72 | | Host: host1 | |
| 73 | | | |
| 74 | | +----------------------+ +----------------------+ | |
| 75 | | | NS:ns0 | | NS:ns1 | | |
| 76 | | | | | | | |
| 77 | | | | | | | |
| 78 | | | ipvl0 | | ipvl1 | | |
| 79 | | +----------#-----------+ +-----------#----------+ | |
| 80 | | # # | |
| 81 | | ################################ | |
| 82 | | # eth0 | |
| 83 | +==============================#==============================+ |
| 84 | |
| 85 | |
| 86 | (a) Create two network namespaces - ns0, ns1 |
| 87 | ip netns add ns0 |
| 88 | ip netns add ns1 |
| 89 | |
| 90 | (b) Create two ipvlan slaves on eth0 (master device) |
| 91 | ip link add link eth0 ipvl0 type ipvlan mode l2 |
| 92 | ip link add link eth0 ipvl1 type ipvlan mode l2 |
| 93 | |
| 94 | (c) Assign slaves to the respective network namespaces |
| 95 | ip link set dev ipvl0 netns ns0 |
| 96 | ip link set dev ipvl1 netns ns1 |
| 97 | |
| 98 | (d) Now switch to the namespace (ns0 or ns1) to configure the slave devices |
| 99 | - For ns0 |
| 100 | (1) ip netns exec ns0 bash |
| 101 | (2) ip link set dev ipvl0 up |
| 102 | (3) ip link set dev lo up |
| 103 | (4) ip -4 addr add 127.0.0.1 dev lo |
| 104 | (5) ip -4 addr add $IPADDR dev ipvl0 |
| 105 | (6) ip -4 route add default via $ROUTER dev ipvl0 |
| 106 | - For ns1 |
| 107 | (1) ip netns exec ns1 bash |
| 108 | (2) ip link set dev ipvl1 up |
| 109 | (3) ip link set dev lo up |
| 110 | (4) ip -4 addr add 127.0.0.1 dev lo |
| 111 | (5) ip -4 addr add $IPADDR dev ipvl1 |
| 112 | (6) ip -4 route add default via $ROUTER dev ipvl1 |