Alcatel-Lucent LAB sobre SDN y OS6900. (Parte I)
En las próximas entradas iré publicando la forma de montar un pequeño laboratorio basado en los OmniSwitch 6900, con el objetivo de tener una idea real de lo que es SDN, y cómo aplicar este nuevo paradigma en una red en explotación.
La mayoría de las personas, tiende a vincular directa y unívocamente SDN con OpenFlow, pero la realidad es que SDN es un concepto muchísimo más amplio, que puede resumirse en la capacidad del equipamiento de nueva generación de networking (ya sea físico o virtual) para ser gestionado desde aplicaciones externas que activan, modifican y destruyen los servicios de red en función de determinados eventos, que varían dependiendo de cada red, cliente y aplicación.
Dentro de Alcatel-Lucent disponemos de diversas soluciones SDN, aunque en esta serie de entradas vamos a tratar esa que todo el mundo tiene en la cabeza: OpenFlow.
Me vais a permitir que cambie a inglés, ya que quiero que otros puedan aprovechar esta pequeña introducción.
First, what are we going to do in this small test-bed?, well a DDoS (Distributed Denial of Service attack) avoidance SDN Application. Obviously this is just a small lab, so the ddos attack will be a simulation.
Many of you may now be asking… What is the overall picture? Ok, here it is:
Let’s see the different components:
- OmniSwitch 6900 (OS6900): The Alcatel-Lucent OmniSwitch OS6900 is supporting SDN integration either using REST interface (JSON) or OpenFlow.
In this case, the OS6900-T40 (40 port copper – RJ45- , 100Mbps/1GE/10GE auto-sensing) is used, in conjunction with the 4 x 1GE/10GE-SFP+ expansion module.
OS6900 do support OF1.0 and OF1.3.1. In this scenario OF1.0 will be used, as Floodlight and POX controllers are supporting OF1.0 (up to the date of this lab, only Ryu was supporting OF1.3.1, apart from other proprietary SDN controllers)
The REST interface is much richer in functions that any OF interface, as the REST interface has full access to the OS6900 features. This is the right interface to use if advanced features are required (lossless ethernet, vrf, etc.)
The OpenFlow (OF) interface is limited to the OF standard release, that is OF1.0 has lower functionality that OF1.3.1. Obviously, extended features can be used in the “vendor-specific” messages of OF, in order to benefit from the hardware capabilities. In that case, new modules must be added to the existing SDN OF controller (POX, NOX, Floodlight, Ryu, or whatever other OF Controller)
OS6900 do support two OpenFlow modes of operation: Hybrid (API) and Full.
In Hybrid mode, the defined virtual switch into the OS6900 will continue to work as a switch, that is, running whatever control protocol for L2/L3 network (Shortest Path Bridging in our extended-example, yes will be an extended example with 4 x OS6900 running SPBm + OF), doing routing, application fingerprinting, and the rest of very nice features the OmniSwitch family has. But SDN controllers can push flows into the tables (table in our example as we’re using OF1.0), that the OS6900 will apply as it were running in Full-OF mode.
In Full mode, the defined virtual switch running into the OS6900 will work as a pure OF switch, that is, will block ALL traffic until the SDN controller push the flows into the tables (table, in singular for OF1.0)
OS6900 supports some vswitches running in Full mode plus one vswitch running in Hybrid mode.
Ports configured into one vswitch are managed by that vswitch, creating an isolated domain.
- InMon sFlow-RT is the sFlow collector. sFlow-RT will gather information from OS6900 (and mininet) and raise events in case that some thresholds are reached.
In our example, sFlow-RT will run in a Virtual Machine (VM). The guest operating system chosen is Xubuntu, as our server is running XenServer in free licencing mode, and GPU is not passed to the VM. Running Ubuntu with Unity in such conditions (including VPN access and so…) could be a pain, so moved to Xubuntu (XFCE, Lubuntu or LXDE would do the job perfectly as well)
Xubuntu, Kubuntu, Lubuntu and many other distributions are based on Ubuntu, so when talking about Ubuntu, it’s like talking of those distros.
We’ll go into some details when setting up the VM for all the systems.
- Floodlight SDN controller. If I manage to get the time, POX SDN controller will also be included in the LAB, but ritgh now, Floodlight is the chosen controller for staring the LAB.
Floodlight currently supports OF1.0, is written in Java, so will not be so difficult to create ad-hoc modules that will allow the SDN controller program the switches according to the requirements.
POX and NOX are SDN OF controllers as well. POX is build with Python, while NOX is completely done in C++. So if you are considering an SDN controller for Real applications, where speed and scalability is needed, consider to use NOX. In our LAB, POX has demonstrated to be fast and flexible even for real deployments, but for very large networks, NOX would be the recommended.
Floodlight SDN controller will run in a VM as well, over Xubuntu.
- Mininet. This is an awesome tool for testing virtual environments, such us virtual switch, open-vswitch, OpenFlow, etc.
The purpose of mininet here is just having another testing environment, I’ll explain how to set up it, but won’t be part of the test, as will be based on OS6900. But, all this test can be perfectly done using mininet,
Mininet will be another VM, running on Xubuntu.
- Two test PCs. These two PCs are VM as well, running Ubuntu 12.10.
These VM are instantiated in another physical server, which has several NICs, so each VM has a dedicated Ethernet interface, to easy the cabling and being able to connect a VM to any interface in our LAB (which is pretty large).
In our scenario, VM1 is connected to OS6900 port 1/1, and VM2 is connected to OS6900 port 1/2. The VM1 will act as the ddos attacker, and VM2 is the server we want to protect.
A short image of the XenCenter with the two hosts, and the VM already running:
Before moving ahead, just an important consideration about the virtualization platform. I’m using Citrix/Xen because these servers are part of our Datacenter Demo, integrated into OmniVista 2500 Virtual Machine Manager. But any virtualization platform can be used, either VirtualBox (a very good choice), vmware, hyper-v, KVM, or whatever.
To conclude this first section, let’s have a look at the overall protocol messages the LAB will consider:
This is the regular behaviour, where the PC1 is sending a regular ping to PC2. In this case, as the OS6900 is working in HYBRID mode, the well-known (with their advantages and drawbacks) Ethernet and routing protocols take control and allows the flow (ARP, ICMP, IP, TTL change, etc.)
Our SDN-APP instructs sFlow-RT to monitor an specific flow, characterized by the IP-SA, IP-DA, what to measure (packets/sec.) and the threshold, that will generate an event to SDN-APP, when reached. This flow is named “ddos”.
Now PC1 starts a “ping flooding” to PC2, so the packets/sec. dramatically grows up. Such packet-rate is reported by the OS6900, and sent to sFlow-RT, who detects that rate exceeds the defined threshold, and raises an event to our SDN-APP.
The event received by SDN-APP has some information in order to react. For instance the “agent” IP address. So SDN-APP send a request to Floodlight asking for information about all vswitches registered in the controller. The information coming back from Floodlight contains the vswitches IP addresses, and the DPID, which is the real field needed in order to interact with any SDN controller. The DPID is the MAC address of the vswitch, and it’s used in the communications between the vswitch and the SDN controller.
With the DPID and the flow that needs to be blocked, we command the SDN controller to push a flow into the vswitch table, blocking the attacker traffic (dropping packets).
Then, a back-off timer is started, hoping the DDoS attack will stop. If DDoS attack persists, traffic is blocked again.
Once the DDoS attack stops, the flow is allowed again, and normal functioning is recovered.
Obviously it’s just an example of what a coordinated infrastructure can do. And be aware that this is not because OpenFlow, it’s because all the actors have OPEN, WELL-KNOWN and STABLE interfaces. REST, OpenFlow, SNMP, NetConf, XML, or whatever any method of interchanging information between actors is the KEY for a COORDINATED solution.
Stay tuned for Part II !!!