On 1 Apr 2021, at 11:32, Eelco Chaudron wrote:
On 1 Apr 2021, at 11:28, Martin Varghese wrote:On Thu, Apr 01, 2021 at 11:17:14AM +0200, Eelco Chaudron wrote:On 1 Apr 2021, at 11:09, Martin Varghese wrote:On Thu, Apr 01, 2021 at 10:54:42AM +0200, Eelco Chaudron wrote:On 1 Apr 2021, at 10:35, Martin Varghese wrote:On Thu, Apr 01, 2021 at 08:59:27AM +0200, Eelco Chaudron wrote:On 1 Apr 2021, at 6:10, Martin Varghese wrote:On Wed, Mar 31, 2021 at 03:59:40PM +0200, Eelco Chaudron wrote:On 26 Mar 2021, at 7:21, Martin Varghese wrote:From: Martin Varghese <[email protected]> The encap & decap actions are extended to support MPLS packet type. Encap & decap actions adds and removes MPLS header at start of the packet.Hi Martin,I’m trying to do some real-life testing, and I’m running intoissues. Thismight be me setting it up wrongly but just wanting to confirm…I’m sending an MPLS packet that contains an ARP packet into aphysical port. This is the packet: Frame 4: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) Encapsulation type: Ethernet (1) [Protocols in frame: eth:ethertype:mpls:data] Ethernet II, Src: 00:00:00_00:00:01 (00:00:00:00:00:01), Dst: 00:00:00_00:00:02 (00:00:00:00:00:02) Destination: 00:00:00_00:00:02 (00:00:00:00:00:02) Address: 00:00:00_00:00:02 (00:00:00:00:00:02).... ..0. .... .... .... .... = LG bit: Globally uniqueaddress (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: 00:00:00_00:00:01 (00:00:00:00:00:01) Address: 00:00:00_00:00:01 (00:00:00:00:00:01).... ..0. .... .... .... .... = LG bit: Globally uniqueaddress (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: MPLS label switched packet (0x8847) MultiProtocol Label Switching Header, Label: 100, Exp: 0, S: 1, TTL: 64 0000 0000 0000 0110 0100 .... .... .... = MPLS Label: 100.... .... .... .... .... 000. .... .... = MPLS ExperimentalBits: 0 .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1 .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64 Data (46 bytes) 0000 ff ff ff ff ff ff 52 54 00 88 51 38 08 06 00 01 ......RT..Q8.... 0010 08 00 06 04 00 01 52 54 00 88 51 38 01 01 01 65 ......RT..Q8...e 0020 00 00 00 00 00 00 01 01 01 64 27 98 a0 47 .........d'..G Data: ffffffffffff525400885138080600010800060400015254008851380101016500000000? I’m trying to use the following rules: ovs-ofctl del-flows ovs_pvp_br0 ovs-ofctl add-flow -O OpenFlow13 ovs_pvp_br0 "priority=100,dl_type=0x8847,mpls_label=100 actions=decap(),decap(packet_type(ns=0,type=0x806)),resubmit(,3)" ovs-ofctl add-flow -O OpenFlow13 ovs_pvp_br0 "table=3,priority=10 actions=normal" With these, I expect the packet to be sent to vnet0, but it’s not. Actually, the datapath rule looks odd, while the userspace rules seem to match: $ ovs-dpctl dump-flows recirc_id(0),in_port(1),eth(),eth_type(0x8847),mpls(label=100/0xfffff,tc=0/0,ttl=0/0x0,bos=1/1), packets:13, bytes:1118, used:0.322s, actions:pop_eth,pop_mpls(eth_type=0x806),recirc(0x19a) recirc_id(0x19a),in_port(1),eth_type(0x0806), packets:13, bytes:884, used:0.322s, actions:drop $ ovs-ofctl dump-flows ovs_pvp_br0 -O OpenFlow13 cookie=0x0, duration=85.007s, table=0, n_packets=51, n_bytes=4386, priority=100,mpls,mpls_label=100 actions=decap(),decap(packet_type(ns=0,type=0x806)),resubmit(,3) cookie=0x0, duration=84.990s, table=3, n_packets=51, n_bytes=3468, priority=10 actions=NORMALThe inner packet is ethernet. So the packet type should be (ns=0,type=0) ?Forgot to add that I already tried that to start with, based on theexample, but as that did not work I tried 0x806. PS: I have this as a remark in my review notes, i.e., to explain the ns and type usage here. This resulted in packets being counted at the open flow level, but it results in NO data path rules. Do get an error though: 2021-04-01T06:53:36.056Z|00141|dpif(handler37)|WARN|system@ovs-system: failed to put[create] (Invalid argument)ufid:3d2d6f6d-5a66-4ace-8b09-7cdcfa5efc8e recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(1),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:01/00:00:00:00:00:00,dst=00:00:00:00:00:02/00:00:00:00:00:00),eth_type(0x8847),mpls(label=100/0xfffff,tc=0/0,ttl=64/0x0,bos=1/1),actions:pop_eth,pop_mpls(eth_type=0x6558),set(eth()),recirc(0x4c)This set(eth) before the recirc is the problem i guesss. I need to check2021-04-01T06:53:36.056Z|00142|dpif(handler37)|WARN|system@ovs-system:execute pop_eth,pop_mpls(eth_type=0x6558),set(eth()),recirc(0x4c)failed(Invalid argument) on packet mpls,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,mpls_label=100,mpls_tc=0,mpls_ttl=64,mpls_bos=1with metadata skb_priority(0),skb_mark(0),in_port(1) mtu 0 Are there missing parts in my kernel that do not get properly detected by the feature detection? $ ovs-appctl dpif/show-dp-features ovs_pvp_br0 Masked set action: Yes Tunnel push pop: No Ufid: Yes Truncate action: Yes Clone action: Yes Sample nesting: 10 Conntrack eventmask: Yes Conntrack clear: Yes Max dp_hash algorithm: 0 Check pkt length action: Yes Conntrack timeout policy: Yes Explicit Drop action: No Optimized Balance TCP mode: No l2 MPLS tunnelling: Yes Max VLAN headers: 2 Max MPLS depth: 3 Recirc: Yes CT state: Yes CT zone: Yes CT mark: Yes CT label: Yes CT state NAT: Yes CT orig tuple: Yes CT orig tuple for IPv6: Yes IPv6 ND Extension: NoYou are good I am not sure what is going wrong. Your test case looks same as the unit test i added. I tried myself again and this is i get ovs-ofctl -O OpenFlow13 add-flow br_mpls2 "in_port=$egress_port,dl_type=0x8847 +actions=decap(),decap(packet_type(ns=0,type=0),goto_table:1" ovs-ofctl -O OpenFlow13 add-flow br_mpls2 +"table=1,in_port=$egress_port,dl_type=0x0800,nw_dst=1.1.1.2 +actions=set_field:00:00:00:00:00:02->dl_dst,set_field:00:00:00:00:00:01->dl_sr +c output:$ingress_port" recirc_id(0x3),in_port(6),eth(src=36:b1:ee:7c:01:03,dst=36:b1:ee:7c:01:02),eth_ +type(0x0800),ipv4(dst=1.1.1.2,frag=no), packets:3, bytes:294, used:0.837s, +actions:set(eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:02)),4 recirc_id(0),in_port(6),eth(),eth_type(0x8847),mpls(label=0/0x0,tc=0/0,ttl=0/0x +0,bos=1/1), packets:3, bytes:348, used:0.837s, +actions:pop_eth,pop_mpls(eth_type=0x6558),recirc(0x3) The packet to the ovs is ETH|MPLS|ETH|IP ? How it is differnt from you test case?Mine is ETH|MPLS|ETH|ARP, which works fine with pop_mplsI am wondering how old mpls pop action workscould you please put down the userspace and datapath rules when you usedpop_mpls.In my understanding it can never work as what you have after MPLS isethernet and not ARP.It’s ethernet + ARP, but here are my rules:To clarify The test vector for Decap Test case ETH|MPLS|ETH|ARP The test vector for pop mpls test case ETH|MPLS|ARP| The above understanding correct?Guess our emails crossed ;) I was sending in the same packet for both the test cases, soETH|MPLS|ETH|ARP Which with decap() is resulting in the rules not being programmedWith popmpls I saw the packets in being received, but did not notice the incorrect use of popmpls so my packet after popmpls looks like ETH|ETH|ARP.So I guess all that remains is why the data path rules is not accepted for ARP with the decap.
Martin any update on the above?
dpctl: recirc_id(0),in_port(2),eth(),eth_type(0x8847),mpls(label=100/0xfffff,tc=0/0,ttl=0/0x0,bos=1/1), packets:64, bytes:5504, used:0.444s, actions:pop_mpls(eth_type=0x806),recirc(0x80d) recirc_id(0x80d),in_port(2),eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:02),eth_type(0x0806), packets:64, bytes:5248, used:0.444s, actions:3,1 ofctl: OFPST_FLOW reply (OF1.5) (xid=0x2):cookie=0x0, duration=178.890s, table=0, n_packets=127, n_bytes=10922,idle_age=0, priority=100,mpls,mpls_label=100 actions=pop_mpls:0x0806,resubmit(,3)cookie=0x0, duration=178.873s, table=3, n_packets=127, n_bytes=10414,idle_age=0, priority=10 actions=NORMALThanks for your time.Your welcomeIf I use the old way, doing pop_mpls, it works fine: ovs-ofctl del-flows ovs_pvp_br0 ovs-ofctl add-flow -O OpenFlow13 ovs_pvp_br0 "priority=100,dl_type=0x8847,mpls_label=100 actions=pop_mpls:0x0806,resubmit(,3)"ovs-ofctl add-flow -O OpenFlow13 ovs_pvp_br0 "table=3,priority=10actions=normal" I also noticed (despite the test example) to make encap work, I had to set the ethernet MAC addresses, or else the packets were not getting out. So something like:ovs-ofctl add-flow -O OpenFlow13 ovs_pvp_br0 "priority=100,in_port=vnet0,actions=encap(mpls(ether_type=0x8847)),set_mpls_label:100,encap(ethernet),,set_field:00:00:00:00:00:02->dl_dst,set_field:00:00:00:00:00:01->dl_src,output:enp5s0f0The packets are not going out because you are sending the packeton a real nic and not on a virtual inerface (veth pair) ?So for a real NIC we need to set the MAC addresses, maybe some where in thedocumentation we should add an example on how to use this feature?Maybe the test case can be made more realistic? Once I understand the failure, I can continue with the review. Cheers, Eelco
_______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
