In the previous A programmable router using SDN on Cisco XNC/OpenDaylight and Floodlight we implemented a very simple L3 routing using SDN. To achieve the results we used a dumb host (H3) which answers to ARP requests.
The question is: SDN can be used for L3 routing?
The answer is: it depends. Currently Fundação CPqD do not support ARP request answering. This means that OpenFlow switches cannot answer to ARP requests without an external help. In the previous article the external help was given by Host 3, configured with many IP addresses, one for each network.
In this post we answers to the ARP request using a SDN controller. To my knowledge, currently Cisco XNC/OpenDaylight and Floodlight do not support this features, so POX is used. POX is
a framework for interacting with OpenFlow switches, we’re using it as the basis for some of our ongoing work to help build the emerging discipline of Software Defined Networking. We’re using it to explore and prototype distribution, SDN debugging, network virtualization, controller design, and programming models. Our ultimate goal is to develop an archetypal, modern SDN controller.
POX is included in the MiniNet OVF: MiniNet as an SDN test platform one more instance of that VM.
In this post we have the same scenario of the previous post:
- H1: ip 192.168.1.1⁄24, mac 00:00:00:00:00:01, gateway 192.168.1.254
- H2: ip 192.168.2.2⁄24, mac 00:00:00:00:00:02, gateway 192.168.2.254
H3 is not needed this time.
Let’s start the MiniNet VM dedicated to the POX controller:
cd pox ./pox.py misc.arp_responder --192.168.1.254=00:00:00:00:01:fe --192.168.2.254=00:00:00:00:02:fe
Let’s start the MiniNet VM dedicated to the MiniNet test lab:
sudo mn --controller=remote,ip=192.168.32.134 --topo=single,3 --mac
We can immediately see that the POX controller has installed a flow entry:
mininet> dpctl dump-flows *** s1 ------------------------------------------------------------------------ NXST_FLOW reply (xid=0x4): cookie=0x0, duration=3.669s, table=0, n_packets=0, n_bytes=0, idle_age=3, priority=28672,arp actions=CONTROLLER:65535
All ARP packets will be sent to the controller, as expected. Let’s move on with the configuration: H1 and H2 hosts must be configured into two different network.
mininet> h1 ifconfig h1-eth0 192.168.1.1 netmask 255.255.255.0 mininet> h1 route add default gw 192.168.1.254 mininet> h2 ifconfig h2-eth0 192.168.2.2 netmask 255.255.255.0 mininet> h2 route add default gw 192.168.2.254
Because ARP protocol is managed by POX, only two flows must be installed:
mininet> dpctl add-flow ip,dl_dst=00:00:00:00:01:fe,nw_dst=192.168.2.2,actions=mod_dl_dst:00:00:00:00:00:02,normal mininet> dpctl add-flow ip,dl_dst=00:00:00:00:02:fe,nw_dst=192.168.1.1,actions=mod_dl_dst:00:00:00:00:00:01,normal
And now H1 can ping H2:
mininet> h1 ping -c 1 192.168.2.2 PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. 64 bytes from 192.168.2.2: icmp_req=1 ttl=64 time=0.048 ms --- 192.168.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.048/0.048/0.048/0.000 ms
- L3 forwarding cannot be implemented with OpenFlow 1.3 specifications. L3 forwarding is achieved by SDN controllers.
- If the SDN (POX) controller is not available, obviously there are no more answers to the ARP requests for the gateway IP addresses. In other words hosts which hold ARP entries can communicate with external networks, others cannot.