[2.1-Build 36] Unknown unicast frame is dropped at vRouter on TSN

[Daisuke Nakajima]

When ARP table is remained at BMS whereas MAC address table is expired on ToR, TSN drops Unknown unicast frame. As a result, BMS traffic does not reaches to BMS which is allocated on other TOR.
Why this issue happens is, ARP table on BMS and MAC address table on ToR of timer is not consolidated.
So, vRouter on TSN should flood unknown unicast frame to prevent above issue.

[Nagabhushana R (bhushana)]

chhandak is investigating this with the Agent team.

[Nischal Sheth (nsheth)]

@Daisuke

We discussed this issue during design phase. Rather than enabling
unknown unicast flooding, we reccommend setting the MAC aging
time to be higher than ARP timeout.

[Daisuke Nakajima (dnakajima)]

@Nischal

If the traffic comes from one way, like a keepalive, the MAC aging time of the destination BMS will be expired.
In this case, BMS does not send any one way traffic after expiring MAC aging time on destination side, because there is no input frame.
Also, if Server sets Static ARP, ARP broadcast is not occurred, hence there is no way to receive ARP request on TSN.

[Daisuke Nakajima (dnakajima)]

When ARP status is STALE on BM and MAC address aging timer is expired on ToR, some packets are dropped, because Unknown unicast frames are dropped on TSN.

If MAC aging timer is expired on ToR, ToR sends massages to TSN, then TSN deletes MAC address from its L2 database. However BM still use Unicast frame and sends ARP request which is assigned Unicast MAC address as Destination MAC address. (frame 6 in test1.pcap)
After that, BM sends ARP request which is assigned Broadcast MAC address. (frame12 in test1.pcap)

root@system012:~# ip netns exec p7p1_NS_1 ip -s neighbor list
10.0.0.3 dev p7p1.1 lladdr 00:21:9b:00:01:01 used 152/149/128 probes 4 STALE　<<<<

root@system012:~# ip netns exec p7p1_NS_1 ping 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=11 ttl=64 time=0.275 ms
64 bytes from 10.0.0.3: icmp_seq=12 ttl=64 time=0.270 ms
64 bytes from 10.0.0.3: icmp_seq=13 ttl=64 time=0.280 ms

[Ashish Ranjan (aranjan-n)]

@Daisuke

We had a discussion on this. Our understanding is currently if we we increase mac timeout on TOR to match ARP timeout we should not see this problem. Pl confirm.

In future, we will track each MAC delete request in TSN. For all such MACs we will look into ARP database and generate a unicast grat arp. BM's response will refresh MAC on TOR which will be synced via OVSDB. This should solve the problem.

Note that we do not want to flood unknown unicast packet as it leads to various flooding/ddos issues as in typical L2 networks.

[Ashish Ranjan (aranjan-n)]

@Daisuke

   2.20 is best effort. 2.30 is more like it.

[Hari Prasad Killi (haripk)]

Here is the plan for this issue:

In R2.2, unknown unicast will be flooded, based on a global knob (provisioning).
Post R2.2, a config knob to control this behavior per VN will be added.

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/9533
Committed: http://github.org/Juniper/contrail-vrouter/commit/7ff3bced6d2f9bc58978781961d2681fea74d62b
Submitter: Zuul
Branch: master

commit 7ff3bced6d2f9bc58978781961d2681fea74d62b
Author: Divakar <email address hidden>
Date: Sun Apr 26 22:21:20 2015 -0700

Flooding of Unknown unicast Frames

The L2 bridge miss packets are dropped as of now. This leads
to network disconnectivity if BM ARP timeout is longer than Bridge
timeout. To avoid this, unknow unicast packets are flooded
into multicast tree. This flooding is limited by per VN flag
for user. For Vrouter, the per VN flag is trnanslated to VIF
and VrfTranslate NH. If unicast lookup fails, and if the above
flag is set, packet if forwarded to broadcast tree. A counter is also
added when unknown unicast is flooded.

Change-Id: Ia618f6fa981e13b0163e0cd5cb3bdb0919fad901
partial-bug:#1424523

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/9666
Committed: http://github.org/Juniper/contrail-vrouter/commit/97eae8e4a64a3d910f777c4fcab3c968e78f74c7
Submitter: Zuul
Branch: R2.20

commit 97eae8e4a64a3d910f777c4fcab3c968e78f74c7
Author: Divakar <email address hidden>
Date: Wed Apr 29 02:27:17 2015 -0700

Flooding of Unknown unicast Frames

The L2 bridge miss packets are dropped as of now. This leads
to network disconnectivity if BM ARP timeout is longer than Bridge
timeout. To avoid this, unknow unicast packets are flooded
into multicast tree. This flooding is limited by per VN flag
for user. For Vrouter, the per VN flag is trnanslated to VIF
and VrfTranslate NH. If unicast lookup fails, and if the above
flag is set, packet if forwarded to broadcast tree. A counter is also
added when unknown unicast is flooded.

Change-Id: Ia618f6fa981e13b0163e0cd5cb3bdb0919fad901
partial-bug: #1424523

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/9372
Committed: http://github.org/Juniper/contrail-controller/commit/deccf6a39f7b32b26822af2748aebb81b9a7cf67
Submitter: Zuul
Branch: master

commit deccf6a39f7b32b26822af2748aebb81b9a7cf67
Author: Naveen N <email address hidden>
Date: Wed Apr 29 12:02:55 2015 +0530

Add option to enable or disable flooding of unknown unicast mac.

Schema changes to support enabling or disabling of unknown unicast
mac. Agent changes to have a per interface flag and nexthop flag to
indicate whether unknown unicast mac should be broadcasted will be
added, as a follow up commit.
Partial-Bug:#1424523

Change-Id: I7d19bc97041368c7da1cbbaeffcf29f293fd5a8f

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/9807
Committed: http://github.org/Juniper/contrail-controller/commit/b35f8866892ca7dab95a72049e3449b1c50af14d
Submitter: Zuul
Branch: R2.20

commit b35f8866892ca7dab95a72049e3449b1c50af14d
Author: Naveen N <email address hidden>
Date: Wed Apr 29 12:02:55 2015 +0530

Add option to enable or disable flooding of unknown unicast mac.

Schema changes to support enabling or disabling of unknown unicast
mac. Agent changes to have a per interface flag and nexthop flag to
indicate whether unknown unicast mac should be broadcasted will be
added, as a follow up commit.
Partial-Bug:#1424523

Change-Id: I7d19bc97041368c7da1cbbaeffcf29f293fd5a8f
(cherry picked from commit deccf6a39f7b32b26822af2748aebb81b9a7cf67)

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/9861
Committed: http://github.org/Juniper/contrail-controller/commit/4c67c942cf60d26560117f633eaa296e69c5f6cc
Submitter: Zuul
Branch: R2.20

commit 4c67c942cf60d26560117f633eaa296e69c5f6cc
Author: Naveen N <email address hidden>
Date: Mon May 4 14:34:27 2015 +0530

Agent changes to support unknown unicast flooding

* VMI would have a flag to specify whether unknown unicast
packet should be flooded.
* VXLAN NH also would have similar flag to specify unknown unicast
to be flooded or not.
* For ingress traffic, unknown unicast flow would have policy
applied based on ingress route, once layer2 route is added
flow would be reevaluated again.
Test cases for same.
Closes-Bug: #1424523

Change-Id: I327202f384df24f48ad7c7f32181d564f6ff105a
(cherry picked from commit 6e98f0d8a0f7fe74eb295cecd2d4301b1c2c8c93)

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/9590
Committed: http://github.org/Juniper/contrail-controller/commit/5c3432a997d2865edc85e0eb0e0fbb8896c6e990
Submitter: Zuul
Branch: master

commit 5c3432a997d2865edc85e0eb0e0fbb8896c6e990
Author: Naveen N <email address hidden>
Date: Wed May 6 10:48:17 2015 +0530

Agent changes to support unknown unicast flooding

* VMI would have a flag to specify whether unknown unicast
packet should be flooded.
* VXLAN NH also would have similar flag to specify unknown unicast
to be flooded or not.
* For ingress traffic, unknown unicast flow would have policy
applied based on ingress route, once layer2 route is added
flow would be reevaluated again.
Test cases for same.
Closes-Bug: #1424523

Change-Id: I327202f384df24f48ad7c7f32181d564f6ff105a