Im not sure if this is a hardware or software issue, however we are attempting to replace on of our CCR1036 routers with a CCR2004 for various reasons.
The existing CCR1036 (ROS6) has 2 10G interfaces, it has 2x 2Gbps fibre services that terminate back to a CCR1072(ROS6) at a DC, these 2 services are delivered as untagged services on the CCR1036 side, but on the DC site CCR1072 the service is tagged.
Now for whatever reason I can not get VPLS to establish on the CCR2004(ROS7.15.x) via these Tagged/Untagged interfaces, it has worked this way for years on the CCR1036 running (ROS6).
In a “test” environment though I can get the CCR2004 to connect to the CCR1072 via VPLS and other older CCR1xxx routers but all directly on the interface and not via the Tagged / Untagged scenario
The basics of the config are as follows
CCR1072 - Provider Tagged VLAN - /30 IP WAN range to Untagged / Native CCR1036 (both interfaces)
OSPF Configured and running between both the CCR1072 and CCR1036
MPLS configured with loopback /32 addresses on both sides
VPLS configured to peer loopback addresses (CCR1072 to CCR1036)
This does not work when connecting to the CCR2004
I can however do this,
CCR1072 /30 IP WAN range to Untagged / Native CCR2004 (both interfaces)
OSPF Configured and running between both the CCR1072 and CCR2004
MPLS configured with loopback /32 addresses on both sides
VPLS configured to peer loopback addresses (CCR1072 to CCR2004)
So far the only difference seems to be that something is happening related to the tag / untagged interface on the Provider Fibre,
the 2 2Gbps services are provided via different providers too so it does not seem to be anything common to the provider.
Any suggestions, insights or possible known bugs that may assist here?
I have seen such a behavior (default LAN traffic being tagged as VLAN 1) if the bridge of that port has VLAN filtering enabled…
After disabling it, they appear as untagged. At least this is how I remember it… (ROS 7.15.2 on CCR2116).
I have found a similar problem when trying to mix tagged and untagged VLANs on RB5009 running v7.15.2.
Here are what I believe to be the relevant parts of the configuration.
[eriks@QCYCrtr-RC5.CLUB] > /interface/vlan/export
# 2024-07-10 14:38:15 by RouterOS 7.15.2
# software id =
#
# model = RB5009UPr+S+
# serial number =
/interface vlan
add interface=backbone-bridge name=ACCESS_vlan vlan-id=10
add interface=backbone-bridge name=CATERING_vlan vlan-id=120
add interface=backbone-bridge name=MGMT_vlan vlan-id=160
add interface=backbone-bridge name=OFFICE_vlan vlan-id=180
[eriks@QCYCrtr-RC5.CLUB] > /interface/bridge/export
# 2024-07-10 14:38:19 by RouterOS 7.15.2
# software id =
#
# model = RB5009UPr+S+
# serial number =
/interface bridge
add fast-forward=no mtu=1500 name=backbone-bridge priority=0x1000
/interface bridge port
add bridge=backbone-bridge interface=e2-south-trunk-lagoon
add bridge=backbone-bridge interface=e7-north-trunk-gh-lts
add bridge=backbone-bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=no interface=e6-interim-mgmt pvid=160
add bridge=backbone-bridge interface=MGMT_vlan pvid=160
add bridge=backbone-bridge frame-types=admit-only-untagged-and-priority-tagged interface=e4-club-mgr-phone pvid=180
/interface bridge vlan
add bridge=backbone-bridge tagged=backbone-bridge,e2-south-trunk-lagoon,e7-north-trunk-gh-lts,e8-INTERNALrtr-trunk untagged=e4-club-mgr-phone,e6-interim-mgmt vlan-ids=10,160,180
[eriks@QCYCrtr-RC5.CLUB] > /ip/address/export
# 2024-07-10 14:38:30 by RouterOS 7.15.2
# software id =
#
# model = RB5009UPr+S+
# serial number =
/ip address
add address=192.168.128.1/21 comment="Access Network" interface=ACCESS_vlan network=192.168.128.0
add address=192.168.8.1/24 comment="Office Network" interface=OFFICE_vlan network=192.168.8.0
add address=192.168.88.254/24 interface=MGMT_vlan network=192.168.88.0
[eriks@QCYCrtr-RC5.CLUB] >
A test workstation connected to e4-club-mgr-phone is unable to obtain a DHCP lease. When it is manually configured with an address on 192.168.8.0/24 it is unable to ARP for its default gateway (192.168.8.1). Switch-based port mirroring of e4-club-mgr-phone to Wireshark on an unused port confirms that the ARP packets are being sent from the workstation (using Ethernet II framing).
/tool/sniffer/start interface=e4-club-mgr-phone on the RB5009 shows the packets arriving. However, it seems that they never make it to the IP stack of the RF5009.
/interface/bridge/host print confirms that the correct MAC address of the test working is being received on interface e4-club-mgr-phone.
Why is the ARP request never making it back to the ARP server of Office_vlan?