Network link between Vyos and modem not coming up

General questions
,
1

Hi all!

I have a slightly weird one here.

The goal is to have a Vyos VM be my gateway/firewall, with my VDSL2 modem in bridge mode.

I have Vyos installed in a KVM running on Proxmox 8.1. Its connection to the rest of my network comes via a bridged interface, passing it a Transit VLAN from my core switch. (Vyos doesn’t know about the VLANs, I have the tag set in the network adapter settings in the config for the virtual machine).
That side is working fine, I ssh in via that interface and it is currently handing out my network’s DHCP leases without a problem.

I have a modem from my ISP, which is a bit antiquated and I’d like to reduce its participation in the network a bit, so I can do more with the firewall side of things for example. It does support bridge mode for the PPPoE connection.

Up until not, it’s been connected to the core switch via its LAN1 port, no trouble. Once in bridge mode, I still want to be able to access its admin interface for troubleshooting if needed, so I recent switched that cable to its LAN4 port, since bridge mode uses LAN1. Again, no problem. Can still browse the net, access the modem, so on.

On the Proxmox host, I set one of the Ethernet ports on it to be passed through to the VM as a PCI passthrough, so I never end up with the bridged internet connection ending up connected to anything but Vyos. Again, that’s working fine, and if I connect a raspberry pi to that port Vyos detects the lower layer being up, although since there is no static IP and no dhcp happening there, that’s all that happens.

Where it gets a little weird is that if I take that same cable and now plug it into LAN1 on the modem, it stays down. Both Vyos and the Modem report the connection unplugged, and there is no activity LED on either port.

I thought maybe they’re detecting it as a loop, so I unplugged LAN4 and tried again, but still nothing.

If I connect LAN4 and LAN1 to the core switch at the same time, they both report as up, if I connect the port for Vyos to the core switch it reports as lower up, but nothing if I connect LAN1 to Vyos.

The modem’s LANside IP is staticly set on the modem.

Anyone has any idea what could cause that behaviour? It has me a bit stumped…

I have rebooted by Vyos VM as well as the Proxmox host.
I have used Vyos to disable and then reenable the interface, no change.

I even took a stab and set the modem into bridge mode and tried to bring up the PPPoE connection but there is no connectivity.

So hopefully someone here will shine a light on the obvious thing I’m missing and get it working for me :stuck_out_tongue:

Thanks!

2

I had to set hw-id as the interfaces keep switching names (eth0, eth1) on reboot, back when I first set up the VM

interfaces config 
ethernet eth0 {
     description "To Modem"
     hw-id 3c:ec:ef:0c:9d:b8
     ipv6 {
         address {
             no-default-link-local
         }
     }
     vif 10 {
         ipv6 {
             address {
                 no-default-link-local
             }
         }
     }
 }
 ethernet eth1 {
     address 10.42.255.254/30
     description LAN
     hw-id 3e:00:a5:c8:6e:56
     ipv6 {
         address {
             no-default-link-local
         }
     }
 }
 loopback lo {
 }
 pppoe pppoe0 {
     authentication {
         password <password>
         user <username>
     }
     default-route auto
     description WAN
     mtu 1492
     no-peer-dns
     source-interface eth0.10
 }
show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             -                                 u/D  To Modem
eth0.10          -                                 u/D  
eth1             10.42.255.254/30                  u/u  LAN
lo               127.0.0.1/8                       u/u

I compiled Vyos from the 1.3 branch on GitHub about 3 months ago, admittedly probably need to update

3

Are you sure this isn’t something as simple as needing a crossover cable?

4

Hmmm… that’s possible, the modem is a pretty antiquated thing. I’ve gotten so used to devices that just auto negotiate the pairs that it didn’t even cross my mind.

I’ll see if I have one, and get one if not, and report back

5

Sadly, no change.

Gave me a really good nostalgia trip back to my 8-9 year old self trying to get my friends and my computers to connect together to play Freelancer back in the day though. So the 5 bucks for the cable was well worth it :joy:

6

Ok is it possible the modem is only standing up at 100mb/s and your NIC doesn’t support that? It seems something very layer 1 that’s the issue just based on your first post.

What does ethtool <proxmox port> report?

1 Like
7

And that’s it! The modem only supports 10/100, but the port I’m connected into is only 1000/10000. Was only using it since it’s on the NIC that connects off the to switch, but the main board’s NIC does 100 so I’ll switch to that

Thanks heaps for the advice!

8

Uh, so I spoke too soon.
Switched the PCIe passthrough to one of the 10/100/1000 ports on the mainboard, moved the cable and still nothing!

ethtool eth0 
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: off (auto)
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: no

Tried with both the original cable and the new crossover cable in case it was a combination of issues…

9

Did you ever get to the bottom of this @TonyArr ?

10

Not yet, though I had to put it in the back burner for a little while.
I’ll dive in again either end of this week or late next week to see if I can figure it out.

Are you having a similar behaviour?