Traffic from ToR-BMS to VM in a inter-vn setup gets dropped

Bug #1710547 reported by Vedamurthy Joshi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R4.0
New
High
Hari Prasad Killi
Trunk
New
High
Hari Prasad Killi

Bug Description

R3.2,4.x etc

Traffic from ToR-BMS to VM in a inter-VN case gets dropped due to SG.
Per current design, the subnet route for the BMS is coming from MX which does not have any SG associated with it.
So, flows started from the VM to the BMS is fine, but flows triggered from the BMS to the VM is not.

This is counter-intuitive to the end-user , because the BMS's MAC and IP is configured in Contrail and is expected to be known to it during flow creation

Tags: bms vrouter
Revision history for this message
Vinoth Kannan Ganapathy (vganapathy) wrote :

seeing the similar behavior with 4.0.1 build 51

root@5b8s40:~# ip netns exec p513p1ns1 ifconfig
tap1 Link encap:Ethernet HWaddr 00:00:00:00:00:10
          inet addr:123.23.4.5 Bcast:123.23.4.255 Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:10/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:8955741 errors:0 dropped:31 overruns:0 frame:0
          TX packets:3983010 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:539226537 (539.2 MB) TX bytes:167292634 (167.2 MB)

root@5b8s40:~# ip netns exec p513p1ns1 ping 123.23.5.18 -c 5
PING 123.23.5.18 (123.23.5.18) 56(84) bytes of data.

--- 123.23.5.18 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

root@5b8s40:~#

root@5b8s35:~# flow -l --match 123.23.5.18
Flow table(size 80609280, entries 629760)

Entries: Created 6019 Added 5990 Deleted 11628 Changed 11750 Processed 6018 Used Overflow entries 0
(Created Flows/CPU: 342 1864 472 429 405 412 308 303 310 368 32 46 26 36 21 12 22 28 78 48 36 56 43 27 46 59 27 34 76 41 2 0 0 0 1 2 0 4 2 1)(oflows 0)

Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)
 Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop
 Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked
TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead

Listing flows matching ([123.23.5.18]:*)

    Index Source:Port/Destination:Port Proto(V)
-----------------------------------------------------------------------------------
   128332<=>351552 123.23.5.18:26637 1 (2)
                         123.23.4.5:0
(Gen: 1, K(nh):36, Action:H, Flags:, QOS:-1, S(nh):36, Stats:0/0, SPort 54427,
 TTL 0, Sinfo 0.0.0.0)

   351552<=>128332 123.23.4.5:26637 1 (2)
                         123.23.5.18:0
(Gen: 1, K(nh):36, Action:D(SG), Flags:, QOS:-1, S(nh):41, Stats:5/490,
 SPort 57569, TTL 0, Sinfo 7.7.7.78)

root@5b8s35:~#

root@5b8s35:~# nh --get 41
Id:41 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:7 Vrf:0
              Flags:Valid, Vxlan, Etree Root,
              Oif:0 Len:14 Data:40 71 83 31 b2 40 90 e2 ba cd 91 78 08 00
              Sip:172.17.90.6 Dip:7.7.7.78

Revision history for this message
Hari Prasad Killi (haripk) wrote :

This is the behavior all along. Not targeting for 4.0.1 atleast.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.