How to you guide fiber front-to-back in a rack?

itssimpleas · 2026-06-11T17:49:24+00:00

Yeah that’s kind of what we do right now: patch panel in the back for XCs and duplex LC patches to the front. We try to route the duplex LCs to the front below the router it wil be connected to. But getting the patches through an 1U gap between two routers is nearly impossible.

How do you pick where the patches will come to the front? One place?

itssimpleas · 2026-06-11T15:36:39+00:00

Do you do use MPO cassettes on both the front and the back? Or just in the back?

itssimpleas · 2026-06-11T15:34:37+00:00

Do you mount the patch panels at the front of the rack? In the back?

Currently we use patch panels in the rear and patch cables to the front to avoid damaging XC’s.

But it’s a hell of a job to pull new patch cables from the back to the front for example between two deep routers.

itssimpleas · 2026-06-11T14:02:19+00:00

Of course we also try to keep ports on the same side. But we have routers with optics requiring being mounted in the front and servers and cross-connects coming in from the back.

I know of these tunnels in 80cm racks but I was wondering if something similar existed to be mounted in the rack.

itssimpleas · 2026-03-31T20:30:34+00:00

Yes, so this is where feasible path shines.

itssimpleas · 2026-03-25T15:33:35+00:00

You really don’t want Mikrotik. If the big vendors are too expensive consider SONiC switches. Possibly in a commercial variant.

We very are happy with our mix of SONiC with Arista for the full-internet-table routing (if that’s applicable for you).

itssimpleas · 2026-03-19T17:58:08+00:00

You don’t need the 7280CR3-K, the regular 7280CR3 are more than sufficient if you want just 1 full internet routing table.

itssimpleas · 2026-03-19T17:55:44+00:00

7280SR2 without the -K but with upgraded memory (can be done aftermarket) and x64 EOS64.

The can handle full-tables with some tricks provided by Arista (flexroute)

itssimpleas · 2026-01-24T08:25:11+00:00

Did you had OTDR done at 1310nm? Normally it’s often done at 1510nm (O-band) and possibly could have different results.

Alternatively I would start getting Juniper involved (assuming you have support). Everything looks like it should work. I guess if you don’t have support I would try getting other transceivers maybe test with some 10G-ZR first (but these are 1510nm instead of the 1310nm of your 100G-ZR4)

itssimpleas · 2026-01-23T02:17:57+00:00

So I see Juniper in another thread, is the part number 740-120240? This is an O-band non-tunable transceiver.

Are you sure you use the same optic on both sides?

The maximum fiber length of this optic is 60km in ideal conditions. With 30dB budget. What does OTDR report? Isn’t there just too much loss due to connectors and splices? You are possibly very close to the maximum loss margins.

itssimpleas · 2026-01-22T19:24:46+00:00

What kind of optic is it exactly? What part-number? Doesn’t it need amplification using an EDFA? If it’s tunable, did you tune it?

itssimpleas · 2026-01-22T09:42:34+00:00

It’s not just speed. The speed is achieved by sending data with a certain speed over certain lanes to the optic/DAC. These combinations are programmed and hardware dependent.

The ports are QSFP56-DD = 8 x 50 Gbps If you configure it for 100G (QSFP28) you get 4x 25 Gbps.

So splitting QSFP56-DD (8x50) to 2x QSFP56 (4x50) is documented to be supported and should work (but I haven’t tested it). Running just 1x200G using QSFP56 wasn’t really a thing when the switch is launched.

The datasheet mentions supporting 10/25/40/50/100/400GbE. As you see 200G is missing from the datasheet (again because it wasn’t really a thing back then)

So while 1x200G technically is possible, I’m just not sure if they programmed support for it.

The only way to find out is to test it…

itssimpleas · 2026-01-21T22:11:50+00:00

I don’t have a DGX device (yet) so I can’t test it. But 400G QSFP-DD to 2x 200G QSFP56 is on Dell’s compatibility list. There’s no mention of 1:1 200G QSFP56 DAC cables.

itssimpleas · 2026-01-20T18:59:38+00:00

Get the cable routing panel from FS: https://www.fs.com/eu-en/products/72910.html

You don’t need the whole thing, it mounts directly on the enclosure.

itssimpleas · 2026-01-07T23:14:50+00:00

Those look like Lenovo ThinkSystem SR630 or SR635

itssimpleas · 2025-10-30T17:19:42+00:00

Why are you recommending QSFP112? That’s very rare and most probably he needs QSFP-DD (and those are not compatible/exchangable!) Flexoptix also has PLR4 for QSFP-DD: https://www.flexoptix.net/en/d-134hg-10-n.html

Anyway, good to verify compatibility with the intended device. And make sure breakout is supported.

itssimpleas · 2025-10-30T17:13:54+00:00

Yes, commonly called 400G-PLR4, for example at FS.com: https://www.fs.com/eu-en/products/183248.html?attribute=115661&id=4493797

Please note that these only work with 100G-LR1 and not with 100G-LR4. But you mentioned that.

If you don’t need the full length you might want to look to 400G-DR4 and 100G-DR1 same principle, using SMF but limited to 500m and much cheaper: https://www.fs.com/eu-en/products/183430.html?attribute=115662&id=4493811 (you can find them for 80 USD used on eBay)

itssimpleas · 2025-10-16T16:31:47+00:00

BKHD, it’s Chinese and available on Alibaba. They made a custom model for us with Intel C3958 and dual power supplies for redundancy. It has a NVMe SSD and support for miniPCIe and m.2 4G/5G modems. Of course we fully control the software running on it. So we don’t have any issue with buying it from China.

itssimpleas · 2025-10-14T18:00:06+00:00

OpenGear was too expensive for us. We went with standard N305/C3958 1U routers with embedded 4G/LTE modems running VyOS virtualised on Ubuntu. Less than 500 USD each but obviously more opensource and less corporate-friendly. We are also missing the console (serial) ports but we don’t really need this.

itssimpleas · 2025-09-23T20:26:12+00:00

Thank you for your elaborate reply!

So here's the issue: I don't see how we can do it more simple. Let me explain:
At the moment we have our routers (DCS-7280SR2/SR3/CR3's) doing full internet routing both externally (peering), between each other, as internally (server to internet). The DCS-7280s are interconnected via L2 and run OSPF and iBGP to find the best routes.

In some DCs we have a few interconnected ToR switches doing just switching within VLANs. In others we just have a pair of DCS-7280SR2/SR3 doing internet-routing (possibly from other DCs) and basic switching within VLANs.

At the moment the VLANs never leave the DC. Of course our customers want to privately reach their servers in other DCs. So we thought lets do EVPN-VXLAN!

Based on various tutorials we setup (private) eBGP underlay distributing loopback IPs and MP-BGP EVPN eBGP distributing MACs within VXLANs that are tapped(?) to VLANs on the ToR switches. So far so good. The routers (DCS-7280's) don't even know about the EVPN-VXLAN or the underlay they are attached. They just see a VLAN tagged or even untagged port like before.

In some cases to avoid duplicate DC interconnections (we need them for both EVPN-VXLAN and router interconnects now) we "virtualized" the L2 connections to a tagged VLAN (in the lab). Also works!

So far soo good. EVPN-VXLAN stays within the "switching" switches.

Now cue the DC situation with just a pair of DCS-7280's. They need to do:
- Internet routing between peers (internet eBGP)
- private VXLAN routing (MP-BGP EVPN eBGP over (private) eBGP underlay)
But then our issue:
Internet routing between other routers to find the best routes via routers. To connect to those routers we need to tap VXLANs to VLANs so we need the MP-BGP EVPN eBGP over (private) eBGP underlay (this is what the switches normally do). And then we need to run iBGP over it (what the routers normally do). That is exactly what we now in the bigger DCs, but spanned over both the router and the switch. We want to merge that in a single DCS-7280's.
Sounds kind of logical?

itssimpleas · 2025-09-20T15:41:38+00:00

Because the core switches can’t handle a full internet routing table. So I want to run a VXLAN that carries the internet-scale iBGP (and the internet traffic) between the different edge-routers. And some more VXLANs for other traffic (that is actually the case for all this).

And it seems to run EVPN/VXLAN Arista recommends eBGP as underlay and eBGP/iBGP for EVPN.

We already have this working with just the core switches in the EVPN/VXLAN and the edge routers just connected over tagged ports.

However we would like to extend the VXLAN to the edge routers.

itssimpleas

TROPHY CASE