<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Hi Mohan,<br><br><br> |--------------| |--------------|
|--------------| <br> | SRC-VM | | SF-VM | | DST-VM |<br> |--------------| |--------------| |--------------|<br> 192.168.0.9 P1 | 192.168.0.4 P2 | | p3 192.168.0.12 p4 | 192.168.0.8<br> fa:16:3e:48:88:96 | fa:16:3e:bb:be:c2 |
| fa:16:3e:9a:29:f1 | fa:16:3e:9f:25:c8<br>
| |
| |<br>Net1-----------------------------------------------------------------------------------------------------------------<br><br>Actually I am getting the packet on the egress port tap interface, but the packet is getting dropped there itself instead of getting forwarded to the destination VM port<br>The reason I found is the Src MAC and Dst MAC are in the reverse order in the ICMP packet, because of which packet is getting dropped <br><br>stack@cloud-VirtualBox:~/test$ sudo tcpdump -n -e -i tap157bda28-a4 -v icmp<br>tcpdump: WARNING: tap157bda28-a4: no IPv4 address assigned<br>tcpdump: listening on tap157bda28-a4, link-type EN10MB (Ethernet), capture size 65535 bytes<br> 192.168.0.9 > 192.168.0.8: ICMP echo request, id 17665, seq 0, length 64<br>19:27:56.812674 <b>fa:16:3e:9a:29:f1 > fa:16:3e:9f:25:c8,</b> ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 44153, offset 0, flags [DF], proto ICMP (1), length 84)<br> 192.168.0.9 > 192.168.0.8: ICMP echo request, id 17665, seq 1, length 64<br>19:27:57.814347 fa:16:3e:9a:29:f1 > fa:16:3e:9f:25:c8, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 44254, offset 0, flags [DF], proto ICMP (1), length 84)<br> 192.168.0.9 > 192.168.0.8: ICMP echo request, id 17665, seq 2, length 64<br><br>stack@cloud-VirtualBox:~/test$ sudo ovs-ofctl dump-flows br-int -O openflow13 | grep in_port=17<br>2016-09-10T14:01:22Z|00001|ofp_actions|INFO|OFPAT_SET_MPLS_TTL is deprecated in OpenFlow13 (use Set-Field)<br> cookie=0x936171a2fbba22bd, duration=407.031s, table=0, n_packets=0, n_bytes=0, priority=30,ip,in_port=17,nw_src=192.168.0.9,nw_dst=192.168.0.8 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2513.381s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=17,icmp_type=136 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2513.307s, table=0, n_packets=224, n_bytes=9408, priority=10,arp,in_port=17 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2513.401s, table=0, n_packets=716, n_bytes=141262, priority=9,in_port=17 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=2513.393s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=17,icmp_type=136,nd_target=fe80::f816:3eff:fe9a:29f1 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2513.347s, table=24, n_packets=5, n_bytes=210, priority=2,arp,in_port=17,arp_spa=192.168.0.12 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=2513.415s, table=25, n_packets=50, n_bytes=4684, priority=2,in_port=17,dl_src=fa:16:3e:9a:29:f1 actions=NORMAL <br> <br> In the last rule we are looking for in_port=17, and src MAC "fa:16:3e:9a:29:f1", but what the packet header contains Dst MAC in place of Src MAC<br> <br>I brought up "trusty-server-cloudimg-amd64-disk1.img" as ServiceFunction VM. As Ubuntu VM contains a single interface, I added other interface manually with following steps<br>=> Added /etc/network/interfaces.d/eth1.cfg<br>=> ifup eth1 <br><br>Then added default route for the dst VM IpAddress<br>=> ip route add 192.168.0.8/32 via 192.168.0.12 dev eth1<br><br>also enabled packet forwarding<br>=> echo 1 > /proc/sys/net/ipv4/ip_forward<br> <br>eth0 Link encap:Ethernet HWaddr fa:16:3e:bb:be:c2<br> inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0<br> inet6 addr: fe80::f816:3eff:febb:bec2/64 Scope:Link<br> UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1<br> RX packets:1241 errors:0 dropped:0 overruns:0 frame:0<br> TX packets:704 errors:0 dropped:0 overruns:0 carrier:0<br> collisions:0 txqueuelen:1000<br> RX bytes:155099 (155.0 KB) TX bytes:91291 (91.2 KB)<br><br>eth1 Link encap:Ethernet HWaddr fa:16:3e:9a:29:f1<br> inet addr:192.168.0.12 Bcast:192.168.0.255 Mask:255.255.255.0<br> inet6 addr: fe80::f816:3eff:fe9a:29f1/64 Scope:Link<br> UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1<br> RX packets:229 errors:0 dropped:0 overruns:0 frame:0<br> TX packets:68 errors:0 dropped:0 overruns:0 carrier:0<br> collisions:0 txqueuelen:1000<br> RX bytes:66984 (66.9 KB) TX bytes:6272 (6.2 KB)<br><br>root@sfvm:/home/ubuntu# route -n<br>Kernel IP routing table<br>Destination Gateway Genmask Flags Metric Ref Use Iface<br>0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0<br>169.254.169.254 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0<br>192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0<br>192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1<br>192.168.0.8 192.168.0.12 255.255.255.255 UGH 0 0 0 eth1<br>root@sfvm:/home/ubuntu#<br><br>Just to verify, have I manually sent ping request from egress port in the ServiceFunction VM ( ping -S 192.168.0.12 192.168.0.8) <br>stack@cloud-VirtualBox:~/test$ sudo tcpdump -n -e -i tap157bda28-a4 -v icmp<br>tcpdump: WARNING: tap157bda28-a4: no IPv4 address assigned<br>tcpdump: listening on tap157bda28-a4, link-type EN10MB (Ethernet), capture size 65535 bytes<br>19:35:33.683969 fa:16:3e:9a:29:f1 > fa:16:3e:9f:25:c8, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16699, offset 0, flags [DF], proto ICMP (1), length 84)<br> 192.168.0.12 > 192.168.0.8: ICMP echo request, id 1351, seq 1, length 64<br>19:35:33.684715 fa:16:3e:9f:25:c8 > fa:16:3e:9a:29:f1, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 30764, offset 0, flags [none], proto ICMP (1), length 84)<br> 192.168.0.8 > 192.168.0.12: ICMP echo reply, id 1351, seq 1, length 64<br><br>Here MAC addresses are getting updated properly and I am getting response.<br><br>I am not able to figure out the reason for reverse MAC addresses when I send ping request using the port-chain<br> <br> <br>Below is the openflow dump <br>stack@cloud-VirtualBox:~/test$ sudo ovs-ofctl dump-flows br-int -O openflow13<br>2016-09-10T13:58:48Z|00001|ofp_actions|INFO|OFPAT_SET_MPLS_TTL is deprecated in OpenFlow13 (use Set-Field)<br>OFPST_FLOW reply (OF1.3) (xid=0x2):<br> cookie=0x936171a2fbba22bd, duration=253.158s, table=0, n_packets=0, n_bytes=0, priority=30,ip,in_port=17,nw_src=192.168.0.9,nw_dst=192.168.0.8 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=253.155s, table=0, n_packets=18, n_bytes=1764, priority=30,ip,in_port=15,nw_src=192.168.0.9,nw_dst=192.168.0.8 actions=group:1<br> cookie=0x936171a2fbba22bd, duration=5521.152s, table=0, n_packets=0, n_bytes=0, priority=20,mpls actions=resubmit(,10)<br> cookie=0x936171a2fbba22bd, duration=2411.459s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=15,icmp_type=136 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2361.237s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=16,icmp_type=136 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2359.508s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=17,icmp_type=136 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=1506.783s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=18,icmp_type=136 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2411.443s, table=0, n_packets=10, n_bytes=420, priority=10,arp,in_port=15 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2361.219s, table=0, n_packets=40, n_bytes=1680, priority=10,arp,in_port=16 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=2359.434s, table=0, n_packets=224, n_bytes=9408, priority=10,arp,in_port=17 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=1506.767s, table=0, n_packets=9, n_bytes=378, priority=10,arp,in_port=18 actions=resubmit(,24)<br> cookie=0x936171a2fbba22bd, duration=5522.397s, table=0, n_packets=0, n_bytes=0, priority=2,in_port=1 actions=drop<br> cookie=0x936171a2fbba22bd, duration=2411.475s, table=0, n_packets=638, n_bytes=127072, priority=9,in_port=15 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=2361.254s, table=0, n_packets=1596, n_bytes=263939, priority=9,in_port=16 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=2359.528s, table=0, n_packets=662, n_bytes=130522, priority=9,in_port=17 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=1506.798s, table=0, n_packets=414, n_bytes=81165, priority=9,in_port=18 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=5484.887s, table=0, n_packets=2482, n_bytes=242710, priority=3,in_port=1,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4098->vlan_vid,NORMAL<br> cookie=0x936171a2fbba22bd, duration=5522.826s, table=0, n_packets=5918, n_bytes=769504, priority=0 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=253.202s, table=5, n_packets=18, n_bytes=1764, priority=0,ip,dl_dst=fa:16:3e:bb:be:c2 actions=push_mpls:0x8847,set_field:65791->mpls_label,set_mpls_ttl(255),push_vlan:0x8100,set_field:4100->vlan_vid,resubmit(,10)<br> cookie=0x936171a2fbba22bd, duration=253.126s, table=10, n_packets=18, n_bytes=1764, priority=1,mpls,dl_vlan=4,dl_dst=fa:16:3e:bb:be:c2,mpls_label=65791 actions=pop_vlan,pop_mpls:0x0800,output:16<br> cookie=0x936171a2fbba22bd, duration=5521.146s, table=10, n_packets=0, n_bytes=0, priority=0 actions=drop<br> cookie=0x936171a2fbba22bd, duration=5522.820s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop<br> cookie=0x936171a2fbba22bd, duration=2411.467s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=15,icmp_type=136,nd_target=fe80::f816:3eff:fe48:8896 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2361.245s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=16,icmp_type=136,nd_target=fe80::f816:3eff:febb:bec2 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2359.520s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=17,icmp_type=136,nd_target=fe80::f816:3eff:fe9a:29f1 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=1506.790s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=18,icmp_type=136,nd_target=fe80::f816:3eff:fe9f:25c8 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2411.451s, table=24, n_packets=10, n_bytes=420, priority=2,arp,in_port=15,arp_spa=192.168.0.9 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=2361.229s, table=24, n_packets=40, n_bytes=1680, priority=2,arp,in_port=16,arp_spa=192.168.0.4 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=2359.474s, table=24, n_packets=5, n_bytes=210, priority=2,arp,in_port=17,arp_spa=192.168.0.12 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=1506.775s, table=24, n_packets=9, n_bytes=378, priority=2,arp,in_port=18,arp_spa=192.168.0.8 actions=resubmit(,25)<br> cookie=0x936171a2fbba22bd, duration=5522.815s, table=24, n_packets=219, n_bytes=9198, priority=0 actions=drop<br> cookie=0x936171a2fbba22bd, duration=2411.489s, table=25, n_packets=33, n_bytes=2960, priority=2,in_port=15,dl_src=fa:16:3e:48:88:96 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2361.270s, table=25, n_packets=1014, n_bytes=138605, priority=2,in_port=16,dl_src=fa:16:3e:bb:be:c2 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=2359.543s, table=25, n_packets=50, n_bytes=4684, priority=2,in_port=17,dl_src=fa:16:3e:9a:29:f1 actions=NORMAL<br> cookie=0x936171a2fbba22bd, duration=1506.817s, table=25, n_packets=30, n_bytes=2716, priority=2,in_port=18,dl_src=fa:16:3e:9f:25:c8 actions=NORMAL<br>stack@cloud-VirtualBox:~/test$<br><br>Thanks in advance,<br>Ravi<br><br>----- Original Message -----<br>From: all<br>To: openstack-dev@lists.openstack.org<br>Sent: Tuesday, September 6, 2016 1:17:11 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi<br>Subject: Re: [openstack-dev] [networking-sfc] SFC flows issue<br><br><link href="/zimbra/css/msgview.css?v=1.0" rel="stylesheet"><div dir="ltr"><div>Hi Ravi ,</div><div><br></div><div>Could you share tcpdump on P3 as well ( <font color="#263238">sudo tcpdump -n -e -i "P3 tab-interface" ) </font></div><div><font color="#263238"><br></font></div><div><font color="#263238">IMO , the possible reasons would be </font></div><div><font color="#263238"><br></font></div><div><font color="#263238">[1] </font><span style="font-size:12.8px">port-security on SF port may block the packet , since it destined to different ip address.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">[2] The SF program may alter the IP Header (Destination field )</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Flow rules are looks okay , and it shows packets are dropped in between p2 and p3 .</span></div><div><br></div><div><br></div><div><font color="#263238">Thanks.,</font></div><div><font color="#263238">Mohankumar.N</font></div><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 3, 2016 at 10:07 AM, Ravi Sekhar Reddy Konda <span dir="ltr"><<a href="mailto:ravisekhar.konda@oracle.com" target="_blank">ravisekhar.konda@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:"times new roman";font-size:12pt;color:rgb(0,0,0)">Hi Networking SFC team<br><div><div style="font-family:"times new roman";font-size:12pt;color:rgb(0,0,0)"><div><div style="font-family:"times new roman";font-size:12pt;color:rgb(0,0,0)"><div dir="ltr"><br> I am trying out networking-SFC on the AllInOne Devstack(master branch) VM brought up on the VirtualBox.<br> I am trying out the following scenario<br> <br> |--------------| |--------------| |--------------| <br> | SRC-VM | | SF-VM | | DST-VM |<br> |--------------| |--------------| |--------------|<br> p1 | p2 | |p3 p4 |<br> | | | |<br> | | | |<br>Net1---------------------------------------------------------------------------------------------<br><br><br>P1 -> 192.168.0.6 "fa:16:3e:d8:8f:28"<br>P2 -> 192.168.0.10 "fa:16:3e:12:7e:50"<br>P3 -> 192.168.0.5 "fa:16:3e:1e:f8:c2"<br>P4 -> 192.168.0.14 "fa:16:3e:4d:e8:c3"<br><br><div>On SF-VM, I have written a simple application to capture the packets on eth0 and forward to eth1<br><br>The issue I am facing is packets are getting sent from Port-1 (SRC-VM) to Port-2 (SF-VM), but I am not seeing packets getting sent from Port-3 (SF-VM) to Port-4 (DST-VM)<br><br>Here is the Classifier I created<br><br>neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix <a href="http://192.168.0.6/32" target="_blank">192.168.0.6/32</a> --logical-source-port 6c700c35-6505-4304-89cd-b48513884cf5 --destination-ip-prefix <a href="http://192.168.0.14/32" target="_blank">192.168.0.14/32</a> --logical-destination-port d0b218c9-57f4-4d38-b363-2086b8dbc8b9 --protocol icmp fc1<br><br>==> Can you please let me know are the flows as expected in this scenario <br>OFPST_FLOW reply (OF1.3) (xid=0x2):<br> cookie=0x9118e6e52dd3dfa0, duration=34624.734s, table=0, n_packets=399, n_bytes=39102, priority=30,icmp,in_port=9,nw_src=192.168.0.6,nw_dst=192.168.0.14 actions=group:1<br> cookie=0x9118e6e52dd3dfa0, duration=34624.696s, table=0, n_packets=0, n_bytes=0, priority=30,icmp,in_port=13,nw_src=192.168.0.6,nw_dst=192.168.0.14 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=45300.986s, table=0, n_packets=0, n_bytes=0, priority=20,mpls actions=resubmit(,10)<br> cookie=0x9118e6e52dd3dfa0, duration=42858.783s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=9,icmp_type=136 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=42250.745s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=10,icmp_type=136 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=37845.792s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=12,icmp_type=136 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=37617.801s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port=13,icmp_type=136 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=42858.758s, table=0, n_packets=73, n_bytes=3066, priority=10,arp,in_port=9 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=42250.725s, table=0, n_packets=151, n_bytes=6342, priority=10,arp,in_port=10 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=37845.769s, table=0, n_packets=666039, n_bytes=27973638, priority=10,arp,in_port=12 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=37617.782s, table=0, n_packets=666069, n_bytes=27974898, priority=10,arp,in_port=13 actions=resubmit(,24)<br> cookie=0x9118e6e52dd3dfa0, duration=45302.016s, table=0, n_packets=0, n_bytes=0, priority=2,in_port=1 actions=drop<br> cookie=0x9118e6e52dd3dfa0, duration=42858.804s, table=0, n_packets=10993, n_bytes=2219925, priority=9,in_port=9 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=42250.774s, table=0, n_packets=22275, n_bytes=4028172, priority=9,in_port=10 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=37845.822s, table=0, n_packets=9967, n_bytes=1989597, priority=9,in_port=12 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=37617.828s, table=0, n_packets=11154, n_bytes=2154155, priority=9,in_port=13 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=45268.699s, table=0, n_packets=14048, n_bytes=1104503, priority=3,in_port=1,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4098->vlan_vid,NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=45302.314s, table=0, n_packets=24842, n_bytes=2954751, priority=0 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=34624.792s, table=5, n_packets=399, n_bytes=39102, priority=0,ip,dl_dst=fa:16:3e:12:7e:50 actions=push_mpls:0x8847,set_field:65791->mpls_label,set_mpls_ttl(255),push_vlan:0x8100,set_field:4099->vlan_vid,resubmit(,10)<br> cookie=0x9118e6e52dd3dfa0, duration=34624.649s, table=10, n_packets=399, n_bytes=39102, priority=1,mpls,dl_vlan=3,dl_dst=fa:16:3e:12:7e:50,mpls_label=65791 actions=pop_vlan,pop_mpls:0x0800,output:10<br> cookie=0x9118e6e52dd3dfa0, duration=45300.979s, table=10, n_packets=0, n_bytes=0, priority=0 actions=drop<br> cookie=0x9118e6e52dd3dfa0, duration=45302.309s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop<br> cookie=0x9118e6e52dd3dfa0, duration=42858.796s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=9,icmp_type=136,nd_target=fe80::f816:3eff:fed8:8f28 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=42250.752s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=10,icmp_type=136,nd_target=fe80::f816:3eff:fe12:7e50 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=37845.802s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=12,icmp_type=136,nd_target=fe80::f816:3eff:fe4d:e8c3 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=37617.815s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port=13,icmp_type=136,nd_target=fe80::f816:3eff:fe1e:f8c2 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=42858.773s, table=24, n_packets=73, n_bytes=3066, priority=2,arp,in_port=9,arp_spa=192.168.0.6 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=42250.735s, table=24, n_packets=139, n_bytes=5838, priority=2,arp,in_port=10,arp_spa=192.168.0.10 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=37845.783s, table=24, n_packets=666039, n_bytes=27973638, priority=2,arp,in_port=12,arp_spa=192.168.0.14 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=37617.791s, table=24, n_packets=666022, n_bytes=27972924, priority=2,arp,in_port=13,arp_spa=192.168.0.5 actions=resubmit(,25)<br> cookie=0x9118e6e52dd3dfa0, duration=45302.304s, table=24, n_packets=59, n_bytes=2478, priority=0 actions=drop<br> cookie=0x9118e6e52dd3dfa0, duration=42858.823s, table=25, n_packets=99, n_bytes=5900, priority=2,in_port=9,dl_src=fa:16:3e:d8:8f:28 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=42250.791s, table=25, n_packets=11603, n_bytes=1849532, priority=2,in_port=10,dl_src=fa:16:3e:12:7e:50 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=37845.841s, table=25, n_packets=666304, n_bytes=27999888, priority=2,in_port=12,dl_src=fa:16:3e:4d:e8:c3 actions=NORMAL<br> cookie=0x9118e6e52dd3dfa0, duration=37617.845s, table=25, n_packets=667436, n_bytes=28153632, priority=2,in_port=13,dl_src=fa:16:3e:1e:f8:c2 actions=NORMAL<br><br>When I manually send ICMP packets from eth1 interface(P3) on SF-VM, packets are going as expected<br><br>Thanks in Advance<span class="gmail-HOEnZb"><font color="#888888"><br>Ravi<br></font></span></div></div>
</div></div></div></div></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
</div></body></html>