[2.20-39~juno] Same MAC address on the SI ports causing ECMP in-net-nat and transit-vn cases failing in sanity

[Ganesha HV]

Topo
====
nodeb12

1]. created 2 svc_chains with transit_vn in between

vn1<----->si1<----->si2<----->vn2

2]. I see the same MAC on the left-intf of si2 and the right-intf of si1.

30.30.30.3/32 32 P - 47 2:cc:99:f7:2:71(108980)
30.30.30.4/32 32 P - 61 2:cc:99:f7:2:71(108980)

root@nodeb12:~# tcpdump -ne -i tap34dfc19e-c0
tcpdump: WARNING: tap34dfc19e-c0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap34dfc19e-c0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:46:40.854314 02:cc:99:f7:02:71 > 00:00:5e:00:01:00, ethertype IPv4 (0x0800), length 86: 30.30.30.3.53673 > 30.30.30.2.53: 51637+ A? update.juniper-updates.net. (44)
14:46:41.494576 02:cc:99:f7:02:71 > 00:00:5e:00:01:00, ethertype IPv4 (0x0800), length 98: 30.30.30.3 > 20.20.20.3: ICMP echo request, id 2193, seq 13353, length 64
14:46:41.502010 02:cc:99:f7:02:71 > 02:cc:99:f7:02:71, ethertype ARP (0x0806), length 42: Reply 30.30.30.3 is-at 02:cc:99:f7:02:71, length 28
14:46:42.098044 02:cc:99:f7:02:71 > 02:cc:99:f7:02:71, ethertype ARP (0x0806), length 42: Reply 30.30.30.3 is-at 02:cc:99:f7:02:71, length 28
14:46:42.494539 02:cc:99:f7:02:71 > 00:00:5e:00:01:00, ethertype IPv4 (0x0800), length 98: 30.30.30.3 > 20.20.20.3: ICMP echo request, id 2193, seq 17728, length 64
14:46:42.997839 02:cc:99:f7:02:71 > 02:cc:99:f7:02:71, ethertype ARP (0x0806), length 42: Reply 30.30.30.3 is-at 02:cc:99:f7:02:71, length 28
14:46:43.494539 02:cc:99:f7:02:71 > 00:00:5e:00:01:00, ethertype IPv4 (0x0800), length 98: 30.30.30.3 > 20.20.20.3: ICMP echo request, id 2193, seq 8150, length 64
14:46:43.797820 02:cc:99:f7:02:71 > 02:cc:99:f7:02:71, ethertype ARP (0x0806), length 42: Reply 30.30.30.3 is-at 02:cc:99:f7:02:71, length 28

Ping between the end-vms is failing.

The same issue is seen in case of in-network-nat ECMP cases too.

Related commit : https://github.com/Juniper/contrail-controller/commit/8f29f768d8cfb70d71e314269e7cecebd21ebafa

[Naveen N (naveenn)]

If there are 2 VM with same MAC address, then in vrouter bridge table only
one of the VM was would be marked as next hop.
In case of ECMP all ARP requests raised would be bridged and all arp reply
would reach only one service instance, rest of the service instance would never
get the arp replies.
In case of active-backup mode, only one of the EVPN route would be published
and hence the problem would not happen.

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/11306
Submitter: Prakash Bailkeri (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/11327
Submitter: Rudra Rugge (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/11328
Submitter: Rudra Rugge (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

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

commit 8488ab57ad1c6cbce898b7318958d3b379cb810d
Author: Rudra Rugge <email address hidden>
Date: Fri Jun 5 15:46:35 2015 -0700

Generate mac from instance ip for service VMs

Generate the same mac-address for all interfaces sharing the same
IP.

Change-Id: I6276f48e851afb5becb932e6ae3d33c2813217b5
Closes-Bug: #1461882

[OpenContrail Admin (ci-admin-f)]

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

commit 560f20c318f8cbf3db8d72860d90a864a276e881
Author: Rudra Rugge <email address hidden>
Date: Fri Jun 5 15:42:55 2015 -0700

Generate mac from instance ip for service VMs

Generate the same mac-address for all interfaces sharing the same
IP. In addition a change to daemonize the haproxy process instead
of managing through supervisor.

Change-Id: I2394f29c4a11bffeee4b0184ce6cd6867b01e0e9
Closes-Bug: #1461882

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/11506
Committed: http://github.org/Juniper/contrail-vrouter/commit/9ce106be352e7139ce7222061c95ced7d123204f
Submitter: Zuul
Branch: R2.20

commit 9ce106be352e7139ce7222061c95ced7d123204f
Author: Divakar <email address hidden>
Date: Thu Jun 11 09:23:26 2015 -0700

ARP response on request interface for service instance

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when ARP request is received from service VM
Vrouter needs to send ARP response on the incoming interface
rather bridging the ARP reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the ARP reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Id90228b432e2d86360a7b77d332b7cdb701cf144
closes-bug: #1461882

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/13871
Submitter: Rudra Rugge (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/13871
Committed: http://github.org/Juniper/contrail-controller/commit/245f6d85c7d28aedb5bb28f4b09b8c2a766b5c56
Submitter: Zuul
Branch: R2.22-dev

commit 245f6d85c7d28aedb5bb28f4b09b8c2a766b5c56
Author: Rudra Rugge <email address hidden>
Date: Thu May 14 13:41:45 2015 -0700

LBAAS haproxy process manager

Manage haproxy daemon for lbaas. Two options avaialable:
- Manage through supervisor. This will run on non-daemon mode
as the process cannot be managed by supervisord if it runs in
background. Process monitoring provided by supervisor.
- Start/stop the daemon as we do today. Need additional changes
to ensure monitoring/restarting of the process.

Additional commit needed to enable this code from vrouter_netns.

Change-Id: I05c13d7c96c86bee2fcddc73342ba28c6010c8e6
Partial-Bug: #1452928

Enable haproxy config translation

Enable haproxy config translation from json format
Also enable haproxy daemon handling by supervisord

Change-Id: If3489ea66430ec0ac50bb6198093a0689fa16219
Closes-Bug: #1452928

Conflicts:

 src/nodemgr/haproxy_stats.py

Generate mac from instance ip for service VMs

Generate the same mac-address for all interfaces sharing the same
IP. In addition a change to daemonize the haproxy process instead
of managing through supervisor.

Change-Id: I2394f29c4a11bffeee4b0184ce6cd6867b01e0e9
Closes-Bug: #1461882

Haproxy config generation fixes for HTTPS protocol

Change-Id: I140361ad4785be2a87d23a04181e73ca999e8e2b
Closes-bug: #1466318

Fix for poodle vulnerability; ChangeId: I9432d035eb59b1ff53cb5d33350cd5f8063e077c; Closes-Bug: #1475392

Change-Id: I390a77261bc0d3257108c06951c79f1d2c3dadaa

Fix for FREAK SSL vulnerability

This fix pushes selected set of secure ciphers into
haproxy config file

Change-Id: Idfc11ce0411024e7154d3b2c46a095fb4f80337d
Closes-Bug: #1477400

HAProxy Performance Tuning

HAProxy's default config is non-performant.
This fix updates following config in HAProxy:
1) Increase TCP client/server timeouts.
2) Increase ulimit globally per HAProxy process.
3) Increase maxconn globally per HAProxy process.

Change-Id: I28be29d5ab3dcb2a35fcbe9168300edf18b2c23c
Closes-Bug: #1477781

Allow custom configs with LBaaS

This fix takes care of haproxy parsing and
validation changes on vrouter agent. Removing
extra white spaces

Closes-Bug: #1475393
Change-Id: I822e27792f78168a178d555db5703fa1e73d0cc9

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/14371
Submitter: Varun Lodaya (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/14576
Submitter: Varun Lodaya (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

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

commit 888049f626fbd7d6ad349ffb2270bcc3886958f1
Author: Rudra Rugge <email address hidden>
Date: Fri May 8 10:54:27 2015 -0700

Generate loadbalancer config in json format

Currently the agent generates loadbalancer configuration in
haproxy specific format. Going forward agent will generate
a generic json based loadbalancer config. This config will
be handled by driver specific configuration parser. Currently
only haproxy parsing is supported.

Closes-Bug: #1452928
Change-Id: I2d198aff0a569615ac5c331e4b6c582b93d9d3a3

Conflicts:
 src/vnsw/agent/oper/loadbalancer_haproxy.cc

LBAAS haproxy process manager

Manage haproxy daemon for lbaas. Two options avaialable:
- Manage through supervisor. This will run on non-daemon mode
as the process cannot be managed by supervisord if it runs in
background. Process monitoring provided by supervisor.
- Start/stop the daemon as we do today. Need additional changes
to ensure monitoring/restarting of the process.

Additional commit needed to enable this code from vrouter_netns.

Change-Id: I05c13d7c96c86bee2fcddc73342ba28c6010c8e6
Partial-Bug: #1452928

Enable haproxy config translation

Enable haproxy config translation from json format
Also enable haproxy daemon handling by supervisord

Change-Id: If3489ea66430ec0ac50bb6198093a0689fa16219
Closes-Bug: #1452928

Conflicts:

 src/nodemgr/haproxy_stats.py

Generate mac from instance ip for service VMs

Generate the same mac-address for all interfaces sharing the same
IP. In addition a change to daemonize the haproxy process instead
of managing through supervisor.

Change-Id: I2394f29c4a11bffeee4b0184ce6cd6867b01e0e9
Closes-Bug: #1461882

Haproxy config generation fixes for HTTPS protocol

Change-Id: I140361ad4785be2a87d23a04181e73ca999e8e2b
Closes-bug: #1466318

Fix for poodle vulnerability; ChangeId: I9432d035eb59b1ff53cb5d33350cd5f8063e077c; Closes-Bug: #1475392

Change-Id: I390a77261bc0d3257108c06951c79f1d2c3dadaa

Fix for FREAK SSL vulnerability

This fix pushes selected set of secure ciphers into
haproxy config file

Change-Id: Idfc11ce0411024e7154d3b2c46a095fb4f80337d
Closes-Bug: #1477400

HAProxy Performance Tuning

HAProxy's default config is non-performant.
This fix updates following config in HAProxy:
1) Increase TCP client/server timeouts.
2) Increase ulimit globally per HAProxy process.
3) Increase maxconn globally per HAProxy process.

Change-Id: I28be29d5ab3dcb2a35fcbe9168300edf18b2c23c
Closes-Bug: #1477781

Allow custom configs with LBaaS

This fix takes care of haproxy parsing and
validation changes on vrouter agent. Removing
extra white spaces

Closes-Bug: #1475393
Change-Id: I822e27792f78168a178d555db5703fa1e73d0cc9

Allow custom configs with LBaaS

This fix enables a new field "custom-attr" in loadbalancer_pool
properties in the schema.

Change-Id: I17eecc2fedea4d1d3889b7e114e99732ac2eecc9
Closes-Bug: #1475393

Allow custom configs with LBaaS

This fix commits the vrouter agent code to read
the custom_attributes from ifmap node and copy it
to config.json file...

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit c8a6f77cc82d190aea1900a05bff2ab9ba061a7f
Author: Divakar <email address hidden>
Date: Thu Jun 11 09:23:26 2015 -0700

ARP response on request interface for service instance

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when ARP request is received from service VM
Vrouter needs to send ARP response on the incoming interface
rather bridging the ARP reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the ARP reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Id90228b432e2d86360a7b77d332b7cdb701cf144
closes-bug: #1461882

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

commit e9d6b26794da49e3bcb617a785520d45b67b03fa
Author: Divakar D <email address hidden>
Date: Sat Oct 8 19:25:38 2016 +0530

Transmit V6 Neighbour advertisement on the receiving interface

This fix is IPV6 equivalent of
https://review.opencontrail.org/#/c/11506/.

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when neighbour request is received from service VM
Vrouter needs to send response on the incoming interface
rather bridging the reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Ib0113227019d7a452541129843813a647d388b36
closes-bug: #1461882

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/24972
Committed: http://github.org/Juniper/contrail-vrouter/commit/d64b7732ce4134caee765964afdf19630a710bd2
Submitter: Zuul
Branch: R3.1

commit d64b7732ce4134caee765964afdf19630a710bd2
Author: Divakar D <email address hidden>
Date: Sat Oct 8 19:25:38 2016 +0530

Transmit V6 Neighbour advertisement on the receiving interface

This fix is IPV6 equivalent of
https://review.opencontrail.org/#/c/11506/.

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when neighbour request is received from service VM
Vrouter needs to send response on the incoming interface
rather bridging the reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Ib0113227019d7a452541129843813a647d388b36
closes-bug: #1461882

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/24974
Committed: http://github.org/Juniper/contrail-vrouter/commit/5bb795b0ed779a1c984d89e9122fb73fbbf38864
Submitter: Zuul
Branch: R3.0.3.x

commit 5bb795b0ed779a1c984d89e9122fb73fbbf38864
Author: Divakar D <email address hidden>
Date: Sat Oct 8 19:25:38 2016 +0530

Transmit V6 Neighbour advertisement on the receiving interface

This fix is IPV6 equivalent of
https://review.opencontrail.org/#/c/11506/.

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when neighbour request is received from service VM
Vrouter needs to send response on the incoming interface
rather bridging the reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Ib0113227019d7a452541129843813a647d388b36
closes-bug: #1461882

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/24973
Committed: http://github.org/Juniper/contrail-vrouter/commit/e894f7e028afd0a879d52f4f68a7daf1c56dedf6
Submitter: Zuul
Branch: R3.0

commit e894f7e028afd0a879d52f4f68a7daf1c56dedf6
Author: Divakar D <email address hidden>
Date: Sat Oct 8 19:25:38 2016 +0530

Transmit V6 Neighbour advertisement on the receiving interface

This fix is IPV6 equivalent of
https://review.opencontrail.org/#/c/11506/.

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when neighbour request is received from service VM
Vrouter needs to send response on the incoming interface
rather bridging the reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Ib0113227019d7a452541129843813a647d388b36
closes-bug: #1461882

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/25213
Committed: http://github.org/Juniper/contrail-vrouter/commit/79be2aaf30ff4df90354719fa25f82703ed3539f
Submitter: Zuul
Branch: R3.0.3.x

commit 79be2aaf30ff4df90354719fa25f82703ed3539f
Author: Divakar D <email address hidden>
Date: Mon Oct 24 12:28:13 2016 +0530

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/25214
Committed: http://github.org/Juniper/contrail-vrouter/commit/bae0a3c608a2b375c1f4e2e8995d1a0167be0397
Submitter: Zuul
Branch: R3.1

commit bae0a3c608a2b375c1f4e2e8995d1a0167be0397
Author: Divakar D <email address hidden>
Date: Mon Oct 24 12:28:13 2016 +0530

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/25212
Committed: http://github.org/Juniper/contrail-vrouter/commit/8d407c895f36e6ab9f637411552e7c07064c6293
Submitter: Zuul
Branch: R3.0

commit 8d407c895f36e6ab9f637411552e7c07064c6293
Author: Divakar D <email address hidden>
Date: Mon Oct 24 12:28:13 2016 +0530

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931

[OpenContrail Admin (ci-admin-f)]

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

commit b0e09fe98ec2cf92cb3461aa86c5e8e54fc4186b
Author: Divakar D <email address hidden>
Date: Mon Oct 24 12:28:13 2016 +0530

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/25215
Committed: http://github.org/Juniper/contrail-vrouter/commit/dc00a57466a78abfdf2d2871574e6c3beffa70a4
Submitter: Zuul
Branch: R3.2

commit dc00a57466a78abfdf2d2871574e6c3beffa70a4
Author: Divakar D <email address hidden>
Date: Mon Oct 24 12:28:13 2016 +0530

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931

[Vineet Gupta (vineetrf)]

Divakar - Please close if fixed.

[Hari Prasad Killi (haripk)]

The bug got reopened because the commit for bug 1635931 had a comment referring to this bug. The script needs to be fixed to not do this. Closing this bug.

[OpenContrail Admin (ci-admin-f)]

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

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/26145
Committed: http://github.org/Juniper/contrail-vrouter/commit/5bdd3992309ef8cf138fff1b5af8332849a7959f
Submitter: Zuul
Branch: R3.0.2.x

commit 5bdd3992309ef8cf138fff1b5af8332849a7959f
Author: Divakar D <email address hidden>
Date: Sat Oct 8 19:25:38 2016 +0530

Transmit V6 Neighbour advertisement on the receiving interface

This fix is IPV6 equivalent of
https://review.opencontrail.org/#/c/11506/.

In in-network service instance case, when service scaling
is more than one, all the instances are going to have the
same mac address and IP address. Inet route points to
ECMP composite nexthop but FDB route does not point to ECMP
nexthop. So when neighbour request is received from service VM
Vrouter needs to send response on the incoming interface
rather bridging the reply packet, as FDB route points
to arbitrarly any of the service VM encap L2 nexthop.

After preparing the reply packet,bridge lookup is done
and outgoing interface is compared against ingress interface.
If they are not same, reply packet is transmitted on
ingress interface.

Change-Id: Ib0113227019d7a452541129843813a647d388b36
closes-bug: #1461882

Disable the flow processing for Neighbour Advertisements

The neighbour request packets are typically Multicast packets and there
is no flow processing for these. When a neighbour request is converted
to neighbour advertisement, we continue to use the same packet buffer
and same packet flags for this advertisement too. This ends up in not
creating a flow for neighbour advertisement too as the original packet
is marked as multicast packet. But the fix we gave
https://review.opencontrail.org/#/c/24973/ for bug: #1461882 for V6
resulted in creating new packet flags for advertisement and this is
resulting in flow being created. The flow processing is dropping the
response as the neighbour advertisement should have ideally come from
different interface.

We can fix this issue either by manipulating the source interface to
match the interface on which neighbour is falling so that flow
processing succeeds or by disabling the flow processing for
advertisements.

The fix now disables the flow processing for advertisements

Change-Id: Ic91f0fb794c13912e43d8c96c726bd80e559b7fb
closes-bug: #1635931