Wednesday, December 14. 2011
STM-1 link with MiRICi-155 Gigabit Ethernet over STM-1 SFP Converter
by Lino Moragon
Some time ago we were given a bundle of two new MiRICi-155, Gigabit Ethernet over STM-1/OC-3 SFP Converter as test equipment.
The goal was to simulate a SDH link with STM-1 framing with a maximum bandwidth of 155 Mbit/s.
In order to get the MiRICi SFPs to operate functional, it is essential to disable Autonegotiation on the SFP Interface, as well as setting Speed to 1000 and Duplex to Full. For Cisco devices it is also necessary to input the following commands, because otherwise the devices would reject the SFPs and error disabling the port:
The interface will also show connected state, even if there isn't any optical cable plugged in.
For the SMT-1 configuration, you won't have any specific configuration options on the switch, such as encapsulation, framing type, etc..
On the other hand you can configure a lot of options on the MiRICi itself with a special USB SFP configuration adapter from the manufacturer RAD (www.rad.com). The settings will be saved on the SFP.
In the first attempt we used a Cisco 3560G switch with a MiRICi plugged into the SFP Slot and on the opposite side we used a Cisco 7301 with a PA-POS-OC3SMI port adapter.
After some testing and troubleshooting we came to conclusion that it isn't possible to create a layer 2 link between these two SDH components. The PA-POS-OC3SMI supports hdlc, ppp and frame-relay encapsulation, whereas the MiRICi SFP only GFP encapsulation.
For our second test we exchanged the PA-POS-OC3SMI with another MiRICi so to create a STM-1 link between the two SFPs. The link came up without any troubles and we could perform some iperf speedtests. The results were about 142 Mbit/s.
All in all it seems the MiRICis are working well in a lot of devices as they support the multi-source agreement (MSA) product identification codes. But you only can use them together with another GFP encapsulation compatible product. For a full list of features and more information, take a look at the manufacturer page: www.rad.com
Some time ago we were given a bundle of two new MiRICi-155, Gigabit Ethernet over STM-1/OC-3 SFP Converter as test equipment.
The goal was to simulate a SDH link with STM-1 framing with a maximum bandwidth of 155 Mbit/s.
In order to get the MiRICi SFPs to operate functional, it is essential to disable Autonegotiation on the SFP Interface, as well as setting Speed to 1000 and Duplex to Full. For Cisco devices it is also necessary to input the following commands, because otherwise the devices would reject the SFPs and error disabling the port:
Switch(config)#service unsupported-transceiverAfter these steps, the interface will still be shown as unsupported, but it won't go to “err-disabled” state when plugging in.
Switch(config)#no errdisable detect cause gbic-invalid
Switch(config-int)#speed 1000
Switch(config-int)#no negotiation auto
The interface will also show connected state, even if there isn't any optical cable plugged in.
For the SMT-1 configuration, you won't have any specific configuration options on the switch, such as encapsulation, framing type, etc..
On the other hand you can configure a lot of options on the MiRICi itself with a special USB SFP configuration adapter from the manufacturer RAD (www.rad.com). The settings will be saved on the SFP.
In the first attempt we used a Cisco 3560G switch with a MiRICi plugged into the SFP Slot and on the opposite side we used a Cisco 7301 with a PA-POS-OC3SMI port adapter.
After some testing and troubleshooting we came to conclusion that it isn't possible to create a layer 2 link between these two SDH components. The PA-POS-OC3SMI supports hdlc, ppp and frame-relay encapsulation, whereas the MiRICi SFP only GFP encapsulation.
For our second test we exchanged the PA-POS-OC3SMI with another MiRICi so to create a STM-1 link between the two SFPs. The link came up without any troubles and we could perform some iperf speedtests. The results were about 142 Mbit/s.
All in all it seems the MiRICis are working well in a lot of devices as they support the multi-source agreement (MSA) product identification codes. But you only can use them together with another GFP encapsulation compatible product. For a full list of features and more information, take a look at the manufacturer page: www.rad.com
Friday, June 18. 2010
10Gig interconnect between Brocade and Juniper - phy-mode 28k
by Fredy Künzler
This blog has nearly been abandoned - sorry about that. Time is running, and spare time is very limited...
Anyway, yesterday I came across a nasty issue which seems not to be documented anywhere in the web, and therefore I thought to make a note here for further reference, maybe it's helpful for someone.
We (Init7, AS13030) were about to bring up a new 10gig interconnect with a peer. They happen to run Juniper gear, while we operate Broacade / Foundry XMR routers. The cable was plugged, the light was on, rx and tx values good. The Juniper showed the port up, IP address was pingable, but the port on the Brocade router remained down. We already thought about a broken interface, before I started to play with the phy-mode parameter.
The Juniper can do only WAN-phy and LAN-phy (I don't have Juniper experience though), but the Brocade has three modes. It offers LAN-phy by default (to revert back to LAN-phy, use the 'no' parameter), WAN-phy and a mode called "28k":
My config looks now like this (anonymised and abridged):
This blog has nearly been abandoned - sorry about that. Time is running, and spare time is very limited...
Anyway, yesterday I came across a nasty issue which seems not to be documented anywhere in the web, and therefore I thought to make a note here for further reference, maybe it's helpful for someone.
We (Init7, AS13030) were about to bring up a new 10gig interconnect with a peer. They happen to run Juniper gear, while we operate Broacade / Foundry XMR routers. The cable was plugged, the light was on, rx and tx values good. The Juniper showed the port up, IP address was pingable, but the port on the Brocade router remained down. We already thought about a broken interface, before I started to play with the phy-mode parameter.
The Juniper can do only WAN-phy and LAN-phy (I don't have Juniper experience though), but the Brocade has three modes. It offers LAN-phy by default (to revert back to LAN-phy, use the 'no' parameter), WAN-phy and a mode called "28k":
(config-if-e10000-4/3)#phy-mode ?It was worth a try, and after setting phy-mode to 28k, the interface on the Brocade came up immediately. I don't know whether there is any drawback, traffic is now flowing normal... (WAN-phy mode has less capacity than LAN-phy, though).
28k Bay 28000
wan 10G WAN PHY mode
My config looks now like this (anonymised and abridged):
#sh run int eth 4/3
interface ethernet 4/3
port-name Foo-Bar
enable
route-only
ip address x.x.x.x/30
phy-mode 28k
!
Wednesday, July 16. 2008
Threats to the Internet Routing and Global Connectivity
on blogg.ch (German, based on an English document): Threats to the Internet Routing and Global Connectivity
Tuesday, July 15. 2008
Sweden is monitoring IP traffic from / to Russia
on blogg.ch (German): Schweden überwacht russischen IP Verkehr
Thursday, July 10. 2008
BOGONs should be updated every now and then ...
by Fredy Künzler
We recently received an email saying
In the past few month these blocks should have become routable:
I know that BOGON filtering could be automated, but we never found the time to get it done properly, and, as the available IPv4 space is running out, the Bogon Route Server Project will become obsolete anytime soon.
We recently received an email saying
Please remove 174.0.0.0/8 from your bogon filter...and indeed, as time flies by, we had an outdated BOGON filter list implemented. IANA keeps allocating /8 to RIRs and if network administrators don't pay attention, parts of the internet could silently become unreachable.
In the past few month these blocks should have become routable:
112.0.0.0/8Therefore it's probably wise to check if you see any more specifics of these prefixes (on Cisco / Foundry / Quagga type "sh ip bgp 113.0.0.0/8 longer").
113.0.0.0/8
114.0.0.0/8
115.0.0.0/8
173.0.0.0/8
174.0.0.0/8
186.0.0.0/8
187.0.0.0/8
I know that BOGON filtering could be automated, but we never found the time to get it done properly, and, as the available IPv4 space is running out, the Bogon Route Server Project will become obsolete anytime soon.