Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

On Mon, May 14, 2018 at 1:01 PM, Aham Brahmasmi  wrote:
> Thank you Koshibe-san for your reply.
>
>> I've actually held back on that diff since it's a bit insufficient by itself.
>
> Ok.
>
>> Actually, you said that you had just em0 on that switch. Can you try
>> adding a local port (addlocal instead of add) alongside em0? It will
>> be a vether(4) interface that needs to be given em0's current address,
>> in its place.
>
> Should I be doing the following? And if yes, what address should em0
> have?
>
> $ cat /etc/hostname.vether0
> inet 1.2.3.4 255.255.255.0
> $ cat /etc/hostname.em0
> inet ?.?.?.? 255.255.255.0
> $ doas ifconfig switch0 create
> $ doas ifconfig switch0 add em0
> $ doas ifconfig switch0 addlocal vether0
> $ doas ifconfig switch0 up
>
> Here, 1.2.3.4 is the external public IP address of the machine
> originally assigned to em0.

em0 shouldn't have an address, and you'll also want to explicitly
enable vether0. Otherwise that looks fine.

>> > There is a continuous stream of messages when running "switchd -dvv":
>> > ...
>>
>> I can't say what they are without the full output, but you will tend
>> to see broadcasts (periodic or otherwise) like your second example
>> even on your bridge. From a second look at your earlier logs, it seems
>> the 1->1 'loops' are generated by the switch seeing VLAN traffic in
>> other parts of the network.
>
> Ok. Would sharing the full output of "switchd -dvv" help?

I wouldn't worry much about it, unless adding the local port doesn't
work for you.

> Interestingly, while searching for addlocal, I encountered a
> presentation on switch [1]. On page 13 of that pdf, there is mention of
> the switch sharing the STP code with bridge. Would it be correct to
> assume that there would be no loops if there was STP in the switch?

Even with a bridge, you'd need to enable STP and set priority values
on the ports for it to work, so you're correct - if there were any
loops, the bridge probably wouldn't have worked either. But you've
also seen that, for switch(4), the STP-related options aren't
available in ifconfig, and as far as I can tell switchd doesn't do
topology/loop detection (and probably won't want to rely on (R)STP to
do so). So, the code might be shared, but is likely not used.


> Regards,
> ab
> [1] - https://www.openbsd.org/papers/bsdcan2016-switchd.pdf
> -|-|-|-|-|-|-|--

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

> tap0 is a control interface created by switchd to communicate with
> switches. It won't carry normal network traffic.

(Last bit of noise, and I'm done)
Actually, I think I'm wrong here. I'll need to dig a bit more to
answer correctly.

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

On Sat, May 12, 2018 at 8:54 PM, Ayaka Koshibe <akosh...@gmail.com> wrote:
>> 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.
>
> I've actually held back on that diff since it's a bit insufficient by itself.

Sorry, I should elaborate. If you plan to try the local port, you may
still want the patch in place to prevent the switch from
disconnecting.

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

> 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.

I've actually held back on that diff since it's a bit insufficient by itself.

> 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.

Actually, you said that you had just em0 on that switch. Can you try
adding a local port (addlocal instead of add) alongside em0? It will
be a vether(4) interface that needs to be given em0's current address,
in its place.

> There is a continuous stream of messages when running "switchd -dvv":
> ...

I can't say what they are without the full output, but you will tend
to see broadcasts (periodic or otherwise) like your second example
even on your bridge. From a second look at your earlier logs, it seems
the 1->1 'loops' are generated by the switch seeing VLAN traffic in
other parts of the network.

> 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.

tap0 is a control interface created by switchd to communicate with
switches. It won't carry normal network traffic.

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

> $ 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=152424475112610=2

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

On Wed, Apr 11, 2018 at 6:25 AM, Aham Brahmasmi <aham.brahma...@gmx.com> wrote:
>> Sent: Wednesday, April 11, 2018 at 10:18 AM
>> From: "Ayaka Koshibe" <akosh...@gmail.com>
>> To: misc@openbsd.org
>> Subject: Re: Cannot access internet with virtual switch
>>
>> > This informs us that for a PACKET_OUT with action OUTPUT, it cannot
>> > have its port as ANY. Now, I do not know why for a PACKET_OUT message,
>> > an action OUTPUT cannot have port as ANY. More importantly, I do not
>> > know why the controller seems to be sending the PACKET_OUT with action
>> > OUTPUT and port ANY.
>>
>> A PACKET_OUT is usually a response to some message e.g. a PACKET_IN,
>> so it would probably help to see which message (if any) the switch
>> sent to the controller to receive that PACKET_OUT.
>
> Thank you Koshibe-san for your reply.
>
> From what I understand, the PACKET_IN for that PACKET_OUT seems to be
> the following:
>
> ofrelay_input_done: connection 1.1: 179 bytes from switch 1
> /dev/switch0 > any: version 1_3 type PACKET_IN length 179 xid 81972
> buffer NO_BUFFER length 129 reason REASON_NO_MATCH table <0> cookie 
> 0x
> 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
> switch_learn: updated mac ac:1f:6b:2e:22:ce on switch 1 port 1
> packet_input: ac:1f:6b:2e:22:ce -> 00:c8:8b:e2:d6:87, port 1 -> 1

This seems to be the right message. It looks like switchd will set the
output port to ANY if it sees a loop (which port 1 -> 1 suggests),
intended for dropping the packet. Do you have loops?

> I have also attached the complete output of "doas switchd -d". This
> is because I do not know whether the above message is the correct
> PACKET_OUT message corresponding to the PACKET_IN message.
>
> Regards,
> ab
> -|-|-|-|-|-|-|--

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

> This informs us that for a PACKET_OUT with action OUTPUT, it cannot
> have its port as ANY. Now, I do not know why for a PACKET_OUT message,
> an action OUTPUT cannot have port as ANY. More importantly, I do not
> know why the controller seems to be sending the PACKET_OUT with action
> OUTPUT and port ANY.

A PACKET_OUT is usually a response to some message e.g. a PACKET_IN,
so it would probably help to see which message (if any) the switch
sent to the controller to receive that PACKET_OUT.

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

On Fri, Apr 6, 2018 at 4:40 PM, Aham Brahmasmi  wrote:
> Hello misc,
>
> Problem
> A physical server with a switch (add em0 up) cannot access the internet.
> However, the same host with a bridge (add em0 up) can access the
> internet.
>
> Steps
> $ ifconfig
> em0: flags=8843 mtu 1500
> lladdr 22:22:22:22:22:22
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex,master)
> status: active
> inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255
> ...
> $ doas route -n show
> Routing tables
>
> Internet:
> Destination GatewayFlags   Refs  Use   Mtu  Prio Iface
> default 20.20.20.1 UGS0 1XXX - 8 em0
> 224/4   127.0.0.1  URS00 32768 8 lo0
> 127/8   127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1   127.0.0.1  UHhl   1X 32768 1 lo0
> 20.20.20/24 20.20.20.20UCn1  9XX - 4 em0
> 20.20.20.1  33:33:33:33:33:33  UHLch  1 1XXX - 3 em0
> 20.20.20.20 44:44:44:44:44:44  UHLl   0X - 1 em0
> 20.20.20.25520.20.20.20UHb00 - 1 em0
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms
> ...
> $ doas ifconfig switch0 create
> $ doas ifconfig switch0 add em0
> $ doas ifconfig switch0 up
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> ^C
> --- 8.8.8.8 ping statistics ---
> 31 packets transmitted, 0 packets received, 100.0% packet loss

Hi,

Seems you haven't started switchd(8), or connected your switch to it
-- it shouldn't forward traffic until you do so.

> $ ifconfig
> em0: flags=8b43 mtu 
> 1500
> lladdr 22:22:22:22:22:22
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex,master)
> status: active
> inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255
> switch0: flags=41
> index 6 llprio 3
> groups: switch
> datapath xx maxflow 1 maxgroup 1000
> em0 flags=0<>
> port 1 ifpriority 0 ifcost 0
> ...
> $ doas route -n show
> Routing tables
>
> Internet:
> Destination GatewayFlags   Refs  Use   Mtu  Prio Iface
> default 20.20.20.1 UGS0 1XXX - 8 em0
> 224/4   127.0.0.1  URS00 32768 8 lo0
> 127/8   127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1   127.0.0.1  UHhl   1X 32768 1 lo0
> 20.20.20/24 20.20.20.20UCn1  9XX - 4 em0
> 20.20.20.1  33:33:33:33:33:33  UHLch  1 1XXX - 3 em0
> 20.20.20.20 44:44:44:44:44:44  UHLl   0X - 1 em0
> 20.20.20.25520.20.20.20UHb00 - 1 em0
> $ doas ifconfig switch0 destroy
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms
>
> Repeating the above steps with bridge0 does let the ping pass through
> after the bridge is brought up. The only delta between the switch and
> bridge output is in the ifconfig.
> $ ifconfig
> bridge0: flags=41
> index 8 llprio 3
> groups: bridge
> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rtsp
> em0 flags=3
> port 1 ifpriority 0 ifcost 0
> ...
>
> I have run "doas route -n monitor" in a separate session while doing
> this. However, I cannot comprehend the output. pf is not involved -
> running tcpdump -nettti pflog0 with the catchall "block log" produces
> the normal output of blocked packets with the bridge. However, it stops
> producing the normal output of blocked packets with the switch. Once the
> switch is destroyed, it is back to normal blocked packets output.
>
> What am I doing wrong/missing? The only thing that stands out to me is
> the em0 flags=0<> line in the ifconfig for the switch. And I do not know
> what to make of it.
>
> Regards,
> ab
> -|-|-|-|-|-|-|--
>