MikroTik

Dear Mikrotik,

We became very enthousiast when reading the Newsletter #74, since it included the announcement of the CRS317-1G-16S+RM.
We currently use multiple CCR1072's in the core of our network to 'aggregate' all the sites using 10Gbit links, all sites (buildings) are connected using CCR1016-12S-1S+ routers.

But! I do have one question, the specs tell that the CRS317-1G-16S+RM will support RouterOS, but what about 'wire-speed' / 'in hardware' / 'fast-path' features, will this device support MPLS at 'wire-speed'?

With kind regards,
Kasper Schoonman
OpenFiber

There is no need for MPLS support to forward MPLS packets over the switch, so yes MPLS packets can be forwarded at wire speed.
If you want to do MPLS label switching on this device, then no since it is software only feature.

mrz can you tell us what cpu is inside? Is there wirespeed L3 performance over a ASIC or like before?

mrz can you tell us what cpu is inside? Is there wirespeed L3 performance over a ASIC or like before?

Most likely like last time. But SwOS bootable too. So, we can set this as normal L2 Switch without RouterOS interference.

Do you really want to use SwOS? No SNMPv2/3, no STP, no CLI, ...

Mrz. I really gotta hand it to you. You are an enormous moron. I really wonder what goes through your head sometimes.

You do realize there is an entire world of cam forwarded mpls switches out there, right?

Your answer is just stupid beyond all belief.

I don't think such an incredibly rude response is going to help anyone here. Maybe take a step back and reread his response.

I believe the response was intended as: 1) MPLS forwarding at wire speed is not a "hardware" issue, forwarding is done already. 2) MPLS Switching is not done at wire speed and requires the MPLS package.

Even if I'm wrong in reading that - being rude and name calling isn't needed, and didn't help bring any details to the subject.

I dont expect MPLS LSR support on a product like this. Feature parity with a HP Procurve Layer3 switch or an Extreme x620 would be fine.

But, If this is anything like the CRS 1 and 2 series I will be pretending it does not exist.

I hope Mikrotik are developing this around real world "use cases" rather than just throwing it out to the market and seeing who buys it.

To clarify the original question. This is just like any other CRS we have made.

There will be wirespeed L2 switching on the CRS317.
There will be no ASIC features, wirespeed L3 routing or MPLS switching. Some features may be added via software updates.

Please don't be rude and read the FAQ.

Thanks for the clarification normis

Do you really want to use SwOS? No SNMPv2/3, no STP, no CLI, ...

Using it, just that SwOS makes RB260 drop within "slightly smarter dumb-switch".

To "Mr. Polite" aka roadracer96,
Since original post did not contain specific use case, two possible scenarios were described when wire speed is possible and when it is not.
It is really hard even to imagine anything rude in my response.
Peace out.

You know damn well what he meant. It had a very specific and obvious question. "Will this device support MPLS at wire speed?.

The answer is no. There is no yes answer. It will forward Ethernet frame at wire speed. It will likely have no concept of what mpls is other than perhaps the ethertype and even then I'd be surprised.

Even trying to sneak a yes into the answer is irresponsible and misleading.

Dear all,

The answer is (now) clear (enough), the device won't support MPLS Label Switching, and this is what I was looking for...
So this new CRS will not be the solution for us, can we expect a new Cloud Core Router device with more than 8 SFP+ ports (or a CRS with label switching support via ASIC) ?
For example a CCR1100-1G-16S+ or even CCR1100-1G-24S+ based on the TILE-Gx100 CPU?
Or probably even a device with (some) QSFP+ ports?

I'm totally not into CPU architectures, but a dual CPU CCR2072-1G-16S+ would be nice / an option for us as well..

As written our current 'core' is build using multiple 'stacked' CCR1072's (the CCR's are interconnected using 10G DAC SFP+), we really like the flexibility, feature richness and affordability of Mikrotik but as a FttH and (Unicast) IPTV ISP we need more 10G ports and probably even some 40G or 100G uplinks in the core, this type of technology is currently being offered by competing companies like Juniper, Brocade and Cisco. I'm very interested if we are the only company being interested in such a device from Mikrotik.

Thanks for the answers.

Kasper

I'm very interested if we are the only company being interested in such a device from Mikrotik.

Thanks for the answers.

Kasper

You are not the only one wishing to buy Mikrotik hardware with more 10g ports and more routing capability. We are also into that. We are a small datacenter looking to push 10G switches TOR (top of the rack), but we need an aggregation switch to interconnect them. We are very excited about this new switch, looking forward in buying it!

LACP support?

LACP support?

As far as I know, all Routerboards perform LACP on CPU. So no Mikrotik device can provide wirespeed LACP, for instance, 20gbit/s passing through two aggregated 10G SPF+ ports. Gentlemen, am I correct about this or am I missing something?

We are working on LACP support and also on accelerated routing and MPLS (including for this product). But since it is not ready yet, I did not want to make early promises.

Hello,

How deep are the buffers on this switch? Is there a per-port, an aggregate shared, or both?
Also, how many forwarding rules are supported in the switch ASIC.
Finally, are there dual power supply options?

I realise these questions are not strictly related to the topic but they lend towards the high stability requirements of a transit LSR

Thanks
Tim

Hi,

Finally, are there dual power supply options?

Picture shown in original post showed two LEDs with PSU1 and PSU2 next to them. That'll be a definitive yes.


Grüße,
Philip

We are working on LACP support and also on accelerated routing and MPLS (including for this product). But since it is not ready yet, I did not want to make early promises.

Forgive me Normis but....what does "accelerated routing and MPLS" mean. Fast path?

Or something other than Fast path? Is this for the CRS317 or is this something larger than this specific device?

It is for this device. The CPU has features that allow it. I can't say more at the moment.

You have now gained.....our interest. Very closely.

I know this might be too close of a probing question but, is release of this box to the public contingent on those features? Or will those be added after release?

I was already planning on buying one for the use of switching....but if what you're saying is true then I would be very interested in using it as a router as well.

Thank you Normis.

Thanks for the teaser Normis.

My interest in this device has doubled!

Hopefully it has MPLS push/pop in hardware and not just label switching.

Thanks for the teaser Normis.

My interest in this device has doubled!

Hopefully it has MPLS push/pop in hardware and not just label switching.

And it will probably support Fast Reroute, EVPN, L3 VPN for IPv6, and every MPLS feature you could ever want.....

BUT.....

Not until v7

Sorry couldn't help myself

And it will probably support Fast Reroute, EVPN, L3 VPN for IPv6, and every MPLS feature you could ever want.....

BUT.....

Not until v7

Unicorns Loading....

I actually have a few questions on this.

So it seems from the looks of it on the back we see a heatsink. Does that mean that this switch will be fully fanless? Or will it have a fan on the inside?

How deep is it expected to be? About the same footprint as a current CCR?

Is there an expected CPU that Mikrotik is looking to put on there? MIPSBE? TILE? PPC? MMIPS?

How much RAM is the target goal?

Is it just one big switching chip? Is there a name to the switch chip? Is it a Broadcom device? Is this similar to the UBNT 16 10 gig switch (I'm guessing likely)?

Is this device going to support ROS 6 or will it come in ROS 7 only?

So it seems from the looks of it on the back we see a heatsink. Does that mean that this switch will be fully fanless? Or will it have a fan on the inside?

I think this heatsink looks exactly the same as one in CCR1009-PC so my blind guess is that it's passive because this heatsink internally looks like that:


I think CPU power should be "proportional" considering 10G to 400mhz MIPS in current 1G CSR so maybe this heatsing is used by CPU. However it might be just used for cooling switch chips, hard to tell. However I'm pretty certain it's passively cooled.

Cut-Through would be great

It is for this device. The CPU has features that allow it. I can't say more at the moment.

That's the ASIC I guess: Marvell Prestera 98DX8216
https://www.marvell.com/switching/prestera-dx/

"Support for the newest Tag formats (VXLAN, NVGRE, Geneve) and congestion management capabilities (PFC, ETS)"

I'd have another scenario for that switch: EoIP support (without encryption) for interconnecting two VMware cluster over IP. So a 10Git/s single stream EoIP tunnel. I don't know, whether EoIP could be offloaded by that ASIC, though.

The system runs silently, but there are two fans for situations where ambient temperature gets close to maximum. They will run automatically and only when it gets too hot.

The system runs silently, but there are two fans for situations where ambient temperature gets close to maximum. They will run automatically and only when it gets too hot.

Very nice! Would love if this mechanic could be added to the other CSS/CRS RM models as well.

The system runs silently, but there are two fans for situations where ambient temperature gets close to maximum. They will run automatically and only when it gets too hot.

Very nice! Would love if this mechanic could be added to the other CSS/CRS RM models as well.

I agree it's incredibly awesome feature enabling those machines to be placed around other people, not only in dedicated, isolated server rooms which are not always available. I wish more enterprise hardware would be able to run passively/actively on demand. As security system integrator I usually work with rackmount network devices on desk for initial config. Loud blowers are really annoying - not only for me but also for co-workers who atm write documentation or do other stuff that requires them to focus. In the end we connect device and 1 laptop and itgenerates so much noise as if it's processing traffic of 100 000 workstations lol...

So .. I got landed with a batch of 3 of these .... and so far, VLans can't be configured in RouterOS/Winbox at all. Nevermind MPLS etc.

Looks like the hardware hit the market before the software was ready.

/M

So .. I got landed with a batch of 3 of these .... and so far, VLans can't be configured in RouterOS/Winbox at all. Nevermind MPLS etc.

Looks like the hardware hit the market before the software was ready.

/M

Welp... I guess you can say then that you use the only unmanaged full 10G switch in the market xD

So .. I got landed with a batch of 3 of these .... and so far, VLans can't be configured in RouterOS/Winbox at all. Nevermind MPLS etc.

Looks like the hardware hit the market before the software was ready.

/M

Try out the latest release candidate version. It contains the latest bridge implementation with Winbox support and MPLS HW offloading.

Try out the latest release candidate version. It contains the latests bridge implementation with Winbox support and MPLS HW offloading.

That doesn't fix the issue with the lack of being able to configure VLans though.

/M

So with the 6.41rc releases Mikrotik have added "MPLS Forwarding" to the CRS317.

In my opinion just being able to forward MPLS packets based on the label is pointless. It wont make me buy the CRS317 over any other plain Layer2 switch.

The MPLS features that would make me buy a CRS317 over another device are:

VPLS (PW) encap/decap
Description:
Tunnels are configured via RouterOS, BGP/RSVP/LDP running on the Control Plane provide signalling, the Control Plane then configures the Data Plane to push/pop labels for this tunnel in hardware.

Use Cases:
Data Centre Interconnect - VPLS will be able to be used to "backhaul" Layer2 traffic between data centres.

(w)ISP Backhaul - CRS3xx installed at remote POP can encapsulate traffic from AP's inside VPLS and backhaul it to a central PPPoE/IPoE concentrator.

Layer 2 VPN Services - CRS3xx can encapsulate all traffic from a port into a VPLS tunnel at customer Site-A and then decapsulate it at customer Site-B allowing ISP's to offer "value added" services.


L3VPN forwarding in Hardware
Description:
VRF's are configured via RouterOS and RD/RT settings configured. RouterOS signals these in the control plane using BGP to other routers. RouterOS Control Plane updates the Data Plane (FIB) to forward VRF packets in HW and to push/pop labels to remote locations.

Use Cases:
Customer VPN's - (w)ISP's can offer MPLS VPN services to their customers and deliver them using Mikrotik CRS3xx devices at site. The CRS3xx device can host multiple VRF's e.g. Customer-WAN, Customer-DMZ, Internet to provide L3 services to the customer, each with different routing tables (hence security boundries)

FYI these features are currently available on the Brocade CER/CES, Extreme Networks x460/x670, Juniper QFX/ACX, Nokia 7210 SAS series. Having these features available on the CRS3xx would provide Mikrotik a competitive advantage over the guys just selling L2/L3 switches, especially at the price point Mikrotik have.

That doesn't fix the issue with the lack of being able to configure VLans though.

/M

What exactly are you missing? Vlan configuration in the latest release candidate version is moved to Bridge section.

https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering
https://wiki.mikrotik.com/wiki/Manual:S ... Offloading

I created a ticket to support on friday and have yet not received an answer on this.

And yes, it's to configure untagged and tagged ports on the 317. Will have a look at that there.

/M

We have responded to your ticket on Monday. Are you sure you have not received a response? Can you check the spam folder?

We have responded to your ticket on Monday. Are you sure you have not received a response? Can you check the spam folder?

Hi Emils,
I don't know, how that email escaped me. Found it now. Thanks for pointing it out.

/M

Data Centre Interconnect - VPLS will be able to be used to "backhaul" Layer2 traffic between data centres.
.

I´m dreaming of "Ethernet Over IP" (EoIP) with hardware acceleration on CRS317, .i.e. 10Gbit/s EoIP tunnels for Vmware VMotion (layer 2 interconnect). Would this be possible with the CRS317?

I´m dreaming of "Ethernet Over IP" (EoIP) with hardware acceleration on CRS317, .i.e. 10Gbit/s EoIP tunnels for Vmware VMotion (layer 2 interconnect). Would this be possible with the CRS317?

+1

But I doubt that it's ethernet over IP and IP is pretty much router stuff.

Data Centre Interconnect - VPLS will be able to be used to "backhaul" Layer2 traffic between data centres.
.

I´m dreaming of "Ethernet Over IP" (EoIP) with hardware acceleration on CRS317, .i.e. 10Gbit/s EoIP tunnels for Vmware VMotion (layer 2 interconnect). Would this be possible with the CRS317?

If anything I think you will see VXLAN tunnel support, as this is supported by the ASIC used in the CRS317.

So with the 6.41rc releases Mikrotik have added "MPLS Forwarding" to the CRS317.

In my opinion just being able to forward MPLS packets based on the label is pointless. It wont make me buy the CRS317 over any other plain Layer2 switch.

The MPLS features that would make me buy a CRS317 over another device are:

VPLS (PW) encap/decap
Description:
Tunnels are configured via RouterOS, BGP/RSVP/LDP running on the Control Plane provide signalling, the Control Plane then configures the Data Plane to push/pop labels for this tunnel in hardware.

Use Cases:
Data Centre Interconnect - VPLS will be able to be used to "backhaul" Layer2 traffic between data centres.

(w)ISP Backhaul - CRS3xx installed at remote POP can encapsulate traffic from AP's inside VPLS and backhaul it to a central PPPoE/IPoE concentrator.

Layer 2 VPN Services - CRS3xx can encapsulate all traffic from a port into a VPLS tunnel at customer Site-A and then decapsulate it at customer Site-B allowing ISP's to offer "value added" services.


L3VPN forwarding in Hardware
Description:
VRF's are configured via RouterOS and RD/RT settings configured. RouterOS signals these in the control plane using BGP to other routers. RouterOS Control Plane updates the Data Plane (FIB) to forward VRF packets in HW and to push/pop labels to remote locations.

Use Cases:
Customer VPN's - (w)ISP's can offer MPLS VPN services to their customers and deliver them using Mikrotik CRS3xx devices at site. The CRS3xx device can host multiple VRF's e.g. Customer-WAN, Customer-DMZ, Internet to provide L3 services to the customer, each with different routing tables (hence security boundries)

FYI these features are currently available on the Brocade CER/CES, Extreme Networks x460/x670, Juniper QFX/ACX, Nokia 7210 SAS series. Having these features available on the CRS3xx would provide Mikrotik a competitive advantage over the guys just selling L2/L3 switches, especially at the price point Mikrotik have.

Agree with you 100%. it's nice to have the hardware forwarding purely as a P router, but the PE functionality is where the magic is

If anything I think you will see VXLAN tunnel support, as this is supported by the ASIC used in the CRS317.

I think Mikrotik doesn´t need VXLAN, as there is EoIP support.

- According to the Marvell Prestera DX homepage: "Support for the newest Tag formats (VXLAN, NVGRE, Geneve) and congestion management capabilities (PFC, ETS)"
- According to Mikrotik´s wiki for EoIP: "Ethernet over IP (EoIP) Tunneling is a MikroTik RouterOS protocol that creates an Ethernet tunnel between two routers on top of an IP connection." "The EoIP protocol encapsulates Ethernet frames in GRE (IP protocol number 47) packets (just like PPTP) and sends them to the remote side of the EoIP tunnel. "
- According to wikipedia: VXLAN: "It uses a VLAN-like encapsulation technique to encapsulate MAC-based OSI layer 2 Ethernet frames within layer 3 UDP packets,"
- According to wikipedia: NVGRE: "Network Virtualization using Generic Routing Encapsulation (NVGRE) is a network virtualization technology that attempts to alleviate the scalability problems associated with large cloud computing deployments. It uses Generic Routing Encapsulation (GRE) to tunnel layer 2 packets over layer 3 networks."

So, hardware support of EoIP might be possible with the CRS317?

I think Mikrotik doesn´t need VXLAN, as there is EoIP support.

I disagree. EoIP is a proprietary Mikrotik protocol. VXLAN (RFC 7348) is the industry standard, with "Fast Path" support across multiple vendors and chipsets, e.g. Broadcom Trident/Tomahawk, Marvell Prestera, Mellanox Spectrum, Intel xl710(i40e).

VXLAN will allow Mikrotik to be used in modern Datacentre networks.

On top of this VXLAN has numerous benefits over EoIP:
- UDP based transport allows for ECMP.
- HW support on many platforms allows VNI based hashing on 802.3ad links.
- Part of the eVPN standard, allowing for multihoming and L2 redundancy.

- According to the Marvell Prestera DX homepage: "Support for the newest Tag formats (VXLAN, NVGRE, Geneve) and congestion management capabilities (PFC, ETS)"
- According to Mikrotik´s wiki for EoIP: "Ethernet over IP (EoIP) Tunneling is a MikroTik RouterOS protocol that creates an Ethernet tunnel between two routers on top of an IP connection." "The EoIP protocol encapsulates Ethernet frames in GRE (IP protocol number 47) packets (just like PPTP) and sends them to the remote side of the EoIP tunnel. "
- According to wikipedia: VXLAN: "It uses a VLAN-like encapsulation technique to encapsulate MAC-based OSI layer 2 Ethernet frames within layer 3 UDP packets,"
- According to wikipedia: NVGRE: "Network Virtualization using Generic Routing Encapsulation (NVGRE) is a network virtualization technology that attempts to alleviate the scalability problems associated with large cloud computing deployments. It uses Generic Routing Encapsulation (GRE) to tunnel layer 2 packets over layer 3 networks."

So, hardware support of EoIP might be possible with the CRS317?

Unlikely. While EoIP is very similar to GRE/NVGRE it is not the same. The Prestera chipset likely only has support for the specific frame/header formats specified by the standards.

Is LACP supported with VLANs on CRS317-1G-16S+RM using the new bridge method?
If so how?

Essentially, trunking VLANs over LACP (hardware based) and then also using the same VLANs for tagging or native on the various SFP+ ports?

Is LACP supported with VLANs on CRS317-1G-16S+RM using the new bridge method?
If so how?

Essentially, trunking VLANs over LACP (hardware based) and then also using the same VLANs for tagging or native on the various SFP+ ports?

LACP is only supported in SwOS atm. I checked with support. Massive bummer.

/M

Sent from my SM-G930F using Tapatalk

Damn.
Haven't tried SW/OS, but does this support VLANs?

We basically are after 10Gb switch, with good VLAN support, LACP, RSTP. Nothing layer 3.

Damn.
Haven't tried SW/OS, but does this support VLANs?

We basically are after 10Gb switch, with good VLAN support, LACP, RSTP. Nothing layer 3.

Both features are supported on CRS317-1G-16S+ :
https://wiki.mikrotik.com/wiki/SwOS/CRS317

Damn.
Haven't tried SW/OS, but does this support VLANs?

We basically are after 10Gb switch, with good VLAN support, LACP, RSTP. Nothing layer 3.

Both features are supported on CRS317-1G-16S+ :
https://wiki.mikrotik.com/wiki/SwOS/CRS317

No Q-in-Q support though in SwOS.

I'm unable to get switchOS to do anything other than boot loop if the SFP+ modules are connected.

RouterOS rarely operates above gigabit speed when I create a bridge from four SFP+ and the gig ethernet port - is including the gig port in the bridge what's slowing me down?

Should I be routing from the gig to the sfp+ and leaving the gig port out of the bridge?

Any suggestions on getting this guy to run switchOS and not bootloop continuously if the SFP+ modules are connected?

There will be wirespeed L2 switching on the CRS317.
There will be no ASIC features, wirespeed L3 routing or MPLS switching. Some features may be added via software updates.

Under-promise, over-deliver. Wirespeed L3 routing is "some feature", alright!:
https://wiki.mikrotik.com/wiki/Manual:C ... Offloading

There will be wirespeed L2 switching on the CRS317.
There will be no ASIC features, wirespeed L3 routing or MPLS switching. Some features may be added via software updates.

Under-promise, over-deliver. Wirespeed L3 routing is "some feature", alright!:
https://wiki.mikrotik.com/wiki/Manual:C ... Offloading

wow

... deleted.

Any progress in this front please or we just keep on dreaming?

After nearly 8 years, I am going to assume:

I'm guessing that Marvell "NDA-licenses" the hardware features, and VXLAN and MPLS is simply to expensive.

But yes, VXLAN/NVGRE with EVPN would have been a killer feature.

When the CRS317 came out we lived in a RouterOS v6 world and given the issues with MPLS in RouterOS v6 it probably was not worth implementing all the Hardware features on a flawed MPLS implementation.

RouterOS v7 MPLS is only really getting to the point where it is usable now, hopefully Mikrotik have not abandoned the idea of Hardware MPLS support, it is sorely needed.

When the CRS317 came out we lived in a RouterOS v6 world and given the issues with MPLS in RouterOS v6 it probably was not worth implementing all the Hardware features on a flawed MPLS implementation.

RouterOS v7 MPLS is only really getting to the point where it is usable now, hopefully Mikrotik have not abandoned the idea of Hardware MPLS support, it is sorely needed.

I really hope so too!

I'd hope for revived MPLS support too here - the hardware spec of those boxes is still quite ok to have as a router at network leaves, yet the supported features are a moving target since the hardware's release.
First we were told MPLS forwarding in hardware, then Layer3 forwarding, but the whole feature-set is kind of a "where is waldo?" experience:

https://help.mikrotik.com/docs/display/ ... ureSupport

VRF routing tables are not offloaded and MPLS forwarding is also gone since ROS v7, basically if one needs simply l3-forwarding it's ok.

imho this is a pitty especially for this device as its chipset has so much more potential - in the meantime we bought a dozen ASRs and some MXs and use MTs as CPEs or switches.

If we need a feature-complete MT we go for the traditional routers having no hw-feature and compensate by cpu-power.