Updates for Ebtables and support for multi-asic.

[abdosi]

Why/What I did:

Following changes were done for ebtables:

• Support for Multi-asic platforms. Ebtable filters are installed in namespace for multi-asic and not host. On Single asic installed on host.

• For Multi-asic platforms we don't want to install on host otherwise Namespace-to-Namespace communication does not happens since ARP Request are not forwarded.

• Updated to use text file to restore ebtables rules then the binary format. Rules are restore as part of Database docker init instead of rc.local

• Removed the ebtable service files for buster as not needed as filters are restored/installed as part of database docker init.
  All the binaries are pre-installed with ebtables* binary are same as ebatbles-legacy-*

How I verrify:

• On Single Asic:

admin@str-xxxx-on-2:~$ sudo ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 3, policy: ACCEPT
-d BGA -j DROP
-p ARP -j DROP
-p 802_1Q --vlan-encap ARP -j DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

• On Multi Asic:

admin@str2-xxxx-acs-3:~$ sudo ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
admin@str2-xxxx-acs-3:~$ sudo ip netns exec asic0 ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 3, policy: ACCEPT
-d BGA -j DROP
-p ARP -j DROP
-p 802_1Q --vlan-encap ARP -j DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

[prsunny]

I think the ebtable service was added for reboot scenarios to save and restore. @yxieca , do you remember?

[abdosi]

I think the ebtable service was added for reboot scenarios to save and restore. @yxieca , do you remember?

It should get restored with this also as part of database docker init

[abdosi]

@yxieca can you please review this.

[yxieca]

I think the ebtable service was added for reboot scenarios to save and restore. @yxieca , do you remember?

It should get restored with this also as part of database docker init

@abdosi the rules in dockers will be restored upon database docker start. We don't have scenario to restart database docker, do we have a risk of losing the configuration and not reapplied? I guess the service is an oneshot service so we are not regressing anything.

Also found out that Guohan added the service because ebtable is not enabled by default on buster.

[abdosi]

I think the ebtable service was added for reboot scenarios to save and restore. @yxieca , do you remember?

It should get restored with this also as part of database docker init

@abdosi the rules in dockers will be restored upon database docker start. We don't have scenario to restart database docker, do we have a risk of losing the configuration and not reapplied? I guess the service is an oneshot service so we are not regressing anything.

Also found out that Guohan added the service because ebtable is not enabled by default on buster.

@yxieca Verified load minigraph and config reload where we don't start database docker configuration are not lost.

[abdosi]

@lguohan waiting on this check Azure.sonic-buildimage (Test vstest) ? What need to be done.

[lguohan]

better to add a test in sonic-mgmt test to compare the ebtables with expected value.

[abdosi]

better to add a test in sonic-mgmt test to compare the ebtables with expected value.

@lguohan sonic-net/sonic-mgmt#2944