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 Global Switch core switch and one to the EUNetworks 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.
- JUNOS supports
a
configurable hold-time. A good value would be 1200 ms.
- 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 in practice not work as expected.
- 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.
- Force10 E-Series' FTOS supports "no bgp fast-external-fallover",
BGP Graceful Restart, and a link
debounce timer to maintain BGP stability during topology switchovers.
The recommended option is to use the "link debounce" command to delay link change notifications on the interface.
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.