Tried posting this in the BGP section of the forum, but got no answer. I’m looking to roll out a Mikrotik CCR2004-16G-2S+ as a new Core router on a business park, but I’m having issues getting it working, and was wondering if anyone could provide some assistance.
Customers on site are each assigned an external IP for their office routers, with the IPs being brought into site via a BGP route from our Tier-1 provider. These IPs are then assigned to various VLANs and carried out across site over various VLANs. When just the LAN connections are plugged in, each end-user on various VLANs can route to each other, ping the gateway, etc. But when I tried to install the router, it shows as connected to the upstream provider, the BGP route is visible via the BGP “sessions” entries, no customer routers are able to get to the internet, or ping the VLAN’s gateway. The ARP table shows very few entries, and those it shows always show as “failed”.
Attached below is the current config of the router.
1.1.74.9 is our Tier1 Partner’s Router
2.1.X.X is the IP range we are distributing to customers on site
2.2.X.X and 2.3.X.X are IPs we rent to other customers via a separate GRE tunnel (2.1.71.133)
There does not look to be enough config for your VLAN’s here. I am trying to find you the page to see the practical implementation for this but it’s eluding me…
Ideally you’d want to use the VLAN bridge filtering so you can purposefully trunk out down each port what you want (or make untagged for dedicated port access) rather than leaving the network wide open so any VLAN can go anywhere.
But as a more general, create yourself a “proper” management port first so you don’t lock yourself out and then recreate your bridge with VLAN filtering enabled and work from there, build the first VLAN and properly mark it on the ports you expect it both tagged and untagged (if any) and then move on to the next. It’s a PITA at first but then it makes sense.
Add this port to the Trusted interface list /interface list
add name=TRUSTED
/interface list members
add interface=vlan-management list=TRUSTED
add interface=OffBridgePortXX list=TRUSTED
Then simply plug in your laptop into port XX, modify the ipv4 settings to 192.168.56.2 and you should have full access.
This is a SAFER spot to play with vlan bridge setups…learned from experience!!
Apologies for the late reply! I think I’ve set the bridge filtering correctly? Do you think this could have been causing the traversal issues described in the first post?
In Mikrotik world, “native” translates to “access port” to that VLAN[*] … and MT default config uses VID=1 as well … but it’s untagged over “cpu-facing bridge port” (see te first link below) as well. By trying to use VLAN 1 as if it was tagged (on CPU-facing bridge port), you’re messing around.
Mikrotik’s implementation of VLANs on bridge is a bit … different than other vendors did. So perhaps you’d want to read these two de-facto bibles:
And I suggest you to read them in indicated order.
[*] native VLAN is actually always transmitted without 802.1Q headers (i.e. untagged) over the link (wire, fiber). Which means that in theory it’s possible to use different VID inside each piece of equipment to deal with it … in practice tough this makes things very confusing. It is perfectly fine to use VID=1 as native VLAN in mikrotik, but one has to be aware of how default config treats VID=1 and change it everywhere. Since it’s default config, it doesn’t get shown by simple /export command (this ocmmand shows only delta to default config), which does make handling of VID=1 quite a bit harder (but not impossible).
Thanks for the info, I’ll give it a read through. On the network its run as a native, untagged VLAN. I assume its not as simple as setting VLAN1 as an untagged port on the bridge, as in the config I linked above?
As I wrote, default config has pvid=1 set on all bridge ports, including cpu-facing bridge port … which means that you should use it as untagged on bridge interface (i.e. don’t create VLAN interface for it). The other possibility is to make cpu-facing bridge port tagged member of VLAN 1 (and then use VLAN interface with VID set to 1 … the way you do now). If you want to stick to VID=1 for management, then I’d go with the second option aboive (use VLAN 1 as tagged inside router), it makes configuration a bit more self-descriptive.
This will probably sound hugely idiotic, but where would I go around changing the cpu-facing bridge port to being a tagged member of VLAN1?
Still trying to get to grips with the eccentricities of Mikrotik VLANs (Much more familiar with Cisco’s implementation, so this is a bit of an adjustment for me)
Read the first article I linked above … it’ll tell you what’s the “cpu-facing bridge port”.
Spolier alert: properties, set on /inteface/bridge items, are mostly about “cpu-facing bridge port” (of the particular bridge), only a few are about “switch-like” entity. Which includes properties like “pvid”. For the rest of bridge port (the “normal ports”) the same properties are set under /interface/bridge/port. Controversally, you configure VLAN membership of “cpu-facing bridge port” in the same place as for the rest of bridge ports (the normal ones) … under /interface/bridge/vlan
Yeah, it’s because ROS VLAN bridging is based on Linux DSA (Distributed Switch Architecture) which can be pretty tricky to grasp because it involves layers of abstraction and specific hardware constraints that don’t fit with “traditional” networking models. Plus, it’s missing decent documentation on the architecture, which doesn’t make things any easier.
I’ve read through the link, and from the best of my understanding, I have VLAN 1 set as tagged on the CPU-facing bridge port? Or am I completely missing something?
Yes, however
/interface bridge
add name=LAN-bridge
includes default settings of pvid=1 and frame-types=admit-all which presents VLAN 1 untagged on the CPU-facing bridge port.
Not that this matters as your bridge also has the default vlan-filtering=no which makes it behave like an unmanaged switch - all port pvid= and frame-types= settings are ignored, as is all of /interface bridge vlan.
From https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-BridgeVLANFiltering “The main VLAN setting is vlan-filtering which globally controls VLAN-awareness and VLAN tag processing in the bridge. If vlan-filtering=no is configured, the bridge ignores VLAN tags, works in a shared-VLAN-learning (SVL) mode, and cannot modify VLAN tags of packets. Turning on vlan-filtering enables all bridge VLAN related functionality and independent-VLAN-learning (IVL) mode. Besides joining the ports for Layer2 forwarding, the bridge itself is also an interface therefore it has Port VLAN ID (pvid).”
If you do not wish to control which VLANs are permitted on individual bridge ports, and you wish the address 172.16.1.254/24 to be associated with untagged traffic on the member ports (sfp1, sfp2 & ether16) the following change should be sufficient:
/ip address
add address=172.16.1.254/24 interface=VLAN1LAN-bridge network=172.16.1.0
Pulled it from the .rsc file of the downloaded config (bearing in mind this was setup via WinBox, if that makes a difference to the config structure)
Assuming this is set up correctly, should this (theoretically) fix the issues in the OP wherin once connected to the BGP upstream router, all ARP entries fail, and inter-VLAN (As well as external) routing fails?
Since the post, I have updated to enable VLAN filtering. As I am simply planning to use the 3 member ports as “mirrors” of the same config, Allowing all VLANs to pass through to the Router, would it be wiser to disable this, and make the change to /ip address you pointed out above?