Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect ipv6 Termination MAC entries when enslaving port to bridge #351

Open
hilmarm opened this issue Nov 5, 2021 · 4 comments
Open

Comments

@hilmarm
Copy link
Contributor

hilmarm commented Nov 5, 2021

Expected Behavior

Enslaving a port to a bridge, then tagging a vlan on the port should not create any Termination MAC entries.

Table ID 20 (Termination MAC):   Retrieving all entries. Max entries = 512, Current entries = 1.
--  inPort:mask = 7:0xffffffff etherType = 0x86dd destMac:mask = aa39.5aea.5990:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1)
| GoTo = 30 (Unicast Routing) outPort = 0 (Physical)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 14

Actual Behavior

Enslaving a port to a bridge, then tagging a vlan on the port does create a Termination MAC entries.

Steps to Reproduce the Problem

Set server side port UP before starting switch side configuration.

ip link set server_port up

On the Switch run the following commands:

Create vlan_filtering bridge swbridge

/sbin/ip link add name swbridge type bridge vlan_filtering 1

Set bridge swbridge up

/sbin/ip link set swbridge up

Attach port_left to the swbridge"

/sbin/ip link set {{ port_left }} master swbridge

Set port_left attached to swbridge up

/sbin/ip link set {{ port_left }} up

add vid 10 to port_left

/sbin/bridge vlan add vid 10 dev {{ port_left }}

Check termination MAC entries

client_flowtable_dump 20

Gives the output(example given):

Table ID 20 (Termination MAC):   Retrieving all entries. Max entries = 512, Current entries = 1.
--  inPort:mask = 7:0xffffffff etherType = 0x86dd destMac:mask = aa39.5aea.5990:ffff.ffff.ffff vlanId:mask = 0x1001:0x1fff (VLAN 1)
| GoTo = 30 (Unicast Routing) outPort = 0 (Physical)  | priority = 2 hard_time = 0 idle_time = 0 cookie = 14

Specifications

  • Version: 1.9.22
  • Platform: agema-ag7648
  • Subsystem:
@KanjiMonster
Copy link
Contributor

Does the port have a IP address assigned?

@hilmarm
Copy link
Contributor Author

hilmarm commented Nov 5, 2021

Does the port have a IP address assigned?

It does:

8: port2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::a0a3:f9ff:fefa:5f97/64 scope link 
       valid_lft forever preferred_lft forever

It seems that the flow appears depeding on what happens first between the following two:

  • bridge enslavement
  • ipv6 addr generation

If the ipv6 link-local address appears first, then the entry is created. If the port is attached to swbridge BEFORE the ipv6 address appears, the flow is not created. In my example given above, the ipv6 address is generated, and therefore the flow should exist (you can argue about ip addresses on bridged ports...).

But what about the case where the port is bridged before the ipv6 address is generated, should it not also generate an entry in the Termination MAC table?

@KanjiMonster
Copy link
Contributor

But what about the case where the port is bridged before the ipv6 address is generated, should it not also generate an entry in the Termination MAC table?

It should, so absence of one seems like the bug.

@jklare
Copy link
Contributor

jklare commented Nov 5, 2021

iirc somebody specifically implemented a check a while ago that made sure to consider the "bridge attachement status" before adding flow tables

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants