You are receiving that error message because the light level being received on the SFP transceiver (-40.0 dBm) is below that transceiver's low optical power alarm threshold value of -28.8 dBm.  Normally, when a transceiver says it is at -40 dBm on the receiving side, that usually means it is not getting any light at all on one strand.  In your case, though, you only have one strand.  So it may be getting light—just not in the wavelength range it is expected to receive light at.   If you have two GLC-BX40-U-I SFPs connecting to each other, that one possible source of the problem.  The -U-I SFP at one end is transmitting at a wavelength that the -U-I SFP at the other end is not designed to receive at.  You need a GLC-BX40-D-I at the other end for the connection to work.   The -U-I transmits around 1310nm (1260–1360nm) and receives around 1550nm (1540–1560nm), while the -D-I transmits around 1550nm (1540–1560nm) and receives around 1310nm (1260–1360nm).  They are complementary.   Replace one of those -U-I SFPs with a -D-I SFP and your link should come up.   If you have a -U-I at one end and a -D-I at the other end and the SMF distance is less than 40 km, the cable strand may have a break in it somewhere along the path. You can check this with an Optical Time Domain Reflectometer (OTDR).   If the fiber span is longer than 40 km, you are probably losing too much optical power in the 1310nm transmission direction.  Attenuation of the optical power signal at 1310nm is something like 0.4dB/km, while at 1550nm it is more like 0.25dB/km which is much less.  You would need to upgrade to GLC-BX80-U-I and GLC-BX80-D-I SFPs to go the extra distance.  These transceivers will reach out to 80 km.   Hope this helps.   -Larry   ... View more

Check the "line vty" section of the config.  Is "login" required but no "password" listed for telnet?  For example, this will work: line vty 0 4 login password ThisIsMyPassword But if you do NOT have the "password" command in there, you will be prevented from logging in via Telnet  until after a password has been configured. VTY lines require a password to be configured before user access is enabled.  Otherwise, the switch or router closes any incoming Telnet sessions immediately. ... View more

Standby commands for HSRP go on the Layer 3 interfaces.  That is, the ones with the IP addresses.  Which in your example would be your interface Vlan200. ... View more

It depends on what kind of bogon information you need to block. The following addresses Martians, which are private and reserved addresses.  Other bogon addresses would be netblocks that have not been allocated to a regional internet registry.  A good reference site for these would be Team Cymru's Bogon Reference page at http://www.team-cymru.org/Services/Bogons/ If you are trying to defeat denial-of-service attacks where IP source addresses are spoofed using bogus numbers (refer to BCP38 or RFC2827), an ACL on the outside interface of an Internet-facing router could look something like this: ip access-list extended ISP-IN remark This ACL restricts traffic inbound from ISP. remark Block bogus source IP addresses. deny   ip 0.0.0.0 0.255.255.255 any deny   ip 10.0.0.0 0.255.255.255 any deny   ip 127.0.0.0 0.255.255.255 any deny   ip 169.254.0.0 0.0.255.255 any deny   ip 172.16.0.0 0.15.255.255 any deny   ip 192.0.2.0 0.0.0.255 any deny   ip 192.168.0.0 0.0.255.255 any deny   ip 224.0.0.0 31.255.255.255 any remark Block your own public IP numbers as source IP addresses.  They shouldn't be coming in from the Internet. deny   ip xxx.xxx.xxx.xxx 0.0.0.255 any deny   ip host yyy.yyy.yyy.yyy any remark Permit anything to authorized destination IP addresses. permit ip any xxx.xxx.xxx.xxx 0.0.0.255 permit ip any host yyy.yyy.yyy.yyy remark Block everything else. deny   ip any any exit interface Ethernet0/0 description Outside ISP connection. ip address yyy.yyy.yyy.yyy 255.255.255.252 ip access-group ISP-IN in exit If you are trying to keep bogus IPs from leaving your network, an ACL on the outside interface of an Internet-facing router could look something like this: ip access-list extended ISP-OUT remark This ACL restricts traffic outbound to ISP. remark Block bogus source IP addresses.  These should not be leaving your network and going to the Internet. deny   ip 0.0.0.0 0.255.255.255 any deny   ip 10.0.0.0 0.255.255.255 any deny   ip 127.0.0.0 0.255.255.255 any deny   ip 169.254.0.0 0.0.255.255 any deny   ip 172.16.0.0 0.15.255.255 any deny   ip 192.0.2.0 0.0.0.255 any deny   ip 192.168.0.0 0.0.255.255 any deny   ip 224.0.0.0 31.255.255.255 any remark Block bogus destination IP addresses.  You shouldn't be trying to reach these out on the Internet. deny   ip any 0.0.0.0 0.255.255.255 deny   ip any 10.0.0.0 0.255.255.255 deny   ip any 127.0.0.0 0.255.255.255 deny   ip any 169.254.0.0 0.0.255.255 deny   ip any 172.16.0.0 0.15.255.255 deny   ip any 192.0.2.0 0.0.0.255 deny   ip any 192.168.0.0 0.0.255.255 permit ip any host 255.255.255.255 deny   ip any 224.0.0.0 31.255.255.255 remark Block your own public IP numbers as destination IP addresses. deny   ip any xxx.xxx.xxx.xxx 0.0.0.255 deny   ip any host yyy.yyy.yyy.yyy remark Permit anything from authorized source IP addresses. permit ip xxx.xxx.xxx.xxx 0.0.0.255 any permit ip host yyy.yyy.yyy.yyy any remark Block everything else. deny   ip any any exit interface Ethernet0/0 description Outside ISP connection. ip  address yyy.yyy.yyy.yyy 255.255.255.252 ip access-group ISP-IN  in ip access-group ISP-OUT out exit Periodically check what's being denied by running a "show ip access-list" command.  If necessary, edit the ACL to log information so you can see specifics of what's being blocked.  It can be useful to see what kinds of attacks you are receiving; or what kind of problems you may have inside your network, that are trying to leak out to the Internet. If you want to keep your L3 switch from wasting time routing to bogus IPs as destinations, you can set up a Null interface and then statically route the bogus traffic to it (black-holes it with minimal CPU involvement): interface Null0 no ip unreachables exit ip route 10.0.0.0 255.0.0.0 Null0 250 name RFC1918 ip route 127.0.0.0 255.0.0.0 Null0 name InternalLoopbackIPs ip route 169.254.0.0 255.255.0.0 Null0 name AutoConfigurationIPs ip route 172.16.0.0 255.240.0.0 Null0 250 name RFC1918 ip route 192.168.0.0 255.255.0.0 Null0 250 name RFC1918 ip route 192.0.2.0 255.255.255.0 Null0 name TestNetwork Note that these won't keep you from routing to subnets of those RFC1918 private IP address spaces, if you are using them behind a firewall.  The more-specific routes in the route tables for these will take precedence over the static routes above.  But these routes will keep your L3 switch from wasting any time trying to reach any other, unconfigured, private IP networks. Hopefully that's what you're looking for.  If you need more information, like how to configure a BGP router from accepting bogon routes from other ISPs, there are several ways to do that.  I'll save them for a separate post.  But they basically follow the same pattern as outlined above: deny the bogus route information first, then permit the authorized route information. ... View more

Sounds like a problem between IP H.323 video conferencing and NAT. In addition to having source and destination IP addresses in the packet headers, H.323 embeds some source IP address info in the payload area. Not all router or firewall NAT implementations will recognize this; these will just change the source IP address in the packet header from a private IP to a public one, leaving the private IP address still embedded in the payload area. Then, when the remote video conference unit tries to return traffic to the embedded private IP address, it won't work. Ask your vendors if their equipment can be manually configured to operate in a NAT environment. I work with a bunch of older Tandberg IP video endpoints that can be manually configured to embed the public IP address that the packets will be NATted to, in the payload area. That is, when they are used with firewalls or NAT devices that are not H.323-aware. In cases where the router or firewall doesn't recognize the H.323 issue and compensate for it, and the video endpoint doesn't allow you to alter the IP address embedded in the payload area, then putting the video endpoint outside of your firewall is a common work-around. If your firewall or perimeter security device is H.323-aware, like Cisco's ASA, then you don't need to embed the public IP address at the video endpoint. Just let the ASA handle it. In addition to nailing up a 1-to-1 mapping of private to public IP address for the video unit, so people can initiate video calls to you, there are a bunch of port numbers that you need to allow through. Some will be TCP ports (for call setup/control) and some will be UDP (for audio and video data streams). The UDP ones are often dynamic in nature, changing during the call. You don't need to allow all 65,535 UDP port numbers through, although you can. Most vendors use specific port number ranges for their equipment; make sure you are allowing these through your firewall/NAT as well, and you should be fine. Be careful about allowing certain ports, such as HTTP or SNMP, to the VTC. Some IP video conference equipment can be web-managed or reconfigured remotely. If you don't secure it properly, someone else will have fun doing it for you. ;-) Hope this helps. ... View more

Keep in mind that if your customers wants to go with the 6503 with Sup720 and they want to do full BGP routes, they need to have 1GB of memory on board these days. 512MB won't be enough. I started out with a Sup720-3B which had 512MB. One day I started getting TCAM error messages in the log. I researched the errors and found I was running out of space for IPv4 routes. The short-term fix was to tweak the memory allocation using "mls cef maximum-routes ip 239" and reboot, maximizing what was available for IPv4. Eventually the TCAM errors returned. Upgrading to a -3BXL PFC with 1GB took care of the problem. Maximum-routes for IP defaults to 512K now, and can be increased to 1007K if needed. ... View more

The router by itself should work fine. I've got an older 7206VXR router with NPE-G1. It takes a 400 Mbps Internet feed from one ISP, and a 100 Mbps Internet feed from another. Full BGP routes on both connections: at this moment, 263,799 from the first one, and 263,990 from the second. I use CAR to rate-limit my customers to their committed bandwidth rates, as their traffic crosses the boundaries of my network. I deal mostly with school districts. Average CPU utilization during our busy time today was in the 30% range, with peaks into the 80% range. The router's using a total of 30% of its 1GByte of memory. An NPE-G2 or equivalent (if you go with a 7201 router to save space) would probably handle the load even more comfortably. For what it's worth, several neighboring Intermediate Units have opted for the newer ASR1002 router, to connect to the statewide network while maintaining high-speed connections with their existing ISPs. The ASRs were chosen because they have more processing power than the 7200-series routers. These IUs anticipate dealing with multiple Gigabit Ethernet links at full capacity. (I'm using my Catalyst 6509 switch with Supervisor 720-3BXL for that.) Hope this helps. ... View more

The two fiber interfaces on a WS-C2950C-24 switch are 100Base-FX which is Fast Ethernet (100 Mbps). The fiber interface on your media converter is 1000Base-SX which is Gigabit Ethernet (1,000 Mbps). They do not work together, because they use two different signaling methods. The only thing they have in common is that they both use multimode fiber optic cable. If you need to connect a fiber port on the Catalyst 2950C-24 switch to something else, you need to use different equipment. Either a 100Base-T to 100Base-FX media converter; or a 10/100Base-T to 100Base-FX bridging media converter. For best performance, set the 100Base-FX fiber ports to full duplex. That will give you your best throughput vs. half duplex; and you will be able to transmit over longer distances: 2km for full duplex, vs. 416m for half duplex. If the fiber ports are manually set to full duplex, the copper ports should be as well. Don't leave it to chance; that is to say, don't depend on autodetection on the media converters. ... View more

Strictly speaking, it's not necessary. As you said, "mode active" implicitly uses LACP. I include "channel-protocol lacp" in the configuration to make extra sure that only a LACP EtherChannel takes place on the specified interfaces. This command prevents you from subsequently adding "channel-group 1 mode auto" or "channel-group 1 mode desirable" to the interface config, because those modes use PAgP. It also creates an error message in the log similar to the following when you try: “%EC-5-ERRPROT: Channel protocol mismatch for interface Gi1/1 in group 1: the interface can not be added to the channel group” For me, the usefulness of this command is that it makes it just a little bit harder to mess up the config later on. Most of my EtherChannels are between Cisco switches, and I'm using PAgP for those. A year or two from now, when I'm reviewing interface configs and looking to standardize them, and I have forgotten that the switch at the other end is non-Cisco and therefore does not do PAgP, seeing this command line in the config along with the “channel-group 1 mode active” will remind me there's a reason why the mode is different. ... View more