vlan bridge to port

RouterOS General
1

Hi, guys, the router is RB4011iGS,

I create vlan70 on bridger1, bridge it to bridge2, vlan70 has a PPPoE service, so far I can PPPoE Scan successfully on bridge2.
Then I bridge port9 to bridge2, but I can’t do PPPoE on the machines that plug to the port9, how can I make this work?

Thanks in advanced.

-IG

2

How do you bridge to another bridge???
Why not put all on same bridge LOL.

3

Exactly as Anav said. This is not adidas (more stripes = more adidas = better). More bridges are not better. More bridges are bad and lead to serious misconfigurations

4

What the OP is doing is OK and is simply the old way of creating “access” ports for VLANs where the VLAN is untagged (before bridge VLAN filtering). Doing it the old way can still be justified on platforms other than CRS3xx due to the fact that you can have VLANs while not losing hardware offload for all ports.

The problem is the PPPoE server needs to be listening on bridge2, not on vlan70.

5

Because I’d like to make an access port in a stupid way.

6

thanks, I just want an access port on port9, I check bridge VLAN filter guide, but seems not supported in my router’s sw chip.

7

Thanks for the reply, the PPPoE service is not on routeros, actually it comes from other device via vlan70, and I want to let only port9 to access it.

8

So the chain is ( == trunk/tagged connection, – access/tagless connection):

variant 1, works:
pppoe server == some network == etherX == bridge1 == interface vlan 70 – bridge2 – interface pppoe-client (internal)

variant 2, doesn’t work:
pppoe server == some network == etherX == bridge1 == interface vlan 70 – bridge2 – ether9 – external PPPoE client

Correct?

If so, what does /tool sniffer quick mac-protocol=pppoe-discovery show, on the widest text window your screen allows, if you first run it and then connect the external pppoe client? You should see how far the PADI got and with what VLAN tag, and how far the PADO response got (if it came at all).

9

Thanks! That’s correct…

The sniff like:

[admin@MikroTik] > /tool sniffer quick mac-protocol=pppoe-discovery
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
ether9 80.509 78 ← C8:hide:AC 00:0hide1:5F
vlan70 80.509 79 → C8:hide:AC 00:0hide1:5F
bridge1 80.509 80 → C8:hide:AC 00:0hide1:5F 70
ether5 80.509 81 → C8:hide:AC 00:0hide1:5F 70
ether9 86.515 82 ← C8:hide:AC 00:0hide1:5F
vlan70 86.515 83 → C8:hide:AC 00:0hide1:5F
bridge1 86.515 84 → C8:hide:AC 00:0hide1:5F 70
ether5 86.515 85 → C8:hide:AC 00:0hide1:5F 70
ether9 89.518 86 ← C8:hide:AC 00:0hide1:5F
vlan70 89.518 87 → C8:hide:AC 00:0hide1:5F
bridge1 89.518 88 → C8:hide:AC 00:0hide1:5F 70
ether5 89.518 89 → C8:hide:AC 00:0hide1:5F 70
ether9 92.52 90 ← C8:hide:AC 00:0hide1:5F
vlan70 92.52 91 → C8:hide:AC 00:0hide1:5F
bridge1 92.52 92 → C8:hide:AC 00:0hide1:5F 70
ether5 92.52 93 → C8:hide:AC 00:0hide1:5F 70
ether9 95.523 94 ← C8:hide:AC 00:0hide1:5F
vlan70 95.523 95 → C8:hide:AC 00:0hide1:5F
bridge1 95.523 96 → C8:hide:AC 00:0hide1:5F 70
ether5 95.523 97 → C8:hide:AC 00:0hide1:5F 70

eth5 is the ethX bridge to bridge1.

I also tried vlan-filtering, but no success so far, my 4011 RB hates me..




10

First, as on the 4011, activation of vlan-filtering on bridge disables “hardware accelerated bridging”, I’d stick with the approach you’ve started from if you need your other LAN devices to talk to each other, VLAN 70 is the single one for which tagging/untagging is necessary, and you don’t need STP protocol (i.e. no interconnected switches).

Other than that - the quotation from the middle of the sniff shows that the PPPoE client is sending pppoe-discovery frames to a unicast MAC address (00:0h:i****d:ei:t1:5F) and gets no responses, which indicates that it is either totally broken or that it has successfully received a PADO response to a PADI frame it has sent before; the PADI always goes to the broadcast MAC address FF:FF:FF:FF:FF:FF. In the latter case, the 4011 does its job well and the problem is somewhere else (most likely, authentication protocol choice or user credentials are wrong).

Disable the PPPoE client on the machine connected to ether9, configure a name of a file for the sniffer (/tool sniffer set file-name=pppoe-start-sniff.pcap), run the sniffer again and then re-activate the PPPoE client. Once you can see just the frame towards the unicast MAC address to come from the client every 3 seconds like above, quit the sniffer, download the file and open it using Wireshark. You’ll see what was going on and possibly also what went wrong. If it’s too much for you, post the pcap file (not a screenshot).

11

Thank you for your kind and helpful tips, Sindy! Wireshark helped, Problem solved. It caused by other devices in fact…