Hi,

I know this may not be a very interesting question, but I do not have
any idea why forwarding does not work.

Any help would really be appreciated.

Best regards
 Daniel

On 17.07.2015 10:43, Daniel Herrmann wrote:
>  Hi,
>
> I have installed OVS 2.3.2-1 on a Debian Wheezy(7.8) maschine. Two
> interfaces (eth1 and eth2) are connected to bridge 0:
>
> --- schnip ---
> root@SOF:~# ovs-ofctl -O OpenFlow13 show br0
> OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:aaaaaaaaaaaaaa19
> n_tables:254, n_buffers:256
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
> OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
>  4(eth1): addr:00:50:56:82:c5:47
>      config:     0
>      state:      0
>      current:    10GB-FD COPPER
>      advertised: COPPER
>      supported:  1GB-FD 10GB-FD COPPER
>      speed: 10000 Mbps now, 10000 Mbps max
>  5(eth2): addr:00:50:56:82:5f:a4
>      config:     0
>      state:      0
>      current:    10GB-FD COPPER
>      advertised: COPPER
>      supported:  1GB-FD 10GB-FD COPPER
>      speed: 10000 Mbps now, 10000 Mbps max
>  LOCAL(br0): addr:00:50:56:82:5f:a4
>      config:     PORT_DOWN
>      state:      LINK_DOWN
>      speed: 0 Mbps now, 0 Mbps max
> OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0
> --- snap ---
>
> I am using Ryu to program the switch and I am trying to implement basic
> Segment Routing support based on MPLS. For example, packages coming into
> eth1 should be encapsulated in an MPLS header using an appropriate
> label. Actually, I think the flow generation part works:
>
> --- snip ---
> root@SOF:~# ovs-ofctl -O OpenFlow13 dump-flows br0
> OFPST_FLOW reply (OF1.3) (xid=0x2):
>  cookie=0x0, duration=327.703s, table=0, n_packets=325, n_bytes=31850,
> ip,in_port=4,nw_dst=10.0.0.88/29
> actions=write_metadata:0x15/0xff,goto_table:10
>  cookie=0x0, duration=327.703s, table=0, n_packets=0, n_bytes=0,
> ip,in_port=4,nw_dst=20.0.0.0/8
> actions=write_metadata:0x14/0xff,goto_table:10
>  cookie=0x0, duration=327.703s, table=0, n_packets=0, n_bytes=0,
> ip,in_port=4,nw_dst=21.0.0.0/8
> actions=write_metadata:0x15/0xff,goto_table:10
>  cookie=0x0, duration=327.703s, table=10, n_packets=0, n_bytes=0,
> ip,metadata=0x14
> actions=set_field:00:50:56:82:b2:66->eth_dst,set_field:00:50:56:82:5f:a4->eth_src,push_mpls:0x8847,set_field:16020->mpls_label,output:5
>  cookie=0x0, duration=327.703s, table=10, n_packets=325, n_bytes=31850,
> ip,metadata=0x15
> actions=set_field:00:50:56:82:b2:66->eth_dst,set_field:00:50:56:82:5f:a4->eth_src,push_mpls:0x8847,set_field:16021->mpls_label,output:5
>  --- snap ---
>
> As you can see, I am using a two-table approach using metadata. The
> first table basically identifies the target, the second adds MPLS header
> and label. Now, If I am sending packages into Port 5, it is matching
> both rules in Table 0 and Table 10, so actually it should be forwarded.
> tcpdump on eth1 shows the packages coming in, however tcpdump on eth2
> does not see any packages going out. Tracing example packages however
> show, that the package actually should be processed correctly:
>
> --- snip ---
> root@SOF:~# ovs-appctl ofproto/trace br0
> in_port=4,dl_dst=00:50:56:82:c5:47,ip,ip_dst=21.0.0.1
> Bridge: br0
> Flow:
> ip,metadata=0,in_port=4,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:50:56:82:c5:47,nw_src=0.0.0.0,nw_dst=21.0.0.1,nw_tos=0,nw_ecn=0,nw_ttl=0
> Rule: table=0 cookie=0 ip,in_port=4,nw_dst=21.0.0.0/8
> OpenFlow actions=write_metadata:0x15/0xff,goto_table:10
>
>     Resubmitted flow:
> ip,metadata=0x15,in_port=4,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:50:56:82:c5:47,nw_src=0.0.0.0,nw_dst=21.0.0.1,nw_tos=0,nw_ecn=0,nw_ttl=0
>     Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0
> reg5=0x0 reg6=0x0 reg7=0x0
>     Resubmitted  odp: drop
>     Resubmitted megaflow:
> recirc_id=0,skb_priority=0,ip,metadata=0,in_port=4,dl_src=00:00:00:00:00:00,dl_dst=00:50:56:82:c5:47,nw_src=0.0.0.0,nw_dst=21.0.0.1,nw_proto=0,nw_frag=no
>     Rule: table=10 cookie=0 ip,metadata=0x15
>     OpenFlow
> actions=set_field:00:50:56:82:b2:66->eth_dst,set_field:00:50:56:82:5f:a4->eth_src,push_mpls:0x8847,set_field:16021->mpls_label,output:5
>
> Final flow:
> mpls,metadata=0x15,in_port=4,vlan_tci=0x0000,dl_src=00:50:56:82:5f:a4,dl_dst=00:50:56:82:b2:66,mpls_label=16021,mpls_tc=0,mpls_ttl=64,mpls_bos=1
> Megaflow:
> recirc_id=0,skb_priority=0,ip,metadata=0,in_port=4,dl_src=00:00:00:00:00:00,dl_dst=00:50:56:82:c5:47,nw_src=0.0.0.0,nw_dst=21.0.0.1,nw_proto=0,nw_tos=0,nw_ttl=0,mpls_label=0,mpls_tc=0,mpls_ttl=0,mpls_bos=0,mpls_lse1=0,mpls_lse2=0,nw_frag=no
> Datapath actions:
> set(eth(src=00:50:56:82:5f:a4,dst=00:50:56:82:b2:66)),push_mpls(label=16021,tc=0,ttl=64,bos=1,eth_type=0x8847),3
> --- snap ---
>
> The datapath ports look like this:
>
> --- snip ---
> root@SOF:~# ovs-dpctl show
> system@ovs-system:
>     lookups: hit:61368 missed:60694 lost:0
>     flows: 1
>     masks: hit:154718 total:2 hit/pkt:1.27
>     port 0: ovs-system (internal)
>     port 1: br0 (internal)
>     port 2: eth1
>     port 3: eth2
> --- snap ---
>
> So... what am I missing here? Why are the packets not forwarded? If
> required, I can also post the Ryu code used to generate the flow rules.
>
> Thanks in advance!
> Best regards
>   Daniel
> _______________________________________________
> discuss mailing list
> [email protected]
> http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to