I still don't entirely understand your topology; it seems like you're doing something a bit unusual. Are the nodes in your topology switches or hosts? Or both (that is, they're acting as hosts running services or hosting users or whatever, but they've also got OVS installed)? If they're switches, are you doing in-band control? Are they connected with tunnels? What are these IP addresses actually the IP addresses of?
I am making a bunch of guesses here. Tell me which of them are wrong. I am guessing that they're all running OVS. The IP addresses you've shown are the IP of the machine's main physical interface (e.g., eth0). You've created tunnels along the paths you've shown and added the tunnel endpoints to OVS. Now what you'd like to do is when a fine-grained (e.g. exact match) flow comes in on some non-tunnel interface, you'd like to set up a specific path from source (you know where this is because the flow showed up as a packet_in from a non-tunnel port) to the destination. How do you know where the destination is (which switch and which port)? The most obvious answers are that you flood until you learn it, or you ARP for it (in many cases, these end up being pretty similar in terms of the traffic). A third option -- which I think you may be thinking of -- would be that you think you already know the destination switch because your actual destination address coincides with one of your tunnel endpoint addresses (e.g., you're trying to ping 192.168.3.4, so the destination is on the host with the eth0 with 192.168.3.4). This strikes me as fairly odd, because in this case I don't immediately see what you gain by having tunnels in the first place since the addresses on the inside are the same as the addresses on the outside. Once you know the destination, you want to pick a path. How do you know the topology? You could either statically configure it, or you could try to discover it. But either way, this path is in terms of *switches*. It's always in terms of switches. Maybe the switches have IP addresses, but that's sort of irrelevant -- IP addresses don't forward packets; switches do. If you want to think of it in terms of IP addresses, you just need to figure out which IP address corresponds to which switch, and then figure out which port leads to that switch. If this is all right, I still don't understand why you're doing it this way. If I'm wrong about something, please clue me in. :) (Incidentally, pieces to do most or all of the things I've mentioned exist. openflow.discovery figures out which ports connect switches. forwarding.l3_learning ARPs for unknown destinations and learns them. forwarding.l2_multi constructs end-to-end paths for fine-grained flows in networks of switches. You may just need to hack the right pieces together.) -- Murphy On Apr 11, 2013, at 2:58 AM, Kouvakas Alexandros wrote: > I will try to explain to you what I am trying to do with a different example. > Let's say that we have the topology below<Diagram1.png> > > Let's say that I choose to ping from host .2 to the host .5. > For some reason (possibly due to traffic or something else) I choose to > instruct the package to follow the path : > 192.16.3.2 --> 192.168.3.1 --> 192.168.3.6 --> 192.168.3.5 and not the > path 3.2 --> 3.1 --> 3.3 --> 3.4 --> 3.5. > > First of all I suppose that I have to find the MAC addresses which are > associated with the IPs of each host. Probably, this can be done with > l3_learning.py code. > > The big question is how can I add manually the exact path that the ping > package should follow according to my criteria. > In the future, I will have to check the traffic between the nodes and then > decide the path that should be followed. > > But for now, it's enough to begin with the determination of the path in the > code. > > Thanks for your help > Alexandros > > > 2013/4/11 Murphy McCauley <[email protected]> > It's not entirely clear to me what you're trying to accomplish here. Is it > that when you get a packet to any of the .2/.3./.4, you want to duplicate it > and send it to the other two also? If so, I think this is just three rules, > one which matches on each address. The actions for these are two rewrites > and two outputs. You know the IP address you want to rewrite to, but you'll > also need to figure out the MAC address which goes with the IP address, and > you'll need to figure out which port to send on. The former is the job of > ARP (though you could also potentially just learn it), and the latter is > basic learning behavior. You could implement these in the controller (the > l3_learning component does this), but it may also be possible to get some > help from the OFPP_NORMAL virtual output port. > > -- Murphy > > On Apr 10, 2013, at 8:53 AM, Kouvakas Alexandros wrote: > >> Hello again, >> I want to install some flows manually to the OF switch. I have an overlay >> network with a subnet 192.168.3.1/24. The central node with the OVS is the >> one with the IP 192.168.3.1 and there are 3 hosts connected directly to the >> central. It's more or less like the Openflow tutorial with mininet. >> >> What I want to do, is when the OF switch receives a packet, let's say from >> the node 192.168.3.2, to forward it to the nodes for example 192.168.3.4 and >> 192.168.3.3. I would like to use the IPs of the nodes and not the MAC >> addresses or ports. In this kind of topology there is not any real >> usefulness, but in the future I am planning to have a more complicated >> overlay network with many nodes connected to each other. In the latter case >> I will try to direct the packet through a path that I will choose. >> >> Is there any example of how I can do that? Do you think it is better to >> alter the code of l2_learning.py or start from the scratch? >> >> >> 2013/3/29 Murphy McCauley <[email protected]> >> On Mar 29, 2013, at 3:28 AM, Felician Nemeth wrote: >> >> >>> My node has python version 2.6.2. >> >> >> >> Note that you may run into some problems here -- POX's requirement is >> >> Python 2.7. >> > >> > I'd like to mention that it is sometimes not straightforward to install >> > a new python version. In which case, pythonbrew is really useful. >> > >> > https://github.com/utahta/pythonbrew >> >> This is a good tip, so I added it to the manual. Thanks. >> >> Between pythonbrew, PyPy, and the recent patches, I think the world for >> 2.6-ers is decent. The manual could probably be refactored a bit to put all >> the Python-version stuff in one place, but that's a project for another time >> or person. :) >> >> It sure would have been nice if 2.6 had been phased out before Python 3 >> really started getting deployed, but it's looking like that's not going to >> happen. Oh well. :) >> >> -- Murphy >> >> >> >> -- >> Kouvakas Alexandros > > > > > -- > Kouvakas Alexandros
