Gateway_less_FWD: Broadcast ping with in a VN is not working, when VN is configured with IP Fabric provider network

[Chandra Sekhar Reddy Mallam]

Broadcast ping with in a VN is not working, when VN is configured with IP Fabric provider network.

Build Info
---------
4.1.0.0-27 Mitaka

Steps
-----
1. Create a VN and configure IP Fabric network as provider network.
2. Launch couple of VMs on this VN across compute nodes
3. Now, try broadcast ping from one of the VM and it fails.

Please see the log below:

root@ctest-vm2-08807933:/home/ubuntu# ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:48:ff:ed:ac:2c
          inet addr:217.96.11.4 Bcast:217.96.11.255 Mask:255.255.255.0
          inet6 addr: 2939:3bf9:80ae:6666::4/64 Scope:Global
          inet6 addr: fe80::48:ffff:feed:ac2c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:3987 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3699 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:285869 (285.8 KB) TX bytes:262866 (262.8 KB)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@ctest-vm2-08807933:/home/ubuntu#

root@ctest-vm2-08807933:/home/ubuntu# ping -b 217.96.11.255 . <======
WARNING: pinging broadcast address
PING 217.96.11.255 (217.96.11.255) 56(84) bytes of data.
^C
--- 217.96.11.255 ping statistics ---
44 packets transmitted, 0 received, 100% packet loss, time 43344ms

root@ctest-vm2-08807933:/home/ubuntu# ping 217.96.11.5
PING 217.96.11.5 (217.96.11.5) 56(84) bytes of data.
64 bytes from 217.96.11.5: icmp_seq=1 ttl=61 time=1.34 ms
64 bytes from 217.96.11.5: icmp_seq=2 ttl=61 time=0.608 ms
^C
--- 217.96.11.5 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.608/0.974/1.340/0.366 ms
root@ctest-vm2-08807933:/home/ubuntu#

root@nodek11:~# rt --dump 0 | grep 217.96.11.5
217.96.11.5/32 32 PT - 14 80:ac:ac:f0:a2:c1(238756)
217.96.11.50/32 0 T - 14 -
217.96.11.51/32 0 T - 14 -
217.96.11.52/32 0 T - 14 -
217.96.11.53/32 0 T - 14 -
217.96.11.54/32 0 T - 14 -
217.96.11.55/32 0 T - 14 -
217.96.11.56/32 0 T - 14 -
217.96.11.57/32 0 T - 14 -
217.96.11.58/32 0 T - 14 -
217.96.11.59/32 0 T - 14 -
root@nodek11:~# nh --get 14
Id:14 Type:Encap Fmly: AF_INET Rid:0 Ref_cnt:4086 Vrf:0
              Flags:Valid, Etree Root,
              EncapFmly:0806 Oif:0 Len:14
              Encap Data: 80 ac ac f0 a2 c1 0c c4 7a 32 0a 88 08 00

root@nodek11:~# rt --dump 0 | grep 217.96.11.255
217.96.11.255/32 0 T - 14 -
root@nodek11:~# nh --get 14
Id:14 Type:Encap Fmly: AF_INET Rid:0 Ref_cnt:4086 Vrf:0
              Flags:Valid, Etree Root,
              EncapFmly:0806 Oif:0 Len:14
              Encap Data: 80 ac ac f0 a2 c1 0c c4 7a 32 0a 88 08 00

root@nodek11:~#

root@nodek11:~# contrail-version;lsb_release -a;cat /proc/version; strings /usr/bin/contrail-vrouter-agent| grep version| grep build-user
Package Version Build-ID | Repo | Package Name
-------------------------------------- ------------------------------ ----------------------------------
contrail-lib 4.1.0.0-27 27
contrail-nodemgr 4.1.0.0-27 27
contrail-setup 4.1.0.0-27 27
contrail-utils 4.1.0.0-27 27
contrail-vrouter-agent 4.1.0.0-27 27
contrail-vrouter-common 4.1.0.0-27 27
contrail-vrouter-dkms 4.1.0.0-27 27
contrail-vrouter-init 4.1.0.0-27 27
contrail-vrouter-utils 4.1.0.0-27 27
nova-common 2:13.0.0-0ubuntu2~cloud0.1contrail1 27
nova-compute 2:13.0.0-0ubuntu2~cloud0.1contrail1 27
nova-compute-kvm 2:13.0.0-0ubuntu2~cloud0.1contrail1 27
nova-compute-libvirt 2:13.0.0-0ubuntu2~cloud0.1contrail1 27
python-contrail 4.1.0.0-27 27
python-contrail-vrouter-api 4.1.0.0-27 27
python-neutronclient 1:4.1.1-2~cloud0.2contrail 27
python-nova 2:13.0.0-0ubuntu2~cloud0.1contrail1 27
python-opencontrail-vrouter-netns 4.1.0.0-27 27
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
Linux version 4.4.0-31-generic (buildd@lgw01-43) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016
{"build-info": [{"build-time": "2017-10-30 06:56:14.660729", "build-hostname": "nodeb6", "build-user": "ashoksr", "build-version": "4.1.0.0"}]}
root@nodek11:~#
root@nodek11:~#

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37586
Submitter: Divakar Dharanalakota (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37619
Submitter: Naveen N (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37667
Submitter: Divakar Dharanalakota (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37668
Submitter: Divakar Dharanalakota (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37619
Submitter: Naveen N (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/37668
Committed: http://github.com/Juniper/contrail-vrouter/commit/2bcb4189d8fec9c4b72c218aaefd5f3bfef7c9ce
Submitter: Zuul (<email address hidden>)
Branch: R4.1

commit 2bcb4189d8fec9c4b72c218aaefd5f3bfef7c9ce
Author: Divakar D <email address hidden>
Date: Mon Nov 20 11:20:34 2017 +0530

Sandesh change for multicast VRF in interface req

This is sandesh change for using different multicast VRF in terface req for VN with provider network

Change-Id: I0c0310232b5e44eec780ad54d552e6750d42b9a6
partial-bug: #1728545

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/37667
Committed: http://github.com/Juniper/contrail-vrouter/commit/fe13bd143833491b47a4f08fbf8c78ab1b509245
Submitter: Zuul (<email address hidden>)
Branch: master

commit fe13bd143833491b47a4f08fbf8c78ab1b509245
Author: Divakar D <email address hidden>
Date: Mon Nov 20 11:20:34 2017 +0530

Sandesh change for multicast VRF in interface req

This is sandesh change for using different multicast VRF in terface req for VN with provider network

Change-Id: I0c0310232b5e44eec780ad54d552e6750d42b9a6
partial-bug: #1728545

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/37619
Committed: http://github.com/Juniper/contrail-controller/commit/25cc2ffc2bbcfc568f525fc5096e096edb198583
Submitter: Zuul (<email address hidden>)
Branch: R4.1

commit 25cc2ffc2bbcfc568f525fc5096e096edb198583
Author: Naveen N <email address hidden>
Date: Fri Nov 17 16:07:33 2017 +0530

* Use native VRF of VM for forwarding mcast packet

If VMI is configured with unerlay forwarding, then multicast
traffic would be forwarded via overlay broadcast route
in the native VN of the interface.

Change-Id: I090901354ffb96b62049033bfbd05f8ba6409d51
Closes-bug: #1728545
Depends-On: I0c0310232b5e44eec780ad54d552e6750d42b9a6

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37586
Submitter: Divakar Dharanalakota (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/37586
Committed: http://github.com/Juniper/contrail-vrouter/commit/4c904a55e08922de93808cc5a9bc41e7620ffbdc
Submitter: Zuul (<email address hidden>)
Branch: R4.1

commit 4c904a55e08922de93808cc5a9bc41e7620ffbdc
Author: Divakar D <email address hidden>
Date: Thu Nov 16 14:52:54 2017 +0530

User different VRF for multicast packets of VN with Provider network

Currently if a VN is configured with Provider network, the VRF of the
VMI's belonging to that VN are seen as Fabric VRF in Vrouter. But the
Multicast/Broadcast tree is built in the VRF corresponding to VN. When
BUM traffic is received on such VMI, traffic needs to be replicated as
per the mutlicast tree of VN's VRF rather on Fabric VRF. To achieve
this, the VN's VRF is added to VMI as different VRF and the bridge
lookup is done for this traffic in this new VRF.

Change-Id: I38721e27cebe80c7f4d14937588ba5b6c180b112
closes-bug: #1728545

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37862
Submitter: Hari Prasad Killi (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/37863
Submitter: Hari Prasad Killi (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/37862
Committed: http://github.com/Juniper/contrail-controller/commit/130f28bbbe2780c1c34c8e4ac60ee79877fa343a
Submitter: Zuul (<email address hidden>)
Branch: master

commit 130f28bbbe2780c1c34c8e4ac60ee79877fa343a
Author: Naveen N <email address hidden>
Date: Fri Nov 17 16:07:33 2017 +0530

* Use native VRF of VM for forwarding mcast packet

If VMI is configured with unerlay forwarding, then multicast
traffic would be forwarded via overlay broadcast route
in the native VN of the interface.

Change-Id: I090901354ffb96b62049033bfbd05f8ba6409d51
Closes-bug: #1728545
Depends-On: I0c0310232b5e44eec780ad54d552e6750d42b9a6
(cherry picked from commit 25cc2ffc2bbcfc568f525fc5096e096edb198583)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/37863
Committed: http://github.com/Juniper/contrail-vrouter/commit/71499ce7be6edec00cc7135d308f1e9f5b425cb2
Submitter: Zuul (<email address hidden>)
Branch: master

commit 71499ce7be6edec00cc7135d308f1e9f5b425cb2
Author: Divakar D <email address hidden>
Date: Thu Nov 16 14:52:54 2017 +0530

User different VRF for multicast packets of VN with Provider network

Currently if a VN is configured with Provider network, the VRF of the
VMI's belonging to that VN are seen as Fabric VRF in Vrouter. But the
Multicast/Broadcast tree is built in the VRF corresponding to VN. When
BUM traffic is received on such VMI, traffic needs to be replicated as
per the mutlicast tree of VN's VRF rather on Fabric VRF. To achieve
this, the VN's VRF is added to VMI as different VRF and the bridge
lookup is done for this traffic in this new VRF.

Change-Id: I38721e27cebe80c7f4d14937588ba5b6c180b112
closes-bug: #1728545
(cherry picked from commit 4c904a55e08922de93808cc5a9bc41e7620ffbdc)