Cisco 1800 drops link to ADVA

ciscowan

I'm having a problem getting a Cisco 1841 connected to an ADVA WAN box provided by TWTelecom. They've given me instructions to force the fasteternet0/0 100 full duplex on interface 0/0, which I have done. When I boot the cisco, there is link and activity during boot, then the Cisco port lights black out while it resets the ports, and once they come back on, the link doesn't remake.

If I connect a laptop to the ADVA, the link makes and it can communicate. Laptop NIC properties show a 100mb connection. If I connect a laptop to the fastethernet0/0, the link makes and it can communicate. Lights on 0/0 show 100 mb and full duplex connection.

The config file for that interface is very basic.

!
interface FastEthernet0/0
 ip address 10.0.2.2 255.255.255.0
 speed 100
 full-duplex
 service-policy output EGRESS
!
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!

What would keep the ADVA and Cisco from making a successful link once the Cisco completes its boot?

Best Answer

I don't know what "ADVA" is, but I'm guessing it's metro-ethernet hardware. Most metro-e setups don't do auto-negotiation at all. speed 100 and duplex full should be disabling autoneg, but who knows what Cisco's doing. The keepalive checks could also be killing the link.

If "auto" works for speed and duplex, then go with it. :-) (that's what your laptop is doing.)

Related Solutions

Cisco Catalyst cluster heartbeat switch issue – increasing input errors

CRC errors are often cabling problems. Here are the things I would check next before swapping out hardware:

Are the servers connected directly to the switch or do they connect through some sort of infrastructure cabling? If so, get the infrastructure cables re-certified.
If you have a real cable tester (not a simple continuity tester), I would test the cables.
If the cables are hand made, I would replace with factory made cables. Often run into these types of issues with hand made cables.
Check to see if there is any source of EM near where the cables run. Re-path the cables if you can even temporarily to make sure they are kept separate from power or other sources of EM.

Beyond that, I would start at the NICs as you already indicated. Could be you got some from a bad run.

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

You're right, you wouldn't really see the burstiness easily on SNMP. 1GE can send 1.48Mpps, so it takes very very little time to congest the the 45Mbps, which can handle less than 75kpps.

If your ingress is 1GE and egress is 45Mbps, then obviously the congestion point of 45Mbps will need to drop packets. This is normal and expected. If you increase buffers you'll introduce more delay.
1GE takes 0.45ms to send 40 1500B IP frames, which is right now the amount of burst you can handle. However dequeueing them on the 45Mbps already takes 10ms.

If you don't have any acute problem, I would probably not do anything about it. But if some traffic is more eligible for dropping than other, then you should replace FIFO with class-based queueing. Say maybe you want to prioritize so that more ftp is dropped and less voip.
Then it'll also make more sense to add more buffering on the ftp traffic, as it's not really sensitive to delay.

If you want to try your luck with deeper buffers, something like this should suffice:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

This would cause 50ms buffers on the Serial1 and would allow you to handle up-to 2.25ms burst from single Gige interface.

Best Answer

Related Solutions

Cisco Catalyst cluster heartbeat switch issue – increasing input errors

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

Related Topic