Openflow support is now available on Juniper EX switches in version 13.3 of code. I decided to explore and test this out. I first needed to find an Openflow compatible Juniper platform. The EX9200 supports Openflow, but you have to add the openflow image to JUNOS
jnpr@EX9200-RE0>request system software add <jsdn-package-name>
After installation you should see it as a module:
jnpr@EX9200-RE0# run show version
Hostname: EX9200-RE0
Model: ex9204
Junos: 13.3R1.6
JUNOS Base OS boot [13.3R1.6]
JUNOS Base OS Software Suite [13.3R1.6]
JUNOS 64-bit Kernel Software Suite [13.3R1.6]
[TRUNCATED]
JUNOS py-base-i386 [13.3R1.6]
JUNOS SDN Software Suite [13.3R1.6]
There are a few possible operational commands:
jnpr@EX9200-RE0> show openflow ?
Possible completions:
capability Show feature and configuration capability
controller Show controller information and connection status
filters Show filter information
flows Show flow information
interfaces Show interface information
statistics Show statistics commands
summary Show openflow information summary
switch Show switch instance description information
To configure openflow, you need to:
1) Create interfaces
2) Associate those interfaces to an OPENFLOW resource group (ie. a virtualized switch)
3) Point to the Openflow controller to receive commands.
First, the creation of interfaces. This is very basic, it's similar to creating normal switching interfaces:
jnpr@EX9200-RE0# show interfaces
xe-2/0/0 {
unit 0 {
family ethernet-switching {
vlan {
members v100;
}
}
}
}
xe-2/0/1 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members v100;
}
}
}
}
[edit]
jnpr@EX9200-RE0# show vlans
v100 {
vlan-id 100;
}
Next, you need to place these interfaces into an Openflow resource group (ie a virtualized switch) and map those interfaces to a port-id that Openflow can understand.
jnpr@EX9200-RE0# show protocols openflow
switch OF-SWITCH-92k {
default-action {
packet-in;
}
interfaces {
xe-2/0/0.0 port-id 1;
xe-2/0/1.0 port-id 2;
}
}
Then you'll need to point to an openflow controller.
set protocols openflow switch OF-SWITCH-92k controller address 10.161.11.77
By default, openflow communicates over TCP using port 6633
Once committed, the EX will continously try to communicate with the openflow server.
jnpr@EX9200-RE0# run show openflow controller
Openflowd controller information:
Controller socket: 12
Controller IP address: 10.161.11.77
Controller protocol: tcp
Controller port: 6633
Controller connection state: down
Number of connection attempt: 10
Controller role: equal
If the EX was correctly communicating with the controller, the connection state should say "up".
jnpr@EX9200-RE0# run show openflow switch
Switch Name: OF-SWITCH-92k
Switch ID: 0 Switch DPID: 00:00:3c:8a:b0:0d:c7:c0
Flow mod received: 6 Vendor received: 0
Packets sent: 841 Packets received: 845
Echo req sent: 833 Echo req received: 0
Echo reply sent: 0 Echo reply received: 833
Port Status sent: 0 Port mod received: 0
Barrier request: 0 Barrier reply: 0
Error msg sent: 0 Error msg received: 0
The DPID or DataPathIdentifier is the physical switch that will be programmed. We'll see where this comes into play later.
I created an Ubuntu VM and installed the POX openflow controller. It's Python based which is awesome since it's a language I can understand. There's Floodlight (Java) or Trema (Ruby), so choose the flavor that you're comfortable with.
To simply start with there is a very basic POX python module found under the forwarding directory. This is the module we'll start with just to demonstrate how this works.
jnpr@ubuntu:~/OPENFLOW-CONTROLLER$ ./pox.py log.level --DEBUG forwarding.hub
POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.
INFO:forwarding.hub:Hub running.
DEBUG:core:POX 0.2.0 (carp) going up...
DEBUG:core:Running on CPython (2.7.5+/Feb 27 2014 19:37:08)
DEBUG:core:Platform is Linux-3.11.0-12-generic-x86_64-with-Ubuntu-13.10-saucy
INFO:core:POX 0.2.0 (carp) is up.
DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
INFO:forwarding.hub:Hubifying 3c-8a-b0-0d-c7-c0 <<<< DPID of the EX Switch
What this does to the EX switch basically turns those two interfaces in a small hub.
On POX the gist of the python script is this:
msg = of.ofp_flow_mod()
msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))
In Openflow terminology:
OFPP_FLOOD - output all openflow ports except the input port and those with flooding disabled
And that's it.
On the EX the Openflow rule looks like this:
jnpr@EX9200-RE0# run show openflow flows detail
Flow name: flow-65536
Table ID: 1 Flow ID: 65536
Priority: 32768 Idle timeout(in sec):0 Hard timeout(in sec): 0
Match: Input port: wildcard
Ethernet src addr: wildcard
Ethernet dst addr: wildcard
Input vlan id: wildcard Input VLAN priority: wildcard
Ether type: wildcard
IP ToS: 0x0 IP protocol: 0x0
IP src addr: 0.0.0.0/32 IP dst addr: 0.0.0.0/32
Source port: 0 Destination port: 0
Action: Output port 65531,
The Action: Output port 65531 basically means everything available openflow interface but where the source of the packet came in on.
I setup a few tester ports to send constant traffic at a very low rate. ~1 pps
jnpr@EX9200-RE0# run show openflow statistics interfaces
Switch Name: OF-SWITCH-92k
Interface Name: xe-2/0/0.0 Port Number: 1
Num of rx pkts: 12 Num of tx pkts: 12
Num of rx bytes: 17952 Num of tx bytes: 17952
Num of rx error: 0 Num of tx error:0
Number of packets dropped by RX: 0
Number of packets dropped by TX: 0
Number of rx frame error: 0
Number of rx overrun error: 0
Number of CRC error: 0
Number of collisions: 0
Switch Name: OF-SWITCH-92k
Interface Name: xe-2/0/1.0 Port Number: 2
Num of rx pkts: 12 Num of tx pkts: 12
Num of rx bytes: 17952 Num of tx bytes: 17952
Num of rx error: 0 Num of tx error:0
Number of packets dropped by RX: 0
Number of packets dropped by TX: 0
Number of rx frame error: 0
Number of rx overrun error: 0
Number of CRC error: 0
Number of collisions: 0
In my next blog entry I'll tweak a POX module to create flow rule entries that coincide more with SDN programming than turning your expensive switch into an expensive hub.
No comments:
Post a Comment