[ovs-discuss] tracing flows with ct state

Michael Kashin mmkashin at gmail.com
Fri Dec 9 18:28:52 UTC 2016


Apologies.
What is the right syntax to specify table id in ofproto/trace?


On 9 December 2016 at 17:57, Joe Stringer <joe at ovn.org> wrote:

> Please don't drop the list.
>
> On 9 December 2016 at 08:12, Michael Kashin <mmkashin at gmail.com> wrote:
> > Thanks Joe,
> > Whenever I omit recirc_id and add only a ct_state I go back to my
> original
> > problem when trace just stops after the packet is submitted to ct.
> >
> > Rule: table=21 cookie=0 priority=100,ip,reg0=0x1/0x1,metadata=0x2
> > OpenFlow actions=ct(table=22,zone=NXM_NX_REG13[0..15])
> >
> > Final flow:
> > ct_state=new|trk,icmp,reg0=0x1,reg13=0x2,reg14=0x2,
> metadata=0x2,in_port=13,vlan_tci=0x0000,dl_src=fa:16:3e:4f:
> 2f:b8,dl_dst=fa:16:3e:0d:df:ea,nw_src=10.0.0.2,nw_dst=8.8.
> 8.8,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
> > Megaflow:
> > recirc_id=0,ip,in_port=13,vlan_tci=0x0000/0x1000,dl_src=
> fa:16:3e:4f:2f:b8,nw_src=10.0.0.2,nw_dst=8.0.0.0/7,nw_frag=no
> > Datapath actions: ct(zone=2),recirc(0xb6)
>
> Perhaps you need to specify table=22 along with the expected ct_zone
> and all of your registers/metadata when running the later flow
> through?
>
> >
> > Cheers,
> > Michael
> >
> >
> >
> > On 9 December 2016 at 05:03, Joe Stringer <joe at ovn.org> wrote:
> >>
> >> On 8 December 2016 at 13:43, Michael Kashin <mmkashin at gmail.com> wrote:
> >> > Hi,
> >> > I'm trying to use ofproto/trace to trace flows installed by OVN
> >> > controller.
> >> > I start with a simple flow spec that I used in OVS before, I get to
> >> > table 21
> >> > when packet gets submitted to connection tracker and that's where
> trace
> >> > stops:
> >> > Datapath actions: ct(zone=2),recirc(0x9f)
> >> >
> >> > I've tried adding recirc_id along with the ct_state to the same flow
> but
> >> > it
> >> > fails:
> >> >
> >> > # ovs-appctl ofproto/trace br-int
> >> >
> >> > in_port=13,ip,dl_src=fa:16:3e:4f:2f:b8,nw_src=10.0.0.2,nw_
> dst=8.8.8.8,dl_dst=fa:16:3e:0d:df:ea,recirc_id=0x9f,ct_state="new|trk"
> >> > Bridge: br-int
> >> > Flow:
> >> >
> >> > recirc_id=0x9f,ct_state=new|trk,ip,in_port=13,vlan_tci=
> 0x0000,dl_src=fa:16:3e:4f:2f:b8,dl_dst=fa:16:3e:0d:df:ea,
> nw_src=10.0.0.2,nw_dst=8.8.8.8,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> >> >
> >> > Final flow: unchanged
> >> > Megaflow: recirc_id=0x9f,ip,in_port=13,nw_frag=no
> >> > Datapath actions: drop
> >> > Translation failed (No recirculation context), packet is dropped.
> >> >
> >> >
> >> > Am I on the right track? Is this something achievable?
> >>
> >> I would suggest dropping the recirc_id; it is transient context that
> >> is kept around as long as a flow is flowing through OVS.
> >>
> >> You should be able to determine how your packets will flow through the
> >> tables by omitting recirc_id, and providing all of the flow fields
> >> that you know were available prior to the recirc() action. Depending
> >> on the flow table, often simply specifying the ct_state is enough.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161209/2031c8ac/attachment.html>


More information about the discuss mailing list