Category: Hardware

Hardware info

[Solution] Speed / Duplex auto-negotiation fails between Cisco and Tandberg

In the last weeks I was working closely with a Cisco Telepresence team to identify a issue regarding poor performance of the video systems. We did find pretty quickly the issue as being the failure of auto-negotiation of Speed and Duplex on the connection between Cisco switch port and Tandberg endpoint devices.

This was the easy part. We though it will be fixed in minutes, but after a few days we did recognized that there is something we do not understand. We did change the settings everywhere to have auto-negotiation on, but we still had problems. For example with Cisco and Tandberg ports set on auto-negotiation on both sides, I’ve seen the most uncommon results:
– Cisco 1000Mbps – Tandberg 1000Mbps = negotiation 1000Mbps / Full
– Cisco 1000Mbps – Tandberg 100Mbps = negotiation 1000Mbps / Full on Cisco + 100Mbps / Full on Tandberg
– Cisco 100Mbps – Tandberg 100Mbps = negotiation 100Mbps / Half on Cisco + 100Mbps / Full on Tandberg

These are just a few of the strange results that we got. Myself as part of the network team I turn my attention to search bugs in IOS, configuration issues, faulty hardware. The Telepresence team was doing their job to search on their systems. Nothing was working.

We turn our attention to TAC engineers. They did try to simulate in a lab environment our problems, but failed. Their system were not having this kind of issue. Internet, search engines and boards could not help as well. I was about to think that we are somewhere in the Bermuda triangle and we are the only one with this kind of problem.

Then the solution came from a Cisco engineer when we least expect it. I quote from his e-mail in which he gave us some suggestion to try:

Are you aware that Tandberg endpoints running newer versions of software 
need to be rebooted before changes to speed settings take effect? 
This can sometimes cause confusion.

We stopped for a second and ask “Did we reload any Tandberg device during troubleshooting sessions?” The answer was “No”. After reload all devices, one by one, everything was working expect a few devices.

We discovered that these Tandberg devices didn’t want to auto-negotiate because of lack of a Cat6 cabling. It seems that all 8 wires need to be there and connected. So, if you have a cable that is patched to transport data and telephony for example to spare some wires, then you may be in trouble.

Why did I add this thing here? For sure it will bring some ironic smile on some faces, but I like to learn from my mistakes or from not paying close attention to some small line in the documentation. OK, if I made you laugh it’s fine, but the reason of this article is different. When I did search Internet for possible solution, I could not find anywhere a line with “reload the damn Tandberg device after you modify Speed / Duplex” settings.


Fiber Optic basics

I think all network engineers touched, if not used / patched, as least one time a fiber optic patch cord. As a network engineer you might not necessarily need to understand HOW fiber optic is working. It’s there and it’s working. You just need to plug the patch cord and that that’s it.

Anyway, for interested network engineers (or geeks) like me, to understand how fiber optic works might be a fun way to spend 10 minutes of my life. Of course, to have in-deep knowledge of FO, at the level which allow you to design applications for this transport medium, you need to read a little bit more than the video above.

Disclaimer: This video is not mine and I don’t claim any rights on it. My thanks go to Jimmy Ray Purse, TechWiseTV, Networking 101 Show, Cisco and last but not least to YouTube for hosting it and let us embed this video.


Cisco 2900 – Interface related chassis modification



The Cisco Enhanced EtherSwitch Service Modules seen above, expands the router’s capabilities by integrating Layer 2 and Layer 3 switching feature sets identical to those found in the Cisco Catalyst 3560-E and Catalyst 2960 Series Switches.

The new Cisco Enhanced EtherSwitch Service Modules are the first modules to take advantage of the increased capabilities on the Cisco 3900 and 2900 Series Integrated Services Routers. Additionally, these service modules enable Cisco’s industry-leading power initiatives, Cisco EnergyWise®, Cisco Enhanced Power over Ethernet (ePoE), and per-port PoE power monitoring-all of which enhance the ability of the branch office to scale to next-generation requirements and still meet important initiatives for IT teams to operate a power efficient network.

Furthermore, the Cisco Enhanced EtherSwitch Service Modules not only perform local line-rate switching and routing but also support direct service module-to-service module communication through the Integrated Services Router Generation 2 multigigabit fabric (MGF) which separates LAN traffic from WAN resources.

Below, you have a hands on demonstration how to add, remove or replace a module in the new Cisco 2900 chassis and what to is recommended to do or avoid during this operations. This is nothing new for the engineers that have to change modules everyday in chassis like 6500 or 7600 platform, but may be very useful for the beginners.

Enjoy!

How to use a Cisco router as Frame-Relay switch


For this tutorial you can use  a low cost Cisco router and of course you need some serial interfaces available on this router. I will use a 7206 with 3 serial interfaces. This router I will call R6 and the rest of the three routers connected to R6, will be R2, R5 and R9. In this way it will be easier for you to understand how the frame-relay routing is achieved.

If we have a look to R6’s (the router used as frame-relay switch) interfaces:

r6-c7206#sh int desc
Interface                      Status         Protocol       Description
Fa0/0                            up                down
Fa0/1                             up                down
Se5/0:1                         up                up                    TO_R2
Se5/1:2                         up                up                    TO_R5
Se6/0                            down          down
Se6/1                             up                up                    TO_R9

you’ll notice that we have 3 active serial interfaces, each being connected to one of the three routers R2, R5 and R9.

Very important, before you begin define a scalable range for your DLCI numbers, otherwise you will have a complete mess when troubleshooting is needed. I like to define them after formula Rx0Ry. In the middle you have the number zero. In this idea, we will have something like R20R5 and from this resul the DLCI 205 for the Frame-Relay connection between R2 and R5. Below you have the DLCI numbers used in this tutorial:

R2 -> R5: DLCI 205
R2 -> R9: DLCI 209
R5 -> R2: DLCI 502
R5 -> R9: DLCI 509
R9 -> R2: DLCI 902
R9 -> R5: DLCI 905

Now that we have defined the DLCI numbers lets configure R6 router as frame-relay switch.

First of all, you need to enable frame relay switching on the router:

r6-c7206#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r6-c7206(config)#frame-relay switching

This command enable the switching  of packets based on the data?link connection identifier (DLCI) inside your router.

Next, we have to configure the frame-relay routing on the physical interface. We will start with interface S5/0:1 where R2 router is connected and apply the following configuration

interface Serial5/0:1
description TO_R2
no ip address
encapsulation frame-relay
! the frame-relay switch is the DCE and the other end is the DTE
frame-relay intf-type dce
frame-relay route 205 interface Serial5/1:2 502
frame-relay route 209 interface Serial6/1 902

With frame-relay route command we tell to frame-relay switch where to forward the packets based on the DLCI number. If we take a look to the first frame-relay route command, than the path to DLCI 502 is interface Serial5/1:2. If you feel confuse, please check again above the interface connection to the router and the assigment scheme for DLCI numbers.

The same like for interface S5/0:1, we will configure the interfaces connected to R5 and R9:

interface Serial5/1:2
description TO_R5
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 502 interface Serial5/0:1 205
frame-relay route 509 interface Serial6/1 905

interface Serial6/1
description TO_R9
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 902 interface Serial5/0:1 209
frame-relay route 905 interface Serial5/1:2 509

Having a look to S5/1:2, first frame-relay route command, here we configure the path back from R5 to R2, by telling the frame-relay switch to chose interface S5/0:1 to send packets to DLCI 205 (R2).

This is the basics of how to configure a Cisco router as a frame-relay switch. If you need help, please don’t hesitate to use the comment form below.