OpenFlow on Juniper EX9200
As you might know, starting with 13.3R1, Juniper EX9200 support OpenFlow 1.0.
Openflow is a standard that allows to control traffic through a central network controller.
To control the traffic in this manner, one would need an Openflow controller and Openflow capable switch.
Using Openflow, one can add, delete, modify flows in the network. Flows are a set of match conditions and they are implemented using filters.
The filters are applied on input direction and it can contain multiple terms.
Each flow has a priority which can determine the position of the term(flow) in the filter. The higher priority terms are installed above the lower priority terms.
In JUNOS, the Openflow traffic is isolated through virtual switches. Each virtual switch contains the Openflow controller, the interfaces participating in Openflow and the default action for the traffic incoming/outgoing on these interfaces.
The interfaces participating in Openflow forwarding must be configured in L2 mode and MAC learning is disabled.
EX9200 requires that a virtual switch routing instance to be configured.
There is also a default action on what to do with the packets that arrive on Openflow enabled interface for which a flow doesn’t exist.
The default action is ‘packet-in’ which means that the packet is sent to the controller. The other possible action is to ‘drop’ the packets which don’t match any existing flow.
There are few timers that you need to be aware of:
– idle-timeout – the number of seconds after which a flow is removed from hardware when there are no matching packets.
– hard-timeout – the number of seconds after which a flow is removed from hardware regardless there are matching packets.
– purge-flow-timer – the number of seconds after which an invalid flow is removed from the flow table.
Idle-timeout and hard-timeout are configured on the controller, whereas purge-flow-timer is configured on Juniper device.
This is the test topology:
This is the configuration on EX9204:
[edit]
lab@EX9204-re0# show protocols openflow
switch SW1 {
default-action {
packet-in;
}
interfaces {
ge-0/3/6.0;
ge-0/3/7.0;
}
controller {
protocol {
tcp {
port 6633;
}
}
address 172.30.145.126;
}
}
[edit]
lab@EX9204-re0# show routing-instances
OPENFLOW-RI {
instance-type virtual-switch;
interface ge-0/3/6.0;
interface ge-0/3/7.0;
vlans {
OF {
vlan-id none;
}
}
}
[edit]
lab@EX9204-re0# show interfaces ge-0/3/6
unit 0 {
family ethernet-switching {
vlan {
members OF;
}
}
}
[edit]
lab@EX9204-re0# show interfaces ge-0/3/7
unit 0 {
family ethernet-switching {
vlan {
members OF;
}
}
}
[edit]
lab@EX9204-re0#
Let’s check few operational commands:
[edit] lab@EX9204-re0# run show openflow controller Openflowd controller information: Controller socket: 12 Controller IP address: 172.30.145.126 Controller protocol: tcp Controller port: 6633 Controller connection state: up Number of connection attempt: 1 Controller role: equal [edit] lab@EX9204-re0# run show openflow switch Switch Name: SW1 Switch ID: 0 Switch DPID: 00:00:b0:a8:6e:ff:97:c0 Flow mod received: 17034 Vendor received: 0 Packets sent: 87916 Packets received: 182372 Echo req sent: 19813 Echo req received: 2 Echo reply sent: 2 Echo reply received: 19813 Port Status sent: 2 Port mod received: 0 Barrier request: 0 Barrier reply: 0 Error msg sent: 17006 Error msg received: 0 [edit] lab@EX9204-re0# run show openflow interfaces Switch name: SW1 Interface Name: ge-0/3/6.0 Interface port number: 59294 Interface Hardware Address: b0:a8:6e:ff:91:f5 Interface speed: 1Gb Full-duplex Interface Auto-Negotiation: Enabled Interface media type: Fiber Interface state: Up Switch name: SW1 Interface Name: ge-0/3/7.0 Interface port number: 59362 Interface Hardware Address: b0:a8:6e:ff:91:f6 Interface speed: 1Gb Full-duplex Interface Auto-Negotiation: Enabled Interface media type: Fiber Interface state: Up [edit] lab@EX9204-re0#
As you can see, in the above output, I highlighted few things which are needed when you try to push the flows from a controller to a Openflow enabled switch:
– DPID – this is the identifier of the switch in Openflow
– Interface port number – this is the identifier of the interfaces in Openflow
As you can see, the default action was configured ‘packet-in’ which means that all the packets are sent to the controller.
[edit]
root@PC_1# run ping 100.100.100.2 count 2
PING 100.100.100.2 (100.100.100.2): 56 data bytes
64 bytes from 100.100.100.2: icmp_seq=0 ttl=64 time=41.854 ms
64 bytes from 100.100.100.2: icmp_seq=1 ttl=64 time=41.460 ms
--- 100.100.100.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 41.460/41.657/41.854/0.197 ms
[edit]
root@PC_1#
Although the hosts are directly connected to EX9204, you can see that average round-trip is 40ms, so this is a good indication that the packets are sent somewhere else as well(in this case to the controller).
Let’s push two flows on the Openflow controller to allow the traffic between the two MAC addresses from the topology:
curl -d '{"switch": "00:00:b0:a8:6e:ff:97:c0", "name":"static-2-to-1", "cookie":"0", "priority":"101", "dst-mac":"00:19:e2:53:9c:1a",
"src-mac":"00:26:88:6e:82:5a","active":"true", "actions":"output=59294"}' http://127.0.0.1:8080/wm/staticflowentrypusher/json
{"status" : "Entry pushed"}
curl -d '{"switch": "00:00:b0:a8:6e:ff:97:c0", "name":"static-1-to-2", "cookie":"0", "priority":"100", "dst-mac":"00:26:88:6e:82:5a",
"src-mac":"00:19:e2:53:9c:1a","active":"true", "actions":"output=59362"}' http://127.0.0.1:8080/wm/staticflowentrypusher/json
{"status" : "Entry pushed"}
Basically these two flows are saying this:
– static-2-to-1 – if the source MAC address is 00:26:88:6e:82:5a and destination MAC address is 00:19:e2:53:9c:1a, then send this packet to port 59294(ge-0/3/6)
– static-1-to-2 – if the source MAC address is 00:19:e2:53:9c:1a and destination MAC address is 00:26:88:6e:82:5a, then send this packet to port 59362(ge-0/3/7)
Remember you need to create a flow for each direction of the traffic.
Let’s check if the flows were pushed to EX9204:
[edit]
lab@EX9204-re0# run show openflow flows detail
Flow name: flow-234946560
Table ID: 1 Flow ID: 234946560
Priority: 100 Idle timeout(in sec):0 Hard timeout(in sec): 0
Match: Input port: wildcard
Ethernet src addr: 00:19:e2:53:9c:1a
Ethernet dst addr: 00:26:88:6e:82:5a
Input vlan id: wildcard Input VLAN priority: wildcard
Ether type: wildcard
IP ToS: wildcard IP protocol: wildcard
IP src addr: wildcard IP dst addr: wildcard
Source port: wildcard Destination port: wildcard
Action: Output port 59362,
Flow name: flow-218169344
Table ID: 1 Flow ID: 218169344
Priority: 101 Idle timeout(in sec):0 Hard timeout(in sec): 0
Match: Input port: wildcard
Ethernet src addr: 00:26:88:6e:82:5a
Ethernet dst addr: 00:19:e2:53:9c:1a
Input vlan id: wildcard Input VLAN priority: wildcard
Ether type: wildcard
IP ToS: wildcard IP protocol: wildcard
IP src addr: wildcard IP dst addr: wildcard
Source port: wildcard Destination port: wildcard
Action: Output port 59294,
[edit]
lab@EX9204-re0#
Now you can see that the round-trip average time dropped, because the packets are not sent anymore to the controller:
[edit]
root@PC_1# run ping 100.100.100.2 count 2
PING 100.100.100.2 (100.100.100.2): 56 data bytes
64 bytes from 100.100.100.2: icmp_seq=0 ttl=64 time=1.788 ms
64 bytes from 100.100.100.2: icmp_seq=1 ttl=64 time=4.008 ms
--- 100.100.100.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.788/2.898/4.008/1.110 ms
[edit]
root@PC_1#
These are the filters installed after the flows were pushed from the controller:
[edit]
lab@EX9204-re0# run show openflow filters
Switch Filter Number of Number of Number of
Name Index terms priorities packets
SW1 96468993 2 2 383
SW1 96468992 2 2 24
[edit]
lab@EX9204-re0#
As you can see, each filter has two terms: one is to match the source MAC and the other is to match the destination MAC.
Let’s change the default action to ‘drop’ so that all the packets that do not match a flow are dropped.
In the same time, I will remove one of the flows so that the ICMP reply will not be forwarded by the EX9204:
[edit]
lab@EX9204-re0# show | compare rollback 1
[edit protocols openflow switch SW1 default-action]
- packet-in;
+ drop;
[edit]
lab@EX9204-re0#
In EX9204, only the flow for packets from PC_1 to PC_2 was installed:
[edit]
lab@EX9204-re0# run show openflow flows detail
Flow name: flow-251723776
Table ID: 1 Flow ID: 251723776
Priority: 100 Idle timeout(in sec):0 Hard timeout(in sec): 0
Match: Input port: wildcard
Ethernet src addr: 00:19:e2:53:9c:1a
Ethernet dst addr: 00:26:88:6e:82:5a
Input vlan id: wildcard Input VLAN priority: wildcard
Ether type: wildcard
IP ToS: wildcard IP protocol: wildcard
IP src addr: wildcard IP dst addr: wildcard
Source port: wildcard Destination port: wildcard
Action: Output port 59362,
[edit]
lab@EX9204-re0#
As you can see, the ping is failing:
[edit]
root@PC_1# run ping 100.100.100.2 count 2
PING 100.100.100.2 (100.100.100.2): 56 data bytes
^C
--- 100.100.100.2 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
[edit]
root@PC_1#
PC_2 is receiving the ICMP request, it is sending the ICMP reply, but this is dropped by the EX9204:
{master:0}[edit]
root@PC_2# run monitor traffic interface ge-0/0/23 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-0/0/23, capture size 96 bytes
08:53:27.060882 In IP truncated-ip - 24 bytes missing! 100.100.100.1 > 100.100.100.2: ICMP echo request, id 39608, seq 22, length 64
08:53:27.060932 Out IP truncated-ip - 24 bytes missing! 100.100.100.2 > 100.100.100.1: ICMP echo reply, id 39608, seq 22, length 64
08:53:28.061841 In IP truncated-ip - 24 bytes missin^C
4 packets received by filter
0 packets dropped by kernel
{master:0}[edit]
root@PC_2#
Regarding the Openflow controller, there are many available that you can use.
The easiest for me was to download the Vmware appliance from Project Floodlight.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Comments
So empty here ... leave a comment!