KullPid, Is this for an RTBH configuration? On the RR, I would try configuring an outbound IP prefix-list on the BGP peering with PE1 that allows any routes except /32s.  For example,   conf t ! First line of the IP prefix-list permits any routes down to /31 in size. ! Second line denies all routes not already permitted by the first line, which would be just the /32s. ip prefix-list NoHostRoutes-OUT seq 10 permit 0.0.0.0/0 le 31 ip prefix-list NoHostRoutes-OUT seq 20 deny 0.0.0.0/0 le 32 router bgp xxxxxx  address-family ipv4   neighbor pe1.pe1.pe1.pe1 prefix-list NoHostRoutes-OUT out  exit-address-family end wr mem   If you wanted to just block that one x.x.x.x/32 and let all other routes through to PE1, you could change the IP prefix-list to look something like this:   ip prefix-list NoHostRoutes-OUT seq 10 deny  x.x.x.x/32 ip prefix-list NoHostRoutes-OUT seq 20 permit 0.0.0.0/0 le 32   This is along the lines of what Cristian Matei suggested regarding "configure an outbound policy on RR, towards PE1, restricting whatever networks you want".  And is done on the RR, not on any of the PE(n) routers. Hope this helps. ... View more

The WS-C2960X-48FPD-L has 48 interfaces that are 10/100/1000, and 2 uplink interfaces that are SFP+.   Each 10/100/1000 interface has a maximum link speed of 1,000 Mbps = 1 Gbps = 1,000,000,000 bits per second. Each SFP+ interface has a maximum link speed of 10 Gbps = 10,000,000,000 bits per second.   For each packet transmitted on an Ethernet link, there are 12 bytes of Inter Frame Gap, followed by 7 bytes of MAC Preamble and then a 1-byte of Start of Frame Delimiter, adding up to 20 bytes of overhead (12+7+1=20).  Next, add to this a minimum-size Ethernet frame of 64 bytes, which consists of a 6-byte Destination MAC Address, then a 6-Byte Source MAC Address, then a 2-byte MAC Type or length, a minimum Network Payload of 46 bytes, followed by a 4-byte CRC (6+6+2+46+4=64), and you get a total of 84 bytes (20+64=84) involved in the transmission of that packet.  Since there are 8 bits per byte, that 84 bytes can also be thought of as 672 bits (84*8=672).   If you divide 1,000,000,000 bits per second by 672 bits per 64-byte packet transmitted, you get 1,488,095.238095 which is the maximum number of 64-byte packets you can transmit per second on a 1-Gbps connection.   Multiply that by 10 to get 14,880,952.380952 which is the maximum number of 64-byte minimum-sized packets you can transmit on a 10-Gbps connection.   48 interfaces of 1-Gbps transmitting 64-byte packets gets you 71,428,571.428571 packets per second, or pps.  (48*1,488,095.238095).   2 interfaces of 10-Gbps transmitting 64-byte packets gets you 29,761,904.761904 pps.   (2*14,880,952.380952).   Add those two multi-million numbers together, and you get 101,190,476.190475 pps.  (71,428,571.428571+29,761,904.761904).   That number looks like it is still short of the 130.9 Mpps quoted on the Data Sheet.  About 2 10-Gbps interfaces short, in fact.  Is there a way we can get 2 more 10-Gbps interfaces into a 2960-X that already has 48 10/100/1000 and 2 SFP+ interfaces?  Yes!   If you install a C2960X-FIBER-STK FlexStack-Extended Fiber stacking module, that will give you two more SFP+ interfaces on the back of the switch.  They are in stack mode by default.  But you can convert them to network mode, which give you another 2 interfaces of 10-Gbps. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15_2_6_e/configuration_guide/b_1526e_consolidated_2960x_cg/b_1526e_consolidated_2960x_cg_chapter_01010010.html#id_33181   So, 101,190,476.190475 pps from the 2960-X switch itself + 29,761,904.761904 more pps from the FlexStack-Extended Fiber stacking module installed in it with those 2 SFP+ stack ports converted to network ports, equals 130,952,380.952379 pps total.  That's probably where they got 130.9 Mpps for the forwarding rate on the Data Sheet.   Hope this helps.         ... View more

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