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:

openflow

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.

The following two tabs change content below.

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Comments

So empty here ... leave a comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sidebar



%d bloggers like this: