> > $ cat /etc/hostname.switch0
> > add em0
> > up
> >
> > Here, em0 is the egress interface connected to the dedicated/bare-metal
> > machine provider's network. This provider's network is beyond my
> > control. As such, there might be a loop in the provider's network.
>
> (Sorry, was meaning to respond but got busy)
> That's my suspicion, the network you're connected to, rather than your
> switch. Say, if you are still trying to use switch(4), there's a
> chance that this might help:
>
> https://marc.info/?l=openbsd-tech&m=152424475112610&w=2
Thank you Koshibe-san for your reply.
Please, no sorry. I am grateful for your help.
Currently, I am using a bridge. From what I understand from the patch
and the cvsweb history, that patch is waiting for ok and commit.
This is my first time running a patch, so I may have messed up the
steps. Based on some inspiration from [1], I have used the following
steps for running the patch on -current:
$ doas user mod -G wsrc <user>
$ exit
<relogin to let user mod take effect>
$ cd /usr
$ cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -P src
$ cd /usr/src
$ cvs -q up -Pd -A
$ cd /usr/src/usr.sbin/switchd
$ vi ofp13.c
<make patch changes>
$ doas user mod -G wobj <user>
$ exit
<relogin to let user mod take effect>
$ cd /usr/src/usr.sbin/switchd
$ make obj
$ make
$ doas make install
Then the usual switch0, switchd and switchctl steps, as mentioned in
my previous mails.
This time, the switch does not close. However, I am still unable to
ping 8.8.8.8 with the switch. As usual, I am able to ping 8.8.8.8
using a bridge.
There is a continuous stream of messages when running "switchd -dvv":
...
switch_learn: updated mac 11:11:11:11:11:11 on switch 1 port 1
packet_input: 11:11:11:11:11:11 -> 22:22:22:22:22:22, port 1 -> 1
ofrelay_input_done: connection 1.1: 1528 bytes from switch 1
/dev/switch0 > any: version 1_3 type PACKET_IN length 1528 xid 11362
buffer NO_BUFFER length 1478 reason REASON_NO_MATCH table <0> cookie 0x0
000000000000000
match type OXM length 24 (padded to 26)
ox match class OPENFLOW_BASIC type IN_PORT hasmask no length 4
1
ox match class OPENFLOW_BASIC type META hasmask no length 8
0
<repeat above message multiple times with incrementing xids 11363...>
...
switch_learn: updated mac 22:22:22:22:22:22 on switch 1 port 1
packet_input: 22:22:22:22:22:22 -> ff:ff:ff:ff:ff:ff, port 1 -> 4294967295
any > /dev/switch0: version 1_3 type PACKET_OUT length 100 xid 10
buffer NO_BUFFER in_port <1> actions_len 16
action OUTPUT len 16 port FLOOD max_len NO_BUFFER
ofrelay_input_done: connection 1.1: 110 bytes from switch 1
...
<repeat port 1 -> 1 messages with incrementing xids 11366...>
<infrequent repeat port 1 -> 4294967295 messages with incrementing xids 11...>
I have noticed in the ifconfig output that the bridge has "rstp" while
there is no "rstp" or "stp" for the switch. It may be possible that the
provider has redundant internet routes, and that the bridge with the
spanning tree protocol might be able to handle it while the switch
may not be. This is just my guess as a layman user and I may be wrong
since I do not know whether spanning tree protocol is applicable for
the switch. I base this on the absence of stp options in the man pages
for switch/switchd/switchctl/switchd.conf.
Furthermore, the output of "switchctl show summary" displays a large
number of macs with ages within 10 seconds, although the switch has
been up for upwards of 1000 seconds. These macs seem to never go above
10 seconds. Two macs in particular are always age 0s. There is only one
switch - /dev/switch0.
Finally, I have a query - What does the tap0 interface do? I ask this
because currently I do not pass in/out tap0 traffic in pf. This is
because I do not know what tap0 is and what it does. With a "block log"
in pf and "tcpdump -nettti pflog0", I get the following output:
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
<timestamp> rule 1/(match) block in on tap0:<RandomPublicIP> >
239.255.255.250.1900: udp 94 (DF) [tos 0x38] [ttl 1]
...
<repeat above message every 10 seconds...>
If I run a ping 8.8.8.8, the ping packets do not show up in the above
output.
Regards,
ab
[1] - https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/005_httpd.patch.sig
---------|---------|---------|---------|---------|---------|---------|--
