[R2.20.43] : BMS receiving duplicate arp packet

[chhandak]

Problem
---------------
When Sending ARP request from a BMS for another BMS in same QFX in same VN, BMS (Target) is receiving duplicate ARP packet.
One is forwarded by QFX and other is going till back up tor agent/tsn and backup tsn is forwarding it back to QFX.

Topology
---------------------

                           VXLAN Traffic MPLSoUDP Traffic

BMS1------QFX---------------Active Tor Agent /TSN------------- Backup TOR Agent
                      | |
                      | |
                  BMS2 |
                                  <<<---------------------------------------------------------- +

                                                          VXLAN Traffic

ARP Coming from QFX to Active TSN
----------------------------------------------------------
root@nodei10:~# tcpdump -ni bond0 udp port 4789 -c 3
tcpdump: WARNING: bond0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:10:07.010610 IP 34.34.34.34.27441 > 192.168.22.5.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46
17:10:07.011676 IP 34.34.34.34.27441 > 192.168.22.5.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46
17:10:07.012682 IP 34.34.34.34.27441 > 192.168.22.5.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46
17:10:07.013687 IP 34.34.34.34.27441 > 192.168.22.5.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46
17:10:07.014632 IP 34.34.34.34.27441 > 192.168.22.5.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46

Active TSN is forwarding traffic to backup TSN
--------------------------------------------------------------------------
root@nodei10:~# tcpdump -ni bond0 host 192.168.22.4 -c 3
tcpdump: WARNING: bond0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:10:50.530692 IP 192.168.22.5.60741 > 192.168.22.4.51234: UDP, length 104
17:10:50.531785 IP 192.168.22.5.60741 > 192.168.22.4.51234: UDP, length 104
17:10:50.532784 IP 192.168.22.5.60741 > 192.168.22.4.51234: UDP, length 104
17:10:50.533787 IP 192.168.22.5.60741 > 192.168.22.4.51234: UDP, length 104
17:10:50.534758 IP 192.168.22.5.60741 > 192.168.22.4.51234: UDP, length 104

Backup TSN is sending traffic back to QFX
-----------------------------------------------------------------
root@nodei9:~# tcpdump -ni bond0 udp port 4789 -c 3
tcpdump: WARNING: bond0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:12:16.251408 IP 192.168.22.4.56533 > 34.34.34.34.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46
17:12:16.252390 IP 192.168.22.4.50249 > 34.34.34.34.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46
17:12:16.253455 IP 192.168.22.4.61800 > 34.34.34.34.4789: VXLAN, flags [I] (0x08), vni 20050
ARP, Request who-has 20.0.25.56 tell 20.0.25.60, length 46

Setup
-----------
host1 = 'root@10.204.217.118'
host2 = 'root@10.204.217.119'
host3 = 'root@10.204.217.120'
host4 = 'root@10.204.217.121'
host5 = 'root@10.204.217.122'
host6 = 'root@10.204.217.131'

env.roledefs = {
    'all': [host1, host2, host3, host4, host5, host6],
    'cfgm': [host1, host2, host3],
    'openstack': [host1, host2, host3],
    'webui': [host2],
    'control': [host1, host3],
    'compute': [host4, host5, host6],
    'tsn': [host4, host5],
    'toragent': [host4, host5],
    'collector': [host1, host3],
    'database': [host1, host2, host3],
    'build': [host_build],
}

env.hostnames = {
    'all': ['nodei6', 'nodei7', 'nodei8', 'nodei9', 'nodei10', 'nodei19']
}

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/11485
Submitter: Manish Singh (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

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

commit 38b64f4c186614ba791905deb6215e3db3235ef7
Author: Manish <email address hidden>
Date: Thu Jun 11 15:24:04 2015 +0530

Tor agent didnt unsubscribe for multicast route.

Problem:
When OVSDB connection went off route was deleted from TOR agent
however it didnt send the unsubscription to controller. Now this
resulted in multiple TSN in olist of multicast route.
This was happening because agent was deriving prefix using tunnel
NH in multicast route(of tor agent). The destination of tunnel
NH is used to reate the EVPN prefix. Since at time of deletion
path was not present tunnel NH used to be NULL and in absence of information
agent skipped sending unsubscribe.

Solution:
Store destination and source of tunnel NH in state and use it during deletion.

Change-Id: Iaa0e5d3aaf276c075b9f31eb6ce5e6d7d0119bc9
Closes-bug: 1463799

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/11536
Submitter: Manish Singh (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

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

commit 89405e4d59d6818741f5523014c1b8f9e721bcf3
Author: Manish <email address hidden>
Date: Thu Jun 11 15:24:04 2015 +0530

Tor agent didnt unsubscribe for multicast route.

Problem:
When OVSDB connection went off route was deleted from TOR agent
however it didnt send the unsubscription to controller. Now this
resulted in multiple TSN in olist of multicast route.
This was happening because agent was deriving prefix using tunnel
NH in multicast route(of tor agent). The destination of tunnel
NH is used to reate the EVPN prefix. Since at time of deletion
path was not present tunnel NH used to be NULL and in absence of information
agent skipped sending unsubscribe.

Solution:
Store destination and source of tunnel NH in state and use it during deletion.

Closes-bug: 1463799
(cherry picked from commit 38b64f4c186614ba791905deb6215e3db3235ef7)

Conflicts:
 src/vnsw/agent/controller/controller_export.cc
 src/vnsw/agent/controller/controller_peer.cc
 src/vnsw/agent/controller/controller_peer.h

Change-Id: Iaa0e5d3aaf276c075b9f31eb6ce5e6d7d0119bc9