Re: Issues converting from bridge(4) to switch(4)
Here is some tcpdumps as well, for reference there is a client connected to em1 which is sending the ARP and DHCP request packets. dhcpd is listening on vether0. switch0: 15:09:28.708823 arp who-has 8.8.8.8 tell 169.254.10.62 15:09:29.574297 0.0.0.0.68 > 255.255.255.255.67: xid:0x1e787469 \ secs:46 [|bootp] [tos 0x10] 15:09:29.574536 0.0.0.0.68 > 255.255.255.255.67: xid:0x1e787469 \ secs:46 [|bootp] [tos 0x10] 15:09:29.574557 0.0.0.0.68 > 255.255.255.255.67: xid:0x1e787469 \ secs:46 [|bootp] [tos 0x10] 15:09:31.672393 arp who-has 8.8.4.4 tell 169.254.10.62 vether0: 15:09:28.708794 arp who-has 8.8.8.8 tell 169.254.10.62 15:09:29.574547 0.0.0.0.68 > 255.255.255.255.67: xid:0x1e787469 \ secs:46 [|bootp] [tos 0x10] 15:09:29.574787 10.0.0.1.67 > 10.0.0.33.68: xid:0x1e787469 \ secs:46 Y:10.0.0.33 S:10.0.0.1 [|bootp ] [tos 0x10] 15:09:31.672628 arp who-has 8.8.4.4 tell 169.254.10.62 em1: 15:09:12.676542 arp who-has 8.8.4.4 tell 169.254.10.62 15:09:13.467594 0.0.0.0.68 > 255.255.255.255.67: xid:0x1e787469 \ secs:30 [|bootp] [tos 0x10] 15:09:13.700573 arp who-has 8.8.4.4 tell 169.254.10.62 I just realized I grabbed the wrong chunk of the em1 log (it has the 30 second poll instead of the 46) but otherwise it is identical. The same packet appears 3 times on switch0 (which has vether0, em1 and em2 -- em2 doesn't have an active carrier and no tcpdump was done but I suspect that packet would show up there). The response from vether0 doesn't appear on switch0 or em1 however. John On Fri, Nov 6, 2020 at 3:21 PM John McGuigan wrote: > > After reading through the switch section of the ifconfig manpage I > changed the line in /etc/hostname.switch0 from: > > add vether0 > > to: > > addlocal vether0 > > Unfortunately, I'm still having the same issue, I can see ARP and DHCP > packets from the client computer on em1, vether0 and switch0, and can > see the ARP-REPLY and DHCP-REPLY packets on vether0 but they > never show up on vether0 or switch0. I also tried: > > sysctl net.inet.ip.forwarding=1 > > In case there was an issue forwarding between interfaces but no luck. > > Also tested this on the Nov 3rd 6.8-current snapshot with the same > results. > > Does anyone recognize this issue, packet replies not being forwarded > from the vether0 to physical adapter on a switch(4)? > > For reference, this behavior doesn't happen if I use a bridge(4) with > the same ports and hostname.if except for the addlocal vs add > I mentioned earlier. > > If someone wouldn't mind replicating this on their hardware (I've > tested this on two APU2s) it would definitely be appreciated. > > Thanks, > > John
Re: Issues converting from bridge(4) to switch(4)
After reading through the switch section of the ifconfig manpage I changed the line in /etc/hostname.switch0 from: add vether0 to: addlocal vether0 Unfortunately, I'm still having the same issue, I can see ARP and DHCP packets from the client computer on em1, vether0 and switch0, and can see the ARP-REPLY and DHCP-REPLY packets on vether0 but they never show up on vether0 or switch0. I also tried: sysctl net.inet.ip.forwarding=1 In case there was an issue forwarding between interfaces but no luck. Also tested this on the Nov 3rd 6.8-current snapshot with the same results. Does anyone recognize this issue, packet replies not being forwarded from the vether0 to physical adapter on a switch(4)? For reference, this behavior doesn't happen if I use a bridge(4) with the same ports and hostname.if except for the addlocal vs add I mentioned earlier. If someone wouldn't mind replicating this on their hardware (I've tested this on two APU2s) it would definitely be appreciated. Thanks, John
Re: Issues converting from bridge(4) to switch(4)
I get no output with monitor: prometheus# time switchctl monitor ^C1m27.15s real 0m00.00s user 0m00.00s system I also tried plugging in a different device into em1 while the monitor was running but I didn't get any output. Here is the output of switchd as well, the output continues to grow with incrementing xids. prometheus# switchd -dvv listen on 0.0.0.0:6653 ofrelay_attach: new connection 1.1 ofp_open: new connection 1.1 from switch 0 any > /dev/switch0: version 1_3 type HELLO length 16 xid 0 version bitmap: version 1_0 version 1_3 ofrelay_input_done: connection 1.1: 8 bytes from switch 0 /dev/switch0 > any: version 1_3 type HELLO length 8 xid 1530 any > /dev/switch0: version 1_3 type FEATURES_REQUEST length 8 xid 1 ofrelay_input_done: connection 1.1: 32 bytes from switch 1 /dev/switch0 > any: version 1_3 type FEATURES_REPLY length 32 xid 1 datapath_id 0x264921d244b07e9a nbuffers 0 ntables 254 aux_id 0 \ capabilities 0x0f any > /dev/switch0: version 1_3 type MULTIPART_REQUEST length 16 xid 2 type TABLE_FEATURES flags empty table properties request any > /dev/switch0: version 1_3 type SET_CONFIG length 12 xid 3 flags miss_send_len NO_BUFFER ofrelay_input_done: connection 1.1: 1048 bytes from switch 1 /dev/switch0 > any: version 1_3 type MULTIPART_REPLY length 1048 xid 2 type TABLE_FEATURES flags table features length 1032 tableid <0> name "" metadata match \ 0x write 0x config 0 max_entries 1 INSTRUCTION (length 20): type GOTO_TABLE length 4 type WRITE_META length 4 type WRITE_ACTIONS length 4 type APPLY_ACTIONS length 4 type CLEAR_ACTIONS length 4 INSTRUCTION_MISS (length 20): type GOTO_TABLE length 4 type WRITE_META length 4 type WRITE_ACTIONS length 4 type APPLY_ACTIONS length 4 type CLEAR_ACTIONS length 4 APPLY_ACTIONS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 APPLY_ACTIONS_MISS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 WRITE_ACTIONS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 WRITE_ACTIONS_MISS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 MATCH (length 136): class OPENFLOW_BASIC type IN_PORT length 4 class OPENFLOW_BASIC type META length 8 class OPENFLOW_BASIC type ETH_DST length 6 class OPENFLOW_BASIC type ETH_SRC length 6 class OPENFLOW_BASIC type ETH_TYPE length 2 class OPENFLOW_BASIC type VLAN_VID length 2 class OPENFLOW_BASIC type VLAN_PCP length 1 class OPENFLOW_BASIC type IP_DSCP length 1 class OPENFLOW_BASIC type IP_ECN length 1 class OPENFLOW_BASIC type IP_PROTO length 1 class OPENFLOW_BASIC type IPV4_SRC length 4 class OPENFLOW_BASIC type IPV4_DST length 4 class OPENFLOW_BASIC type TCP_SRC length 2 class OPENFLOW_BASIC type TCP_DST length 2 class OPENFLOW_BASIC type UDP_SRC length 2 class OPENFLOW_BASIC type UDP_DST length 2 class OPENFLOW_BASIC type SCTP_SRC length 2 class OPENFLOW_BASIC type SCTP_DST length 2 class OPENFLOW_BASIC type ICMPV4_TYPE length 1 class OPENFLOW_BASIC type ICMPV4_CODE length 1 class OPENFLOW_BASIC type ARP_OP length 2 class OPENFLOW_BASIC type ARP_SPA length 4 class OPENFLOW_BASIC type ARP_TPA length 4 class OPENFLOW_BASIC type ARP_SHA length 6 class OPENFLOW_BASIC type ARP_THA length 6 class OPENFLOW_BASIC type IPV6_SRC length 16 class OPENFLOW_BASIC type IPV6_DST length 16 class OPENFLOW_BASIC type IPV6_FLABEL length 4 class OPENFLOW_BASIC type ICMPV6_TYPE length 1 class OPENFLOW_BASIC type ICMPV6_CODE length 1 class OPENFLOW_BASIC type IPV6_ND_TARGET length 16 class OPENFLOW_BASIC type IPV6_ND_SLL length 6 class OPENFLOW_BASIC type IPV6_ND_TLL length 6 class OPENFLOW_BASIC type TUNNEL_ID length 8 WILDCARDS (length 132): class OPENFLOW_BASIC type META length 8 class OPENFLOW_BASIC type ETH_DST length 6 class OPENFLOW_BASIC type ETH_SRC length 6 class OPENFLOW_BASIC type ETH_TYPE length 2 class OPENFLOW_BASIC type VLAN_VID length 2 class OPENFLOW_BASIC type VLAN_PCP length 1 class OPENFLOW_BASIC type IP_DSCP length 1 class OPENFLOW_BASIC type IP_ECN length 1 class OPENFLOW_BASIC type IP_PROTO length 1 class OPENFLOW_BASIC type IPV4_SRC length 4 class OPENFLOW_BASIC type IPV4_DST length 4 class OPENFLOW_BASIC type TCP_SRC length 2 class OPENFLOW_BASIC type TCP_DST length 2 class OPENFLOW_BASIC type UDP_SRC length 2 class OPENFLOW_BASIC type UDP_DST length 2 class OPENFLOW_BASIC type SCTP_SRC length 2 class OPENFLOW_BASIC type SCTP_DST length 2 class OPENFLOW_BASIC
Re: Issues converting from bridge(4) to switch(4)
what output does switchctl monitor give you On Thu, 29 Oct 2020 at 17:16, John McGuigan wrote: > > prometheus$ ifconfig em0 > em0: flags=808843 \ > mtu 1500 > lladdr 00:0d:b9:be:ef:94 > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > inet 192.168.1.80 netmask 0xff00 broadcast 192.168.1.255 > > prometheus$ ifconfig em1 > em1: flags=8b43 MULTICAST> mtu 1500 > lladdr 00:0d:b9:be:ef:95 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > > prometheus$ ifconfig em2 > em2: flags=8b43 MULTICAST> mtu 1500 > lladdr 00:0d:b9:be:ef:96 > index 3 priority 0 llprio 3 > media: Ethernet autoselect (none) > status: no carrier > > prometheus$ cat /etc/hostname.em0 > dhcp > prometheus$ cat /etc/hostname.em1 > up > prometheus$ cat /etc/hostname.em2 > up > > On Thu, Oct 29, 2020 at 11:10 AM Tom Smyth > wrote: > > > > what is your ifconfig em0 > > ifconfig em1 > > ? > > > > On Thu, 29 Oct 2020 at 17:07, John McGuigan wrote: > > > > > > Howdy misc, > > > > > > I have an APU2 with the following configuration under 6.8: > > > > > > em0 = WAN > > > em1 = bridge0 LAN > > > em2 = bridge0 LAN > > > vether = 10.0.0.1 > > > > > > prometheus$ cat /etc/hostname.bridge0 > > > add vether0 > > > add em1 > > > add em2 > > > up > > > > > > prometheus$ cat /etc/hostname.vether0 > > > inet 10.0.0.1 255.255.255.0 10.0.0.255 > > > > > > I have dhcpd listening on vether0 and it works just fine. I have a > > > client connected to em1 and it can ping 10.0.0.1 with no issues. > > > > > > The trouble started when I wanted to implement a switch(4) instead > > > of the bridge(4): > > > > > > I moved /etc/hostname.bridge0 to /etc/hostname.switch0 > > > > > > prometheus$ cat /etc/switchd.conf > > > device "/dev/switch0" > > > > > > switchd was enabled via rcctl > > > > > > When I rebooted the system the client on em1 no longer got a dhcp > > > response and can't ping 10.0.0.1 > > > > > > ifconfig snippet: > > > > > > switch0: flags=41 > > > index 6 llprio 3 > > > groups: switch > > > datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 > > > vether0 flags=0<> > > > port 7 ifpriority 0 ifcost 0 > > > em1 flags=0<> > > > port 2 ifpriority 0 ifcost 0 > > > em2 flags=0<> > > > port 3 ifpriority 0 ifcost 0 > > > vether0: flags=8943 \ > > > mtu 1500 > > > lladdr fe:e1:ba:d0:0b:ca > > > index 7 priority 0 llprio 3 > > > groups: vether > > > media: Ethernet autoselect > > > status: active > > > inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > > > > > > > > > With tcpdump on vether0 I see the arp requests from the client for > > > 10.0.0.1 but vether0 doesn't respond. > > > > > > I see the same arp traffic on switch0 and em1 via tcpdump too. > > > > > > The switch seems to have learned the mac address of the client: > > > > > > prometheus$ switchctl show macs > > > SwitchPortTypeNameInfo > > > 1 2 mac f0:de:f1:23:13:37 age 3s > > > > > > Unfortunately, I don't really know how to dig any deeper at this issue. > > > Does anyone here see a glaring mistake or would be able to nudge me in > > > a better direction? > > > > > > Thanks, > > > > > > John > > > > > > > > > -- > > Kindest regards, > > Tom Smyth. -- Kindest regards, Tom Smyth.
Re: Issues converting from bridge(4) to switch(4)
prometheus$ ifconfig em0 em0: flags=808843 \ mtu 1500 lladdr 00:0d:b9:be:ef:94 index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.1.80 netmask 0xff00 broadcast 192.168.1.255 prometheus$ ifconfig em1 em1: flags=8b43 mtu 1500 lladdr 00:0d:b9:be:ef:95 index 2 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active prometheus$ ifconfig em2 em2: flags=8b43 mtu 1500 lladdr 00:0d:b9:be:ef:96 index 3 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier prometheus$ cat /etc/hostname.em0 dhcp prometheus$ cat /etc/hostname.em1 up prometheus$ cat /etc/hostname.em2 up On Thu, Oct 29, 2020 at 11:10 AM Tom Smyth wrote: > > what is your ifconfig em0 > ifconfig em1 > ? > > On Thu, 29 Oct 2020 at 17:07, John McGuigan wrote: > > > > Howdy misc, > > > > I have an APU2 with the following configuration under 6.8: > > > > em0 = WAN > > em1 = bridge0 LAN > > em2 = bridge0 LAN > > vether = 10.0.0.1 > > > > prometheus$ cat /etc/hostname.bridge0 > > add vether0 > > add em1 > > add em2 > > up > > > > prometheus$ cat /etc/hostname.vether0 > > inet 10.0.0.1 255.255.255.0 10.0.0.255 > > > > I have dhcpd listening on vether0 and it works just fine. I have a > > client connected to em1 and it can ping 10.0.0.1 with no issues. > > > > The trouble started when I wanted to implement a switch(4) instead > > of the bridge(4): > > > > I moved /etc/hostname.bridge0 to /etc/hostname.switch0 > > > > prometheus$ cat /etc/switchd.conf > > device "/dev/switch0" > > > > switchd was enabled via rcctl > > > > When I rebooted the system the client on em1 no longer got a dhcp > > response and can't ping 10.0.0.1 > > > > ifconfig snippet: > > > > switch0: flags=41 > > index 6 llprio 3 > > groups: switch > > datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 > > vether0 flags=0<> > > port 7 ifpriority 0 ifcost 0 > > em1 flags=0<> > > port 2 ifpriority 0 ifcost 0 > > em2 flags=0<> > > port 3 ifpriority 0 ifcost 0 > > vether0: flags=8943 \ > > mtu 1500 > > lladdr fe:e1:ba:d0:0b:ca > > index 7 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > > > > > > With tcpdump on vether0 I see the arp requests from the client for > > 10.0.0.1 but vether0 doesn't respond. > > > > I see the same arp traffic on switch0 and em1 via tcpdump too. > > > > The switch seems to have learned the mac address of the client: > > > > prometheus$ switchctl show macs > > SwitchPortTypeNameInfo > > 1 2 mac f0:de:f1:23:13:37 age 3s > > > > Unfortunately, I don't really know how to dig any deeper at this issue. > > Does anyone here see a glaring mistake or would be able to nudge me in > > a better direction? > > > > Thanks, > > > > John > > > > > -- > Kindest regards, > Tom Smyth.
Re: Issues converting from bridge(4) to switch(4)
what is your ifconfig em0 ifconfig em1 ? On Thu, 29 Oct 2020 at 17:07, John McGuigan wrote: > > Howdy misc, > > I have an APU2 with the following configuration under 6.8: > > em0 = WAN > em1 = bridge0 LAN > em2 = bridge0 LAN > vether = 10.0.0.1 > > prometheus$ cat /etc/hostname.bridge0 > add vether0 > add em1 > add em2 > up > > prometheus$ cat /etc/hostname.vether0 > inet 10.0.0.1 255.255.255.0 10.0.0.255 > > I have dhcpd listening on vether0 and it works just fine. I have a > client connected to em1 and it can ping 10.0.0.1 with no issues. > > The trouble started when I wanted to implement a switch(4) instead > of the bridge(4): > > I moved /etc/hostname.bridge0 to /etc/hostname.switch0 > > prometheus$ cat /etc/switchd.conf > device "/dev/switch0" > > switchd was enabled via rcctl > > When I rebooted the system the client on em1 no longer got a dhcp > response and can't ping 10.0.0.1 > > ifconfig snippet: > > switch0: flags=41 > index 6 llprio 3 > groups: switch > datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 > vether0 flags=0<> > port 7 ifpriority 0 ifcost 0 > em1 flags=0<> > port 2 ifpriority 0 ifcost 0 > em2 flags=0<> > port 3 ifpriority 0 ifcost 0 > vether0: flags=8943 \ > mtu 1500 > lladdr fe:e1:ba:d0:0b:ca > index 7 priority 0 llprio 3 > groups: vether > media: Ethernet autoselect > status: active > inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > > > With tcpdump on vether0 I see the arp requests from the client for > 10.0.0.1 but vether0 doesn't respond. > > I see the same arp traffic on switch0 and em1 via tcpdump too. > > The switch seems to have learned the mac address of the client: > > prometheus$ switchctl show macs > SwitchPortTypeNameInfo > 1 2 mac f0:de:f1:23:13:37 age 3s > > Unfortunately, I don't really know how to dig any deeper at this issue. > Does anyone here see a glaring mistake or would be able to nudge me in > a better direction? > > Thanks, > > John > -- Kindest regards, Tom Smyth.
Issues converting from bridge(4) to switch(4)
Howdy misc, I have an APU2 with the following configuration under 6.8: em0 = WAN em1 = bridge0 LAN em2 = bridge0 LAN vether = 10.0.0.1 prometheus$ cat /etc/hostname.bridge0 add vether0 add em1 add em2 up prometheus$ cat /etc/hostname.vether0 inet 10.0.0.1 255.255.255.0 10.0.0.255 I have dhcpd listening on vether0 and it works just fine. I have a client connected to em1 and it can ping 10.0.0.1 with no issues. The trouble started when I wanted to implement a switch(4) instead of the bridge(4): I moved /etc/hostname.bridge0 to /etc/hostname.switch0 prometheus$ cat /etc/switchd.conf device "/dev/switch0" switchd was enabled via rcctl When I rebooted the system the client on em1 no longer got a dhcp response and can't ping 10.0.0.1 ifconfig snippet: switch0: flags=41 index 6 llprio 3 groups: switch datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 vether0 flags=0<> port 7 ifpriority 0 ifcost 0 em1 flags=0<> port 2 ifpriority 0 ifcost 0 em2 flags=0<> port 3 ifpriority 0 ifcost 0 vether0: flags=8943 \ mtu 1500 lladdr fe:e1:ba:d0:0b:ca index 7 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 With tcpdump on vether0 I see the arp requests from the client for 10.0.0.1 but vether0 doesn't respond. I see the same arp traffic on switch0 and em1 via tcpdump too. The switch seems to have learned the mac address of the client: prometheus$ switchctl show macs SwitchPortTypeNameInfo 1 2 mac f0:de:f1:23:13:37 age 3s Unfortunately, I don't really know how to dig any deeper at this issue. Does anyone here see a glaring mistake or would be able to nudge me in a better direction? Thanks, John
