DHCP Client on tagged interface

RouterOS General
1

Hi All,

Today I encounter a situation where I need to have additional connectivity with my edge router we were able to saturate all the copper ports of CCR2116 so I decided to use SFP-SFPPLUS2 as tagged/trunk port for VLAN 14-15 respectively, to do that I pair my current CRS317 to CRS354 and make a trunk in between so that I can have two or more additional ports the idea is working great until I hit a snag

For my WAN13 which is vlan 14 I was able to obtain IP via DHCP with ONUISP1 which is great as intended

For my WAN14 which is vlan 15 It doesn’t work the uphill battle start I triple check for possible config issue and I can’t find anything

To troubleshoot the issue i create a vlan interface called “vlan15” in the bridge on CRS317 and make a dhcp client on that interface “vlan15” and it works and I even create a static IP from vlan15 interface in the bridge and WAN14 interface with vlan-id 15 in CCR2116 and they work in L3, I hope someone could lend their set of eyes please thank you!

I don’t think this is bug but more of a configuration issue, If this turn out to be a bug then this is very painful because this is common scenario than happen on a daily basis

image
image1171Ă—584 38.9 KB

EDIT: I don’t know if this make a difference all port was set to their max L2-MTU for each equipment I even disable jumbo frames and no dice

2

I’m not sure but shouldn’t the syntax of the vlan-ids parameter in the CRS317 bridge VLAN entry be 14,15 instead of 14-15?

3

hmm… I used to that syntax even in ros v6 days… well nice catch if that is the culprit thanks will revert to this post whatever happen

4 
/interface bridge vlan
add bridge=DISTRIBUTION tagged=TRUNK-TO-WANSW,sfp-sfpplus5 vlan-ids=\
    14,15,16,17,18,19

I change that to this still no joy :slight_smile:

5

Interesting.

On crs354: vlans 14 and 15 exist, ports with the correct native vlan? Macs are seen in the correct vlans?

On crs317: vlans 14 and 15 exist? Macs are seen in the correct vlans?

6

Yes both vlan14 and 15 exist in both switches 354 and 317 I was able to obtain IP in CCR2116 on VLAN14 = WAN13 but not on VLAN15 = WAN14

all device in question is v7.17.2

7

I was thinking about the 14-15 vs 14,15 also, but the documentation is clear that both are valid.

I assume the CRS354 has the correct bridge port PVID and VLAN filtering configuration? The output above doesn’t show.

I would suggest sniffing DHCP on CCR and both CRSes to see how packet exchange looks like and which device is not getting anything back.

8 
[rchan@317] > /interface/bridge/print 
Flags: X - disabled, R - running 
 0 R name="DISTRIBUTION" mtu=auto actual-mtu=10218 l2mtu=10218 arp=enabled 
     arp-timeout=auto mac-address=D4:01:C3:00:F0:FD protocol-mode=rstp 
     fast-forward=yes igmp-snooping=no auto-mac=no admin-mac=D4:01:C3:00:F0:FD 
     ageing-time=5m priority=0x4000 max-message-age=20s forward-delay=15s 
     transmit-hold-count=6 vlan-filtering=yes ether-type=0x8100 pvid=1 
     frame-types=admit-all ingress-filtering=yes dhcp-snooping=yes 
     add-dhcp-option82=yes port-cost-mode=short mvrp=no max-learned-entries=auto 


[rchan@354] > /interface/bridge/print 
Flags: X - disabled, R - running 
 0 R name="DISTRIBUTION" mtu=auto actual-mtu=10218 l2mtu=10218 arp=enabled arp-timeout=auto mac-address=D4:01:C3:25:20:51 protocol-mode=rstp fast-forward=yes 
     igmp-snooping=no auto-mac=no admin-mac=D4:01:C3:25:20:51 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
     vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=yes dhcp-snooping=yes add-dhcp-option82=yes port-cost-mode=long mvrp=no 
     max-learned-entries=auto 
[rchan@354]

Yes vlan-filtering=yes on both switch, thanks for helping re: dhcp exchange message the CCR2116 just sending discover and hears nothing back, in both switch dhcp snooping is turned on but I’m pretty sure that both port ether26 and ether28 on 354 is trusted port as well as the trunk port on both switches, I can confirm as well that both onus is handing off IP address if i plugged directly the ONU to CCR2116 port (ether13 management port for testing purpose)

image
image1193Ă—206 73.9 KB

9

Can you please post /interface/bridge/port/print from CRS354? I just want to make sure ingress traffic for ether26 and 28 gets tagged. The fact you didn’t post this part of configuration initially makes me wonder if this is the missing piece.
It would also help to see the same command output from CRS317.

10

Please see attached, thanks

For CRS354

image

image

For CRS317

image
image994Ă—150 55.9 KB

image

11

Thanks, everything seems to be in order. What about trunk interface on 354 back to 317, is it also trusted?

12

From 354 to 317 hehehe that’s why i’m pulling my hair as well

image

image

13

I’m not an expert by any means but don’t see anything wrong with configuration. I would suggest trying to disable DHCP snooping temporarily as a troubleshooting step just to rule out any potential issues there. Also, maybe play with bridge rules logging action on the switches to see where the response gets dropped to at least narrow down to whether it’s 317 or 354. You already ruled out the CCR and both ISP devices.

Actually, you have the CPU/bridge added to the VLANs (at least on 354), so could sniff packets there.

1 Like
14

Yeah, that’s the plan I just need to consult with the owner first yesterday out of desperation I inadvertently without thinking change something that cause severe downtime and I don’t want to repeat again that rookie mistake, thanks a lot for your great help I also lobby a ticket hoping MT could also look into this

15

I hear you, making changes to production should never be taken lightly. Sniffing though is non-disruptive (disables FastTrack temporarily):

/tool/sniffer/quick ip-protocol=udp port=67,68 mac-address=<CCR WAN14 MAC)

On 354 it would show if DHCP requests are making it thus far and if ONUs respond.
Would be nice to run it also on 317 but requires a change, adding the bridge to the VLAN.

16

Yes I just add bridge to the VLAN on 317 will do some packet sniffing thanks for the tip earlier i check on the bridge host if I learn the MAC properly yeah it’s there, I will post more if I find something substantial

17

Out of curiosity we swap ONU between ether26 and ether28 and it worked WAN14 with vlan15 was able to obtain IP via DHCP which is a good thing but leads to another question of why? hahaha

2
2653Ă—386 80.6 KB

18

try to statically assign an ip address for that vlan interface (it can be put on that vlan interface or client access interface with their respective ip block) - and if that doesn’t work it means you have stp working for the whole switch cluster.

or…

it can be that you need a dhcp relay agent for that vlan interface.

19

Hi wiseroute sorry if I wasn’t able to follow you, you mean I can’t have multiple vlan on an interface and make DHCP on it? I failed to see what it has something to do with STP care to elaborate more on this please?

edit: why do i need a DHCP agent on this case sorry If my mind get blown away hahahah?

20

That is very interesting and really points to one of the ONUs/ISPs doing something funny like restricting by MAC. I think you said you tried both directly to CCR on a management port (one at a time?), could one ONU use sticky MAC? Are these two different ISPs or just two lines from the same ISP? If the same, maybe they don’t allow both connections to be up at the same time?