6

A normal switch works independently of the rest of the network. A OpenFlow/SDN switch, when it receives a packet, that it does not have a flow for (Match + exit port) will contact a SDN controller (Server) and ask what must it do with this packet. The controller can then download a flow to the switch, possibly including some packet manipulation. Once the ...


6

No routing protocol is used. The purpose of routing protocols is to tell other routers which paths are available, so the other routers can make a good forwarding decision. In SDN, the controller has a complete view of the network -- it already knows all the paths. The controller calculates the best path for a particular kind of data, and then uses a ...


6

We've always said that SDN Controllers are "Protocol-less", they don't need to know the packet's encoding to switch it. Or, controllers can route packets by the IP Address. And the IP Address used to be encoded on the header of the packet You misunderstand the idea of "protocol-less." It means the controller doesn't run a routing protocol, since it ...


5

Short version: it doesn't. Longer version: Openflow is just a protocol for communicating between the 'forwarding units' and a controller. It is the controller itself that determines what to do with packets, and it can do this in any way it likes. You can implement most of the current routing protocols in an OpenFlow controller, see for instance RouteFlow. ...


4

Openflow is to SDN as OSPF is to Routing


4

Apologies, it took a while to figure out mininet and the OpenFlow ryu controller, but I finally got it... I tried to print haddr_to_str(src), haddr_to_str(dst) and got 00:00:00:00:00:03 and ff:ff:ff:ff:ff:ff which is not what I expected. I wanted to get 2 as source and 3 as dest. The short story is that you're decoding the destination mac address correctly....


4

Yes, the openflow protocol supports the creation of flows with multiple actions, and each action can be to send a frame/packet out a certain port. However, whether or not your openflow switch supports this is a different matter. E.g. this Cisco doc states that only "output to a single port" is supported by version 1.1.5 of their Openflow agent on Nexus ...


4

When a packet is received at an SDN switch that doesn't have a rule associated with it, it gets forwarded to the controller. Now, the controller may choose to drop it, or do something special (like log it and then forward). This behavior is key to implementing many Openflow features, like learning switches. https://github.com/mininet/openflow-tutorial/wiki/...


4

You could solve this by running VXLAN on the hypervisor using software like FRR. That would imply that you run a full mesh BGP setup between your hypervisors, or use route reflectors. Then, you can create as many VNI's between your hypervisors which can be used as VPC's between virtual machines. We've done this in a test setup and it seems to work, so we're ...


3

Finally I figured out what was wrong: After creating the qos and queues, it's necessary to define the flows, like this: sudo ovs-ofctl add-flow s3 in_port=1,dl_type=0x0800,nw_proto=6,tp_dst=666,priority=100,actions=set_queue:1,normal sudo ovs-ofctl add-flow s3 in_port=1,dl_type=0x0800,nw_proto=6,tp_dst=555,priority=100,actions=set_queue:0,normal sudo ovs-...


3

An SDN controller generally doesn't forward user data (at least not with OpenFlow). It often only gets a digest from an unmatched packet (the essential data extracted), so there might even be nothing to forward.


2

Let's say you have multiple openflow enabled switches with virtual and physical hosts connected to the same controller. As long as they are reachable through the network when you link the switch to the controller, controller is aware of them. You can check this in the controller's topology. (Eg: In the case of ovs, you do "ovs-vsctl set-controller br0 tcp::...


2

Hidden flows in OVS are used by the controller to talk to the switch, you typically won't want these to show up in Netflow hence they are hidden by default. If you use the command; 'ovs-ofctl dump-flows br' you will get all flows except the hidden ones, if you use the command; 'ovs-appctl bridge/dump-flows br' you'll also get the hidden ones. Megaflows are ...


2

Ingress policing on OVS is not implemented using OpenFlow, but is implemented as a Token Bucket, according to the OVS manual. The size of the bucket corresponds to ingress_policing_burst. Initially the bucket is full. Whenever a packet is received, its size (converted to tokens) is compared to the number of tokens currently in the bucket. If the ...


2

This is a nice idea. We are using Floodlight for our SDN experiments. At the point in time we started, it was much more mature than the OpenDaylight software. As this has been more than a year ago, it might not be true anymore. SDN offers you the following features that should be helpful to your use case: Link parameter measurements to find such paths: ...


2

Openflow is just the protocol used for communicatuin between the controller and a switch. This is considered the southbound communication. SDN is too vague and over used. There is no direct comparison. However openflow would fall under the SDN umbrella. If you want to compare openflow, then compare it to a proprietary protocol doing the same ...


2

The Controller doesn't do anything right away - it does not know this event has occurred. The initial decision to be made has to be made by the device that received the packet it can't match. It may decide (due to configuration) to send that packet to the Controller, but simple math indicates that this doesn't scale (the management interface is very slow ...


2

If by Ethernet, you mean Ethernet 'frames' then that packet is sent to the Controller. The Controller then instructs the Switch about packet modification and actions for output port. Alternatively, the Switch may just send a 'pointer' to the packet rather than sending the whole packet to the Controller.


2

It is the default flow that sends all packets to the controller. The controller can then install new flows, or process the packets via PACKET_OUT messages. I believe that if you use the -m or --more argument it will show you that it is actually a flow that matches all fields wildcarded. This is omitted by default.


2

I found that using Group Tables that is supported in OpenFlow since version 1.1 of the standard, it is possible to replicate and process a packet through multiple buckets of actions. If a group table entry is from type "ALL", then all action buckets in the group are executed which can be used to forward a packet to multiple outgoing ports. A number of ...


2

When the network is set up, the controller on recognizing the switch has been added to the network will install the default rule to ensure it gets messages from that switch that are not resolved by higher priority rules. All subsequent rules installed are considered higher priority. but in real networks we cannot connect each switch directly to the ...


2

One of the characteristics of SDN is that the controllers are not in the forwarding path. So, s1 and s2 need a path between them, not the controllers.


2

The function you are looking for is Network Address Translation (NAT), which you would most likely need to use the misc.nat tool. The usage is documented in nat.py located here: https://github.com/noxrepo/pox/blob/eel/pox/misc/nat.py


1

The difference between an ACL and a firewall is keyword stateful. A firewall keeps a state table whereas a basic ACL simply filters based on layer 3/4 properties. In a router, firewall functionality has been called Context based acccess control, CBAC. There are also reflexive ACL's. We now have NGFW's with deepest packet inspection (application aware ...


1

Good question. The 5 second, and facetious answer is that OpenSwitch needs real wires and ports whereas OpenVswitch doesn't. In more detail: OpenSwitch is switching software that you ultimately deploy onto a physical switch. Think of it as the equivalent of IOS or CatOS or JunOS. It's going to be controlling some real hardware ports. OpenVSwitch, on the ...


1

Yes. To be more precise, the openflow protocol defines the set-field action, but it depends on the switch implementation whether or not it supports this, and which fields can be modified if it does. E.g. this doc mentions that the openflow agent on Cisco NXOS switches support (among others) following actions: Rewrite source MAC address (SMAC) ...


1

SDN is a concept of a network that virtualizes it control plane and allows it to be programmable (Therefore it has the name "Software-Defined"). Whether you look inside of SDN, you'll see a set of protocols and tools for enabling software defined. One of this protocols is the OpenFlow, however you have another protocols that does almost the same stuff (NFV - ...


1

Short answer: because merely routing isn't enough. In modern enterprise or service provider networks, there is usually a requirement to treat certain types of traffic differently than others. For example, real-time traffic such as voice or video often requires a minimum amount of delay. Other traffic may require a minimum amount of bandwidth. Certain ...


1

The architecture of SDN prevents stateful in-line processing of packet flows (ignoring using firewall hardware, NFV or experimental stateful switches). Therefore anything that monitors the state of a flow requires that state to be held by the controller. This causes unacceptable workload for the controller and increases state held across (typically) ...


1

There are applications and appliances which can perform load balancing as you described, but it may be for resources other than servers. The load balancer will have a fixed, known IP address, and that is the address which hosts will use to access a resource on the other side of the load balancer. The requesting host will really have no idea which resource ...


Only top voted, non community-wiki answers of a minimum length are eligible