Ali, I will try to follow another approach similar to what you suggested.
Your advice helped me a lot thank you very much.
I have another simple question: I am configuring FV as
fvctl -f fvpasswd_file add-flowspace myflowspace1 all 1 any myslice1=7
fvctl -f fvpasswd_file add-flowspace myflowspace2 all 10 nw_dst=
10.0.0.255/32 myslice2=7
As far as I understand, this means the packets not matching; nw_dst=
10.0.0.255/32, should not be forwarded to myslice2 but to myslice1.
However, again all of the packets are issued to myslice2 because of its
respectively high priority, I guess.
Actually this behavior expected because after FV is getting configured
such, then I "list-flowspace" and it gives:
Configured Flow entries:
{"force-enqueue": -1, "name": "myflowspace1", "slice-action":
[{"slice-name": "myslice1", "permission": 6}], "queues": [], "priority": 1,
"dpid": "all_dpids", "id": 296, "match":* {"wildcards": 4194303}*}
{"force-enqueue": -1, "name": "myflowspace2", "slice-action":
[{"slice-name": "myslice2", "permission": 6}], "queues": [], "priority":
10, "dpid": "all_dpids", "id": 297, "match"*: {"wildcards": 4194303}*}
As this log shows, there is no difference at the "matching" fields. So I
think, either i am doing sth wrong with nw_dst=10.0.0.255/32 or it is not
working right.
(Because when add another match e.g. in_port=3, it is showing this in
myflowspace2 match field differently from that of myflowspace1)
Any help would be highly appreciated. Thanks for the time.
Mehmet Fatih Aktas
On Wed, Apr 3, 2013 at 4:18 PM, Ali Al-Shabibi
<ali.al-shab...@stanford.edu>wrote:
> [Responses inline]
>
> > After I created the slices as I wrote in the previous email; first I am
> running controller:8002, then 3 sws are not getting connected but only the
> sw whose dpid is added with the last flowspace entry. e.g. if the FV is
> configured such that
> > fvctl -f fvpasswd_file add-slice myslice1 tcp:192.168.56.1:8001 mfa
> > fvctl -f fvpasswd_file add-slice myslice2 tcp:192.168.56.1:8002 mfa
> >
> > fvctl -f fvpasswd_file add-flowspace myflowspace1 all 1 any myslice1=7
> > fvctl -f fvpasswd_file add-flowspace myflowspace2 00:00:00:00:00:02 3
> any myslice2=7
> > fvctl -f fvpasswd_file add-flowspace myflowspace2 00:00:00:00:00:03 3
> any myslice2=7
> > fvctl -f fvpasswd_file add-flowspace myflowspace2 00:00:00:00:00:01 3
> any myslice2=7
> > Then only sw_dpid:::01 is connected to myslice2. I listed FV datapaths
> and it is showing;
> > Connected switches:
> > 1 : 00:00:00:00:00:00:00:01
> > 2 : 00:00:00:00:00:00:00:02
> > 3 : 00:00:00:00:00:00:00:03
> > 4 : 00:00:00:00:00:00:00:04
> > So there is no connectivity problem. Also as you suggested, I traced the
> OF packet exchanges between the sws and the controllers, but for this case,
> the connection messages (Hello, Features Request, Set Config etc.) are
> exchanged for only connected sw_dpid:::01.
> >
>
> Are you sure flowvisor is connecting dpid 0x01 to myslice2? From your
> description I understand that initially only controller :8001 is running.
> Therefore, FlowVisor will create a connection for dpid 0x01 to myslice1
> only. So it is normal that you only see traffic for dpid 0x01. Does this
> make sense to you?
>
> >
> > >Slicing on the dpid only will be tricky because having two entire
> datapaths in two different slices is nearly impossible, you need some other
> >variable to discriminate on. I don't know what kind of virtual subnets you
> want to build, but have you considered slicing on IPs or even >vlans?
> Another alternative which is quite simple is to slice on a combination of
> dpids and ports.
> > This is a good suggestion, thanks, but what I want to have is sligthly
> more dynamic way of slicing the network by using FlowVisor. That is why I
> was trying to go for fine-grained manner of slicing: by specifying dpids
> individually for each slice. Also I am not trying to slice the datapath
> entirely here.
> > Do you have any idea that might be useful to achieve this type of
> slicing else I will try to follow what you suggested, vlan or IP slicing.
> > Thanks.
> >
>
> Dpid slicing isn't very fine grained because once you allocate a dpid to a
> slice (ie. which no other discriminant), the flowspace (and therefore the
> slice it is in) with the highest priority will always have control of that
> dpid. From what I can tell, VLAN or IP (or MAC) slicing is your best bet
> here.
>
> > Mehmet Fatih Aktas
> >
> >
> >
> > On Wed, Apr 3, 2013 at 2:26 PM, Ali Al-Shabibi <
> ali.al-shab...@stanford.edu> wrote:
> > Hi Mehmet,
> >
> > For your instability issue could you check that the connection between
> the switches and flowvisor is stable. That'll give us a better idea of
> where to start looking. You can verify this by running fvctl list-datapaths
> and confirming that all 4 switches remain connected. If they are always
> connected then you should probably capture a packet trace between flowvisor
> and the controllers to see what is actually going on. This can be done with
> wireshark.
> >
> >
> > >
> > > Also, even though the flowspaces of myslice1&2 are successfully
> created and all switches are getting connected successfully, FV does not
> send the packet_ins to both slice switches but only to one e.g.
> controller:8001.
> > >
> >
> > So flowvisor does not do this. It will only forward control traffic to
> one slice. In your case myslice1 takes precedence because it has a higher
> priority and matches all dpids.
> >
> > > Overall, what i am trying to do is to slice the network into virtual
> subnets, and here i explained the problems I had during doing that. What I
> am doing may not be the best way, I would appreciate any help or comment.
> >
> > Slicing on the dpid only will be tricky because having two entire
> datapaths in two different slices is nearly impossible, you need some other
> variable to discriminate on. I don't know what kind of virtual subnets you
> want to build, but have you considered slicing on IPs or even vlans?
> Another alternative which is quite simple is to slice on a combination of
> dpids and ports.
> >
> > Let me know if this helps.
> >
> > > Thanks for the time.
> > >
> > > Mehmet Fatih Aktas
> > >
> > >
> > > On Tue, Feb 26, 2013 at 3:08 PM, Ali Al-Shabibi <
> ali.al-shab...@stanford.edu> wrote:
> > > Hi Mehmet,
> > >
> > > FlowVisor can reside anywhere really (within a reasonable latency), so
> you could have it running in the mininet VM or on another machine. Just
> point your mininet network to the FlowVisor.
> > >
> > > This can be done by giving the --controller remote option to mininet.
> That said, I'd be interested to know what problems you had installing
> FlowVisor.
> > >
> > > >
> > > > Is there any simple tutorial or any resource that can help me to get
> on board quickly ?
> > >
> > > Unfortunately not yet, but I will be putting the tutorials up online
> officially soon, although they may not be very different to the ones you
> have found yet.
> > >
> > > Hope this helps!
> > >
> > > > Thanks.
> > > >
> > > > Mehmet Fatih Aktas
> > > > _______________________________________________
> > > > openflow-discuss mailing list
> > > > openflow-discuss@lists.stanford.edu
> > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
