Topology mapping for SDN OpenFlow networks with Nectus
Nectus can monitor OpenFlow capable devices in the same way as the non-OpenFlow devices.
In this article we will show how Nectus can discover and monitor switches that are SDN OpenFlow ready.
We will use following sample topology for demonstration with Floodlight OpenFlow controller and three OpenFlow switches:
The EX9200 is configured to run OpenFlow on all interfaces:
[edit]
root@ex9204-re0# show protocols openflow switch EX9200 interfaces
xe-0/0/3.0;
xe-0/0/5.0;
xe-0/0/6.0;
xe-0/0/4.0;
[edit]
root@ex9204-re0#
On the controller side, two flows were pushed to the EX9200 to do the following:
– If a packet comes from interface xe-0/0/3, then it must be sent through interface xe-0/0/5
– If a packet comes from interface xe-0/0/5, then it must be sent through interface xe-0/0/3
These two flows assure bidirectional communication between the two tester devices through the OpenFlow capable device.
To keep the output simple, here are the port identifiers for all four OpenFlow enabled interfaces:
[edit]
root@ex9204-re0# run show openflow interfaces | no-more
Switch name: EX9200
Interface Name: xe-0/0/5.0
Interface port number: 38956
Switch name: EX9200
Interface Name: xe-0/0/3.0
Interface port number: 34887
Switch name: EX9200
Interface Name: xe-0/0/4.0
Interface port number: 38736
Switch name: EX9200
Interface Name: xe-0/0/6.0
Interface port number: 39049
[edit]
root@ex9204-re0#
On controller side, it can be easily seen which interfaces were enabled for OpenFlow on the switch and what were the rules pushed into the switch:
The flows can be checked on switch level as well(again just to keep the output simple, some part of it was removed). The rule with priority 0 is the default one:
[edit]
root@ex9204-re0# run show openflow flows detail | no-more
Flow name: flow-65536
Table ID: 1 Flow ID: 65536
Priority: 0 Idle timeout(in sec):0 Hard timeout(in sec): 0
Cookie: 0
Match: Input port: wildcard
Action: Output port CONTROLLER,
Flow name: flow-33619968
Table ID: 1 Flow ID: 33619968
Priority: 102 Idle timeout(in sec):0 Hard timeout(in sec): 0
Cookie: 45035999530541090
Match: Input port: 38956
Action: Output port 34887,
Flow name: flow-16842752
Table ID: 1 Flow ID: 16842752
Priority: 101 Idle timeout(in sec):0 Hard timeout(in sec): 0
Cookie: 45035999861269506
Match: Input port: 34887
Source port: wildcard Destination port: wildcard
Action: Output port 38956,
[edit]
root@ex9204-re0#
To confirm that the traffic flows according to the OpenFlow rules, 100 ICMP packets were sent between the two tester devices.
This means that each flow had 100 packets(100 echo requests and 100 echo replies).
{master:0}[edit]
root@qfx5100-48s-6q# run ping 10.10.10.5 source 10.10.10.3 count 100 rapid
PING 10.10.10.5 (10.10.10.5): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
— 10.10.10.5 ping statistics —
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.783/12.039/58.854/6.001 ms
{master:0}[edit]
root@qfx5100-48s-6q#
These are the statistics on the OpenFlow enabled interfaces:
And this is from flows level:
Now that everything works as expected through the OpenFlow capable switch, let us see how Nectus can discover and visualize Layer 2 and Layer 3 topology.
After running discovery Nectus built this Layer 2 network topology showing that SDN devices are connected just like any other networking devices:
For Layer 3 Nectus built this diagram with 10.10.10.0/24 subnet between two SDN devices:
Summary: Nectus Topology mapping and monitoring for OpenFlow SDN devices works in the same way as with regular switches.
The same basic performance metrics such as Interface utilization, CPU or RAM usage can be monitored on any of SDN devices with Nectus NMS.