On Nov 15, 2014, at 4:47 PM, Padma Jayasankar <padmaj...@gmail.com> wrote:
> Hi, > Could u please clarify whether removing some flow entries using flow_mod in > a switch, will result in packet loss when we are not deleting the flow > entries that are used currently to send the traffic? I wouldn't think so, but it may depend on the switch. > Further if we have some low priority entries(wildcard) and some high > priority entries for the same match conditions are added(exact match), then > will we have both the entries. According to my understanding, ow the packets > that match the exact match entry will follow the high priority entries and as > a result low priority entries will get deleted after some time.Is my > understanding correct? If no packets are hitting the low priority rule and the rule has an idle timeout, then yes -- the low priority one should eventually idle out. As far as my understanding of the spec goes. > > Thanks and Regards, > Padma V > > On Sat, Nov 15, 2014 at 6:07 PM, Murphy McCauley <murphy.mccau...@gmail.com> > wrote: > On Nov 15, 2014, at 4:29 AM, Padma Jayasankar <padmaj...@gmail.com> wrote: > >> Hi, >> Thanks for the immediate response. >> Regarding >> 1) Yes .am using l2_multi with openflow_discovery packets.. So is this to >> forwrd LLDP packets of other switches to the controller? > > Yes. This is how discovery works. > >> 2) Is this the correct way of deleting? Actually now i have the entries >> with other ports in the flow table. So it is deleting the entries with the >> specified conditions i guess. But i am getting packet loss which are using >> these existing entries(the entries which are present in the table) >> To be clear,i have to entries with different priorities for the same >> destination in the switch. I give ping request thru xterm and >> give "link s3 s7 down". I have modified OVSK, so when a link fails it >> deletes the flow entries which has outport as the specified one. But inport >> match case fails..that entry is still present in the table. >> 3) when v senf ofp_flow_mod with OFP_DELETE for some entry and at that >> time the packets r flowing thru that switch(thru another link), then will >> that flow get affected? Actually some packets are getting dropped while this >> flow_mod message is sent. any reason? > > I can't attempt to reason about what a modified version of OVS might do. > Sorry. > >> >> On Sat, Nov 15, 2014 at 8:53 AM, Murphy McCauley <murphy.mccau...@gmail.com> >> wrote: >> On Nov 14, 2014, at 7:12 PM, Padma Jayasankar <padmaj...@gmail.com> wrote: >> >>> HI, >>> 1. I am getting the following entry in all switches. What does this entry >>> denote? >>> cookie=0x0, duration=100.653s, table=0, n_packets=34, n_bytes=1394, >>> idle_age=1, priority=65000,dl_dst=01:23:20:00:00:01,dl_type=0x88cc >>> actions=CONTROLLER:65535 >> >> I'm guessing this is the output from ovs-ofctl or dpctl or something. It's >> probably worth learning to use the tool; it probably has a man page. It >> should also be pretty clear if you take a look at the OpenFlow spec. >> >> The high points of this entry are that packets with the destination MAC >> 01:23:20:00:00:01 and Ethertype 0x88cc are sent to the controller. 0x88cc >> is LLDP. And if you look up the OUI of the MAC address, you'll see that >> it's Nicira Networks. This is the multicast MAC address used for >> Nicira-style discovery. You're probably running the POX discovery >> component, which installs table entries like this. >> >>> 2. I am using POX with Mininet and OVSK. I am using l2_multi routine.This >>> deletes all the flow entries when a link failure(link down) event is >>> raised. I want to change this , so that it deletes entries pertaining the >>> failed link alone.How to achieve this? I tried with the following code >>> ie) How to delete entries of a switch that has outport or inport as the >>> specified port number >>> >>> clear = of.ofp_flow_mod(command=of. >>> OFPFC_DELETE,out_port=port1) >>> sw1.connection.send(clear) >>> >>> clear = >>> of.ofp_flow_mod(command=of.OFPFC_DELETE,match=of.ofp_match(in_port=port2)) >>> sw2.connection.send(clear) >>> >>> But it is not behaving as expected >> >> What's it doing instead? >> >>> Please clarify. >>> >>> Thanks and Regards, >>> Padma V >> >> > >