If you want to skip a lot of the introductory stuff and go directly to the point, just skip to the section marked red.

I realized that one Layer 3 switch does not really support VLAN, so I need another solution to create a virtual LAN.

According to the manual, these limitations will be removed in future firmware versions. The latest firmware is two years old, so no, they wouldn't fix it.

Note: When operating the switch in multilayer mode, all ports should be defined as untagged, and no VLANs can overlap. You should also assign the same default PVID to the ports at both ends of a link if the VLAN must cross the switches. (See “VLAN Tagging” configuration.) These limitations will be removed for future firmware versions.

However, I can change the system mode to Layer 2 and use VLAN. I prefer not to do that, because it may be bottlenecks if I use a router to deal with the traffic.

Right now I'm using EoIP to bridge two networks. That was very easy to configure, and it's working quite well. There is only one problem, the throughput is not what I expected. It seems that EoIP tunnels requires a lot of CPU power, so I either need to replace the hardware or try something else.

What I need is a simple point-to-point Layer 2 bridge (Ethernet over MPLS).

I read that MTU issues can arise if the MPLS backbone cannot support MTUs larger than 1530. Do I need some special hardware (NICs) where I can set L2 MTU to mitigate this issue?

Thanks in advance.

Hi,

MPLS requires at least 8 bytes overhead for the encapsulation, so that would be the minimum required for MPLS to be able to forward 1500 mtu frames.
The higher the MTU, the nastiest things you can do over them tunnels (such as MPLS over MPLS for example).

So far, Miktorik can't do EoMPLS service, but they can do VPLS which is much better, however im not sure about the CPU overhead on the vpls service compared to eoip, but as far as i can tell from the little experience i've had so far, you ought to use some x86 systems to acheive better performance. As far as i can tell, enabling MPLS packet switching adds little or no overhead, actually should decrease the load on the CPU.

In any case, try with mtu 1508 and see how things works, on MT's boxes you can easly change the MTU as most of them support up to 1600 MTU (rb1000 for example), but im sure with Intel NICs you can set even higher (like 9000 bytes jumbo mtu), just make sure the mtu is big enough on all ends, otherwise you will experience problems.

Viorel

Hi,

MPLS requires at least 8 bytes overhead for the encapsulation, so that would be the minimum required for MPLS to be able to forward 1500 mtu frames.

Depends on what you mean by forwarding - single label takes 4 bytes, therefore simplest MPLS forwarding requires as much of additional space as VLAN. Of course, in order to use other MPLS based applications (VPLS, IP VPNs) you need more.

So far, Miktorik can't do EoMPLS service, but they can do VPLS which is much better

It actually can. What is usually understood by EoMPLS (at least by cisco) is simple "pseudowire" that you can use for ethernet forwarding. This is what you get by configuring static LDP signaled VPLS interface in RouterOS. You can even configure pseudowire that is compatible with cisco. VPLS is broader term, but it is still implemented based on those simple "pseudowires" - VPLS in general means a mesh of those pseudowires and also some means for autodisovery. In RouterOS all pseudowires are refferred to as "VPLS interfaces", so that your configuration does not get polluted with interfaces that are actually the same, but are called differently.

, however im not sure about the CPU overhead on the vpls service compared to eoip, but as far as i can tell from the little experience i've had so far, you ought to use some x86 systems to acheive better performance. As far as i can tell, enabling MPLS packet switching adds little or no overhead, actually should decrease the load on the CPU.

Here we should understand that there are actually 2 kinds of devices involved in EoIP (and also VPLS) path - endpoints (which do encap/decap) and "core" routers that do forwarding (routing in EoIP case, MPLS forwarding in VPLS case). For both of these devices using VPLS will reduce overhead - endpoints do not have to do EoIP encapsulation and IP fragmentation, instead - they have to do VPLS encapsulation (and possibly fragmentation). VPLS case definitely has less overhead, one simple reason being the fact, that encapsulation overhead for VPLS is smaller (12 bytes - 8 bytes for labels and 4 bytes for control word, where EoIP adds IP and GRE headers - total of 28 bytes). As to "core" routers - MPLS switching overhead is smaller than regular routing overhead, so MPLS switching is preferred over routing anyway.

As to the original question about 1530 byte MTU - it is preferred to use interfaces which support appropriate L2MTU, so that you can avoid fragmentation at all. But in any case - even if your network does not support L2MTUs that allow to avoid VPLS fragmentation - VPLS will have less overhead than EoIP, and it does not matter what hardware you are using.

Thanks for the answer Mplsguy, now I know that Ethernet over MPLS requres hardware with support for at least 1530 L2 MTU. I find out that some RouterBOARDs does not support more than 1514 to 1526 L2 MTU, and only a few NICs I have seems to support L2 MTU at all. I also figured out that NICs with the same chipset as in RouterBOARD supports L2 MTU.

and only a few NICs I have seems to support L2 MTU at all

not 'L2 MTU', but 'L2 MTU detection' =) it depends on the driver, whether it can give such information to OS

Not detected = Not supported?

http://wiki.mikrotik.com/wiki/Maximum_T ... 2.2FL2_MTU

L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge and VPLS interfaces ..

it means, detection is not supported ))

so, you should just know it

'L2MTU' cannot be just not supported. it would be meaning that nothing can be sent by this interface =)

What I have been wondering about - If i happen to have some x86 box with a gigabit intel chipset network card, which I know supports Jumbo frames, but does not show any L2 MTU Size in ROS...

What L2 MTU does that card actually run at? Stock 1500-something? 9000-something?
I'm thinking about building an x86 based box with intel nics, but not being able to forward full ethernet frames by VPLS without fragmentation would be a deal-breaker.

Basic rule is that cards not showing l2mtu can be considered having l2mtu the same as configured IP MTU (/interface set mtu=x). It is common for cards to actually "run" with l2mtu=IP MTU + 4 (for single VLAN encapsulation) or even a little bigger value. But this can not be safely assumed or taken for granted (the best I can suggest is actually try it out). Taking all this into account, you can implement "big l2mtu" network using cards that support jumbograms (but do not report l2mtu) if you are fine with having large IP MTU at the same time.

Thanks for the info mplsguy!

Can you name any gigabit ethernet cards which report L2 MTU and are supported by ROS 4.2 x86?

Thanks for the info mplsguy!

Can you name any gigabit ethernet cards which report L2 MTU and are supported by ROS 4.2 x86?

I am afraid only gigabit chipsets used on routerboards do report L2 MTU. So I guess the best you can do at this time is increase IP MTU.

One of my PCI Gigabit NICs reports 1600 L2 MTU. I don't know the chipset, but the card is D-Link DGE-528T H/W Ver: A2. I guess it is RealTek 8169S.

One of my PCI Gigabit NICs reports 1600 L2 MTU. I don't know the chipset, but the card is D-Link DGE-528T H/W Ver: A2. I guess it is RealTek 8169S.

Sorry, I misinterpreted hedeles question. It is Intel cards that definitely do not "support" l2mtu. L2 MTU is supported for RTL 8169 and VIA Velocity family chips, that are used in PCI cards (and actually is - e.g. RB44GV cards). If your gigE card happens to use any of these it should have l2mtu.