Fix ipv6 forwarding for datapath bridges

[jbemmel]

Fixes #2389

On many platforms and following security best practices, the default policy for IP forwarding is "drop". This PR modifies the existing firewall logic to dynamically create forwarding rules for both ipv4 and ipv6, on all bridges used in the topology.

This results in new rules in the DOCKER-USER chain for table ip (v4) and ip6, enabling IPv6 forwarding across bridges

Implementation notes:

• The endpoint_bridge Deploy function gets called many times, once per endpoint. The rules only need to be created once - the remaining calls go ignored. Feel free to move this logic to a more suitable place if needed
• The debug print of IP versions could be made nicer; in Python I would do 'IPv4' if v==xyz else 'IPv6' but I don't know the Go equivalent

[hellt]

can you plase create a clab topology that exhibits the issue?

[jbemmel]

can you plase create a clab topology that exhibits the issue?

name: initial
prefix: "clab"

mgmt:
  network: netlab_mgmt
  ipv4-subnet: 192.168.121.0/24
  # Note: 'start' not validated
topology:
  nodes:
    r:
      mgmt-ipv4: 192.168.121.101
      kind: ceos
      env: {'INTFTYPE': 'et', 'CLAB_MGMT_VRF': 'management'}
      image: ceos:4.33.0F
      runtime: docker
      group: 
    h1:
      mgmt-ipv4: 192.168.121.102
      kind: linux
      restart-policy: 'no'
      image: python:3.9-alpine
      runtime: docker
      group: hosts
      binds:
      - clab_files/h1/hosts:/etc/hosts
    h2:
      mgmt-ipv4: 192.168.121.103
      kind: linux
      restart-policy: 'no'
      image: python:3.9-alpine
      runtime: docker
      group: hosts
      binds:
      - clab_files/h2/hosts:/etc/hosts

    initial_1:
      kind: bridge

  links:
  - endpoints:
    - "r:et1"
    - "initial_1:r_et1"
  - endpoints:
    - "h1:eth1"
    - "initial_1:h1_eth1"
  - endpoints:
    - "h2:eth1"
    - "initial_1:h2_eth1"

Created by Netlab:

---
defaults.device: eos

groups:
  _auto_create: True
  hosts:
    members: [ h1, h2 ]
    device: linux
    provider: clab

nodes:
  r:

links:
- r:
  h1:
  h2:
  prefix.ipv6: 2001::/64

validate:
  ipv6_def_route:
    description: Check RA-generated default route
    wait: 30
    wait_msg: Waiting for RA message to generate the default route
    nodes: [ h1, h2 ]
    plugin: default6()
    stop_on_error: True

It's easier to do netlab up with the above topology, than for me to copy/paste the resulting EOS config. The key part is:

!
interface Ethernet1
   description r -> [h1,h2] [stub]
   mac-address 52:dc:ca:fe:01:01
   no switchport
   ipv6 address 2001::1/64
   ipv6 nd ra interval msec 5000
!

(and you could use FRR too - same issue)

[hellt]

I believe RA has no play in any of this. Can a simple topology with linux hosts and ping6 be used to validate this?

[jbemmel]

I believe RA has no play in any of this. Can a simple topology with linux hosts and ping6 be used to validate this?

As well:

name: tests
prefix: "clab"

mgmt:
  network: netlab_mgmt
  ipv4-subnet: 192.168.121.0/24
  # Note: 'start' not validated
topology:
  nodes:
    x1:
      mgmt-ipv4: 192.168.121.101
      kind: linux
      restart-policy: 'no'
      image: python:3.9-alpine
      runtime: docker
    x2:
      mgmt-ipv4: 192.168.121.102
      kind: linux
      restart-policy: 'no'
      image: python:3.9-alpine
      runtime: docker
    x3:
      mgmt-ipv4: 192.168.121.103
      kind: linux
      restart-policy: 'no'
      image: python:3.9-alpine
      runtime: docker

    tests_1:
      kind: bridge

  links:
  - endpoints:
    - "x1:eth1"
    - "tests_1:x1_eth1"
  - endpoints:
    - "x2:eth1"
    - "tests_1:x2_eth1"

(source: ipspace/netlab#1669)

[hellt]

implemented in #2401 as part of a bigger refactoring