AMS-IX Interface & Cabling Specifications
| Interface type | Cable | Connector | Wavelength | Max. Distance(1) | TX (dBm) | RX (dBm) | |
|---|---|---|---|---|---|---|---|
| 10baseT | UTP-5 | RJ-45 | - | 80 | m | - | - |
| 100baseTX | UTP-5 | RJ-45 | - | 80 | m | - | - |
| 1000baseSX | MM | SC/PC | 850 nm | 200 | m | -9.5 | -17 |
| 1000baseLX(2) | MM | SC/PC | 1310 nm | 280 | m | -9.5…-3.0 | -20…-3.0 |
| 1000baseLX(2) | SM | SC/PC | 1310 nm | 5 | km | -9.5…-3.0 | -20…-3.0 |
| 1000baseLH-A(3) | SM | SC/PC | 1550 nm | 60-80 | km | 0.0…3.0 | -21…-3.0 |
| 1000baseLH-B(3) | SM | SC/PC | 1550 nm | 60-80 | km | 2.5…5.0 | -27…-3.0 |
(1):
This concerns the
“customer cable,” i.e.
the maximum distance between
member equipment and the AMS-IX patch panel.
(2):
Foundry LX ≡ Cisco LH
(3):
Foundry LH ≡ Cisco ZX
10GE specifics
Your 10GE port is connected to a photonic switch, which patches it through to a switch port on an active 10GE Ethernet access switch.
The AMS-IX topology is built around two sets of core switches: one at Global Switch, and another at EUNetworks. Only one set is active at a time. The 10GE Ethernet access switches are locally available at each location and one can connect with either ER or LR optics. Of the two locally connected 10GE access switches one connects to the Telecity core switch and one to the NIKHEF core switch. A photonic switch introduces less than 3 dB of attenuation between the AMS-IX patch panel and the Ethernet access switch.
| Interface type | Cable | Connector | Wavelength | Max. Distance(1) | TX (dBm)(4) | RX (dBm) | |
|---|---|---|---|---|---|---|---|
| 10GE-LR | SM | SC/PC | 1310 nm | < 10 | km | -4.5…0.0 | -13.2…0.5 |
| 10GE-ER | SM | SC/PC | 1550 nm | < 40 | km | -1.0…+2.0 | -16.9…-1.0 |
(1):
This concerns the
“customer cable,” i.e.
the maximum distance between
member equipment and the AMS-IX patch panel.
(4):
As measured at the AMS-IX patch panel.
A switchover between the two topologies introduces a very short link flap (typically < 20 ms). In order to avoid BGP instability, you should configure your router to not act immediately on such events.
- IOS supports
"no bgp fast-external-fallover"
and
event dampening.
The "no bgp fast external-fallover" tells the device to not act immediately on link flaps but wait for the BGP hold timers to expire before resetting sessions. Newer versions of Cisco IOS even support "ip bgp fast-external-fallover deny" in a per-interface context.
The previously advised carrier-delay does not work as expected.
- JunOS supports
a
configurable hold-time. A good value would be 1200 ms.
- Foundry supports a feature called BGP Graceful Restart that, if all peers support it, will reduce the impact of prefix flaps but the CPU will still have to re-establish any flapped BGP session before the configured interval passes. In software version 2.3.00 for RX "delay-link-event" was introduced, which can make the router ignore short link flaps. This command is billed as applying only to VSRP, though; therefore, we suggest to leave "fast-external-fallover" in its default state.
If your router platform does not support such a feature, we advise you to configure the equivalent of "no bgp fast-external-fallover" - i.e., to not act on link flaps but wait for the BGP hold timers to expire before resetting sessions.
In practice we have found that carrier-delay does not always work on Cisco equipment. We suggest you disable fast-external-fallover instead.