DHCP fails for VMs in a VN in L3-mode

[Vedamurthy Joshi]

R2.20 Build 81 Ubuntu 14.04

A VN is set to be in pure L3 mode.

A Vm booted in such a VN is not getting its DHCP IP

Divakar has a fix for the same

vif0/3 OS: tap104fd905-15
            Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:0
            Vrf:1 Flags:PL3D MTU:9160 Ref:4
            RX packets:221 bytes:71742 errors:0
            TX packets:18 bytes:1060 errors:0

root@nodek2:~# rt --dump 1 --family inet |grep 22.1.1.3
22.1.1.3/32 32 PT - 32 -

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/13247
Committed: http://github.org/Juniper/contrail-vrouter/commit/6743e3c38202fef349bd7689e697105dd62bf84a
Submitter: Zuul
Branch: R2.20

commit 6743e3c38202fef349bd7689e697105dd62bf84a
Author: Divakar <email address hidden>
Date: Mon Aug 24 16:18:21 2015 +0530

Using the DHCP flag from VMI/VIF

After IRB code is introduced, the DHCP flag from VIF is no more used to
decide whether packet needs to be trapped or flooded. These flags are
encoded in L2 Bridge table entries to support BMS Dhcp support as in
case of BMS, no VIF is present in TSN's Vrouter kernel correspdonding to
BMS. But introduction of l3-only mode has introduced the requirement
back to look for this flag in VIF as there would not be any L3 bridge
entries in L3-Only mode. The fix is to check for the Dhcp enable flag in
VMI then followed by L2 bridge entry.

Alon with the above change, the code is reorganised to use the fmd's
mcast source value. In absence of fmd_src in FMD, when packet is moving
from L2 multicast nexthop to Fabric nexthop, to identify the whether
packet is received from Tor or another Vrouter, validate_src is invoked
again to identify the source of the packet, leading to redundant checks.
As part of IRB code fmd_src is introduced to identify which which source
the packet has been received and this is reused to identify the source.

Change-Id: Ic9495711d7479801a6edce001ddaebe94bcba6da
closes-bug: #1486490

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/13485
Committed: http://github.org/Juniper/contrail-vrouter/commit/0511fc2e76ff7ffc342907efe4f665a7119c3111
Submitter: Zuul
Branch: R2.20

commit 0511fc2e76ff7ffc342907efe4f665a7119c3111
Author: Divakar <email address hidden>
Date: Tue Sep 1 22:34:53 2015 +0530

Taking the correct ethernet header

As part of fix for bug 1486490, the l2 multicast control packets are
handled in a different function to process DHCP packets. To do the
bridge lookup, the source mac address needs to be taken from ethernet
haeder. But as the packet is already pulled, source mac is taken wrongly
and bridge lookup is going wrong. As a fix, the offset of ethernet
header is corrected now.

Also, as fabric composite nextghop does not have any more multicast
validate source function, this is also removed.

Change-Id: I353ccbb81629210ae1d328c9a3bf5c6ca965a8c2
closes-bug: #1491051

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/13620
Committed: http://github.org/Juniper/contrail-vrouter/commit/8d327e0f35a78c3b51321822a70e8baf8ab7be58
Submitter: Zuul
Branch: master

commit 8d327e0f35a78c3b51321822a70e8baf8ab7be58
Author: Divakar <email address hidden>
Date: Mon Aug 24 16:18:21 2015 +0530

Using the DHCP flag from VMI/VIF

After IRB code is introduced, the DHCP flag from VIF is no more used to
decide whether packet needs to be trapped or flooded. These flags are
encoded in L2 Bridge table entries to support BMS Dhcp support as in
case of BMS, no VIF is present in TSN's Vrouter kernel correspdonding to
BMS. But introduction of l3-only mode has introduced the requirement
back to look for this flag in VIF as there would not be any L3 bridge
entries in L3-Only mode. The fix is to check for the Dhcp enable flag in
VMI then followed by L2 bridge entry.

Alon with the above change, the code is reorganised to use the fmd's
mcast source value. In absence of fmd_src in FMD, when packet is moving
from L2 multicast nexthop to Fabric nexthop, to identify the whether
packet is received from Tor or another Vrouter, validate_src is invoked
again to identify the source of the packet, leading to redundant checks.
As part of IRB code fmd_src is introduced to identify which which source
the packet has been received and this is reused to identify the source.

closes-bug: #1486490
closes-bug: #1491051
closes-bug: #1492529

Change-Id: Id188ff821ccebbc12f42dbe4755a11c39e838317