CRS125-24 funky L2 bridging Behaviour? (no pppoe through)

Hi,

Scenario (all ROS 6.19, on CRS125-24 tried 6.20, no difference):

  • CRS125-24, all ports slaved to master port ether1.

  • CCR1016 ether2 hooked up to CRS24 ether24. PPPOE server set up on it. It has a bridge setup with ether2 (root), ether1,10,11,12

  • BaseBox (used as testing unit, pppoe client/MAC ping from it) hooked up to CRS125-24 ether6.

From the BaseBox/CCR1016 I only can MAC-Ping CRS125-24 master-port 1; all other CRS24 ports timeout. Guess this is expected and has to do with the master port switching group, where all slave port macs are ignored. Sounds reasonable.

But… It seems something is preventing true L2 bridging between the CCR1016 and the BaseBox:

MAC Ping from CCR1016 (either from ether2 or bridge) to BaseBox ether1 MAC succeed.
MAC-Ping from the basebox ether1 to CCR1016 ether2 MAC FAILS.

Of course PPPOE client on BaseBox never connects to PPPOE Server on the CCR1016, as I see BaseBox sending PADI and the PPPOE server receiving it from the BaseBox ether1 MAC address, then sending PADO to the BaseBox, that never “sees” it, which is reasonable as there seems no true L2 bridging is in effect as it’s not able to MAC-Ping the CCR1016??

What am I missing??? Tried disabling CRS125-24 switch setting mac-isolation with no difference…

Update: changed all ports on CRS125-24, now master port is ether24, which is hooked to CCR1016 ether2.

Now the MAC-pingeable MAC in CRS125-24 is ether24’s as expected.

However, same bahaviour persists; BaseBox is not able to MAC-Ping CCR1016 ether2’s mac.

Nor any device connected to the CRS125-24 as I have just tested… non are able to mac-ping the CCR1016.

Do you have the PPPoE server bound to the ether2 port, or to the bridge on the CCR? Have you tried with ether2 removed from the bridge on the CCR (and/or with the PPPoE server bound to the bridge)?

Which port is the bridge on the CCR taking its MAC from? Typically, if ether1 is running, I would expect auto-mac on the CCR to set the MAC of the bridge to the MAC of ether1, not ether2. You can control which MAC the bridge gets by setting the admin-mac and disabling auto-mac.

Have you verified there is no firewall running/catching your traffic on any of the devices?

Hi DLNoah, thanks for your reply!

PPPoE Server is bound to ether2, also tried binding it t the bridge with no difference.

You nailed it! Will be more careful when setting bridges in the future, as you said the bridge had taken ether1 mac and “disabled” the resting etherX MACs (which sounds reasonable, as it happens with the etherX master-port settings).

Set ether2 MAC as admin-mac, but Where’s the auto-mac setting?? Cannot locate it in the winbox gui, though I see is disabled in a export after setting admin-mac.

No filters or NAT of any kind in bridges/ip firewall.

You nailed it, thanks! :smiley: Owe you some beers if you ever came to Seville!

In Winbox GUI, setting an admin-mac automatically disables auto-mac (changes it to auto-mac=no). Via command line/terminal, I always make sure I set both options; I’ve not done testing to figure out if ROS is intelligent enough to auto-disable auto-mac regardless of how an admin-mac is entered. I’d rather enter a few extra keystrokes than get a surprise :slight_smile:

The exact technical reason that auto-mac would typically pick ether1’s MAC from the ports you named is that auto-mac will default to the lowest MAC address of all ports in the bridge. RouterBOARDs will universally assign MAC’s to the Ethernet ports so that ether1 is the lowest, and increasing from there. In general, the wlan interfaces (e.g. on 911’s) are then assigned after the Ethernet ports.

If you’re still having problems getting the PPPoE session to bind, can you post the (sanitized) configs for your PPPoE server & client, and the log output of the PPPoE server from the CCR?

Yep, already read all about that in the wiki, lesson learnt: be careful with bridges and always know what you’re doing… thanks for your explanation!

PPPoE Service work like a charm :slight_smile:

Having serious problems with other thing now: mANT30’s… gonna open a new post about it.