The Cisco 887VA is quite a capable unit, and you can see some of the specs as follows:
Cisco 887VA Integrated Services Router-Integrate Access and Security
New Cisco 887VA Routers support DSL multimode, including very-high-speed DSL 2 (VDSL2) and asymmetric DSL 2+ (ADSL2+). Part of the Cisco Integrated Services Routers Generation 2 (ISR G2) portfolio, they support VDSL2 and ADSL2+ on a single WAN interface.
Cisco 887VA Integrated Services Routers provide:
- Multimode DSL (VDSL2 and ADSL2 and 2+) over a basic telephone system
- Business continuity with primary and backup connections
- VPNs at broadband speeds up to 20 tunnels
- Built-in security capabilities such as Network Address Translation (NAT) and firewall
- Four 10/100 Mbps Fast Ethernet switch ports
- Easy deployment with Cisco Configuration Professional
- Centralized management
- Universal software image for easy expansion with software activation
Available options include:
- Advanced security, including intrusion prevention, Group Encrypted Transport VPN, and dynamic multipoint VPN (DMVPN)
- Power over Ethernet (PoE) on two switch ports
More details you can visit: http://www.cisco.com/en/US/products/ps11063/index.html
For a site that has a couple of PCs, but which need to be strictly separated (for example, staff and client PCs), the unit is great – it has a few VLANs, ACLs, firewall functionality, and even VRFs or L2TP if you want to go that far. Take note that to get the most options available and therefore the most flexibility with things like a choice of routing protocols, DMVPN, and IPSec tunnels, for a few extra dollars go for the Advanced IP feature set:
Another thing that we have been trialling is Scansafe content filtering; content filtering is a duty-of-care and in some cases legislative requirement for an organization that has under-18s in residential care. The Cisco 887VA with Advanced IP running 15.2 and up can natively integrate with Scansafe, meaning no configuration on the end-user; no pesky .Pac files to exclude the intranet sites from the filtering. I’ve had it running in a trial at two sites and it works a treat. At the management end, you can use user authentication or, as we are doing, the embedded local IP addresses to differentiate sites and groups for access and on the router only a handful of commands are required to set up a system with regex and IP whitelists. Like all content filtering, it has its flaws, and a savvy user will be able to circumvent it given enough time and effort, but at this stage, it is proving very effective.
In the image below, I just did a “dir?” to list the file systems, and then plugged in the USB, and lo and behold, there it was.
Plugging in a Toshiba 16Gb thumb drive
So now, just like any flash or nvram file system, I can copy to and from the USB drive.
Directory listing for my IOS images
Copy running config to USB drive
At this stage, you can boot with a config on the thumb drive; you can’t yet boot from an image on the drive.
We can certainly see where it could come in handy – non-technical people can usually be relied upon to plug in a thumb drive for you if you can’t do your software update remotely for some reason, or you could use the archive commands to regularly do local copies of configs, or copy logs or debugs for later analysis. Plus if you are on site, you don’t need a laptop with an ethernet and a TFTP client and a console cable to do a local update – just plug in the USB and the console cable.
The Cisco 887VA is a very capable small branch router, and if you are in the market for a fixed form factor router that gives you all the options you might need, you can choose it.
Scott Hogg wrote the article “Cisco USB Console Ports” that is a popular one in a list of the top 10 articles in his blog. Here we will share it with network and Cisco fans.
Cisco USB Console Ports
Cisco products now come with USB ports that allow console access
For years I have been wondering when Cisco would activate the USB ports on their devices. I have been hoping for all kinds of USB functionality to routers, switches, firewalls but Cisco has been slow to unlock the power of these USB ports. Wouldn't it be cool if you could connect the myriad of USB devices to a Cisco router to further the list of amazing things you could do? Cisco has started to put mini-USB ports on their devices to allow for console port connectivity.
I am hoping that this new method continues to be spread to other devices. I also hope that Cisco will enable all of the USB Type-A ports on their other devices for similar connectivity. For years I have hauled around two console cable sets. Because I often connect to multiple devices at the same time, such as redundant supervisors on Catalyst 6500s or to two supervisors in redundant Catalyst 6500s or VSS, I need two serial cables. Here is a picture of one of my typical USB cables. I use a Keyspan USA-19HS USB to serial adapter. I realize that this is expensive but it is the most reliable and its driver seems universally accepted by laptop operating systems. Note that the end on the light-blue console cable has been replaced and a yellow boot added because of excessive wear. You know you have logged into a lot of Cisco routers when you wear out the RJ-45 connector on the end of your favorite console cable.
Cisco has now given us the ability to connect our laptops to the USB ports for console access. Cisco has added USB Type-B ports to their devices and these ports can be used as a console cable.
You will need three things to get this working.
1) A device that uses this type of USB Type-B port
2) A USB Type A to 5-pin mini Type-B cable
3) A driver from Cisco to make this work with your laptop operating system
You still need to install a driver on your laptop to use the USB interface as a serial communications port. Don't worry that this link shows the download location for 3900 ISR G2 routers. The same utility works for the entire ISR-G2 line. The latest version of the USB Console Software is version 3.1 The filename of the software is "Cisco_usbconsole_driver_3_1.zip" and the current version was release on Jan 20, 2010 with a file size of 14692.83 KB (15045453 bytes).
Currently, Cisco has USB console drivers for the following operating systems:
- Windows 2000, Windows XP 32- and 64-bit, Windows Vista 32- and 64-bit
- Mac OS X version 10.5.4
- Redhat / Fedora Core 10 with kernel 188.8.131.52-117
- Ubuntu 8.10 with kernel 2.6.27-11
- Debian 5.0 with kernel 2.6
- Suse 11.1 with kernel 184.108.40.206-9
Once you install the driver you need to create a connection using your favorite terminal emulation software. My favorite one happens to be SecureCRT from VanDyke. You need to set the terminal emulator to use the proper COM port that is being used by the USB port on your laptop. Then you set the serial communications to the old-reliable standard: 9600 baud, 8 data bits, no parity, and 1 stop bit, no flow control. However, I have been told that these console ports can be run up to 12Mbps but the baud rate of the serial port can only go as high as 115,200 bps. That could have come in handy many moons ago when I had to upload IOS files using XMODEM.
The other caveat is that the Cisco devices are still coming with the traditional RJ-45 console ports. You can use both of these ports but only one will allow for commands to be entered. It appears that the USB port trumps the RJ-45 port. It is like the USB port is the default console media-type. Since the USB port takes precedence over the RJ-45 port then you will want to set the inactivity timeout for the USB port so that if it is unplugged that the RJ-45 port can become active again.
This is done with the following command.
Switch# configure terminal
Switch#(config)# line console 0
Switch#(config-line)# usb-inactivity-timeout 30
I believe that the usb-inactivity-timeout command is not supported on 2900 series routers. To restore USB console port connectivity after the timeout period then you will need to unplug and re-plug the USB port to re-activate the USB console port connection.
For security reasons you may want to disable this USB port. In this case you can configure the device to only allow console connectivity with the RJ-45 port. This can be performed with the following commands.
Switch# configure terminal
Switch(config)# line console 0
Switch(config-line)# media-type rj45
When I logged into the USB port of an ISR G2 router I was prompted for the same console login method configured for "line con 0". Therefore, there is no need to worry about the security of the USB console ports unless you haven't configured proper security for your serial line console port. In other words, you don't have to specify AAA for the USB port. It simply uses the same AAA strategy defined for "line con 0" for both the RJ-45 serial and USB interfaces.
Right now, from what I can tell, the only devices that can use this special USB interface as a console port are the Cisco ISR G2 routers (1900s, 2900s, 3900s, 5500 Wireless controllers, 3750-X, 3560-X, and 2960-S switches).
Does anyone know of any other Cisco product that has these USB/Console ports?
The ASA 5505 is the only model that has an 8-port switch embedded in the device. All interfaces of the ASA5505 are Layer2 switch ports and thus they support some features that you can find on Cisco switches. One of these features is called “Private Vlan”.
The concept of “Private VLAN” is very useful in DMZ environments. Here is how it can be used: Let’s say you have a firewall with an Outside interface connected to Internet, an Inside interface connected to the secure LAN, and a DMZ Interface connected to a subnet which is hosting several publicly accessible servers (e.g Web Server, Email server etc). The DMZ servers are all on the same network subnet. Thus, if one of the DMZ servers gets compromised, then the attacker can easily use this hacked server as a “stepping-stone” to access the other servers in the DMZ.
The above situation can be mitigated by using “Private VLANs”. Although the DMZ Layer2 VLAN number and Layer3 subnet will be the same for all servers, by designating each switch port of the DMZ as “Private VLAN” then the servers in the DMZ will not be allowed to communicate with each other.
Let’s see a diagram below to explain the concept of “Private VLAN”.
Let’s say we have an Cisco ASA5505 with three security Zones:
- Outside Zone: Interface E0/0 in VLAN 10
- Inside Zone: Interface E0/1 in VLAN 20
- DMZ Zone: Interfaces E0/2, E0/3 in VLAN 30
Notice that in DMZ we have 2 publicly accessible servers (Web and Email Server) that they both belong in the same Layer2 vlan (VLAN30) and the same Layer3 network subnet (10.0.0.0/24).
If we don’t configure “Private Vlans”, then if the Web or Email server gets hacked, the attacker can access the other DMZ server as well. With Private VLANs, the Web and Email Servers can NOT communicate with each other although they are on the same Vlan and subnet. However, all other zones (outside and inside) are able to access the DMZ zone (and vice-versa) with no problems.
We are not going to see the complete config here, just the part that has to do with Private Vlan setup.
ASA5505(config)# interface ethernet 0/0
ASA5505(config-if)# switchport access vlan 10
ASA5505(config-if)# no shutdown
ASA5505(config-if)# interface ethernet 0/1
ASA5505(config-if)# switchport access vlan 20
ASA5505(config-if)# no shutdown
ASA5505(config-if)# interface ethernet 0/2
ASA5505(config-if)# switchport access vlan 30
ASA5505(config-if)# no shutdown
ASA5505(config-if)# switchport protected
ASA5505(config-if)# interface ethernet 0/3
ASA5505(config-if)# switchport access vlan 30
ASA5505(config-if)# no shutdown
ASA5505(config-if)# switchport protected
The command “switchport protected“ configures the specific physical ports as “Private VLANs”. All ports that are configured as Private Vlans cannot communicate with each other.
---Resource from http://www.tech21century.com
The newer versions of NX-OS support 1G or 10G on the N5K, but the Nexus5000 is not auto-speed sensing. A mini case study follows.
Description: Gi1/1/1: This port has been disabled because Non Compliant Gigabit Interface Converter (GBIC) connector detected.
Recommendation: Replace connector with cisco compliant Gigabit Interface Converter (GBIC) connector. Refer switch technical documentation to determine cisco compliant connector. Enable the port again.
This seemed odd, since the GLC-SX-MM is supported on both devices. I tried shut/no shut on both ends of the port, but that did not help. I then wondered - does he have a bad SFP? I poked around a bit.
The CLI show log info on the 3750 switch was also unhappy:
*Apr 16 01:48:41.190: %PHY-4-SFP_NOT_SUPPORTED: The SFP in Gi1/1/1 is not supported
*Apr 16 01:48:41.190: %PM-4-ERR_DISABLE: gbic-invalid error detected on Gi1/1/1, putting Gi1/1/1 in err-disable state
Strange, the GLC-SX-MM is supported on the Catalyst 3750. The interface capabilities looked fine:
3750_sw1#sh int gig 1/1/1 capa
Type: 1000BaseSX SFP
Trunk encap. type: 802.1Q,ISL
Trunk mode: on,off,desirable,nonegotiate
Broadcast suppression: percentage(0-100)
Fast Start: yes
QoS scheduling: rx-(not configurable on per port basis),
tx-(4q3t) (3t: Two configurable values and one fixed.)
CoS rewrite: yes
ToS rewrite: yes
Inline power: no
The status on the 3750 was not connected:
3750_sw1#sh int gig 1/1/1 status
Port Name Status Vlan Duplex Speed Type
Gi1/1/1 notconnect 1 auto auto 1000BaseSX SFP
I then went to look at the N5K. It claimed it has an invalid SFP of an unkown type:
N5K1# sh int e1/5 status
Port Name Status Vlan Duplex Speed Type
Eth1/5 -- sfpInvali 1 full 10G SFP-1000BAS
N5K1# sh int e1/5 capa
Type (SFP capable): 10Gbase-(unknown)
Trunk encap. type: 802.1Q
Broadcast suppression: no
Rate mode: none
QOS scheduling: rx-(6q1t),tx-(1p6q0t)
CoS rewrite: no
ToS rewrite: no
Link Debounce: yes
Link Debounce Time: yes
Pvlan Trunk capable: yes
TDR capable: no
FabricPath capable: yes
Port mode: Switched
FEX Fabric: yes
The Nexus5000 also claimed there was no transceiver:
N5K1#sh log | inc 1/5
2012 Apr 6 18:10:26 N5K1 %ETHPORT-5-IF_DOWN_NONE: Interface Ethernet1/5 is down (None)
2012 Apr 6 19:06:10 N5K1 %ETHPORT-5-IF_HARDWARE: Interface Ethernet1/5, hardware type changed to No-Transceiver
I scratched my head a bit, and then came up with the underlying issue - when installing 1GE optics in the N5K, you need to manually set the speed. If you look back, you will see the previous 'sh int e1/5 status' on the N5K shows a speed of 10G. So after the appropriate "speed 1000" command to the e1/5 interface on the N5K, the link came up on both ends.
N5K1# sh int e1/5 stat
Port Name Status Vlan Duplex Speed Type
Eth1/5 -- connected 1 full 1000 SFP-1000BAS
Summary: The newer versions of NX-OS support 1G or 10G on the N5K, but the N5K is not auto-speed sensing. If you run into something similar, even error messages on the remote device, check the port speed on the N5K.
---Resource from http://www.netcraftsmen.net
This document is an illustration of Stub, Totally Stub and NSSA area feature in an IPv6 environment. Stub, NSSA, and totally stubby are supported and configured in the exact same way as for OSPFv2 for IPv4, using the area stub, area nssa, and area stub no-summary commands.
In this document, three routers (R1,R2 and R3) are configured with OSPFv3 routing protocol, with router R1 and R3 in Area 0 and R1/R2 in Area 12. Router R3, has three Loopback interfaces and are advertised via OSPFv3. The only exception of Loopback 3, which is redistributed into OSPFv3 routing protocol to make it as an external route. This is done purposely to differentiate between different type of routes received by router R2 under different cisrcumstances. Under Normal conditions, i.e. running OSPFv3 without any of the stub feature all these routes will appear at R2 as below.
Note: route OE2 is external as it was redistributed on R3 as a connected route. See configuration of R3.
All configurations are tested on Cisoc 7200 series router running Cisco IOS 15.1(3)S3 advance ip services image.
For complete configuration, see attached files (R1, R2 and R3).
Case Study 1: OSPFv3 Stub Routing
In Stub routing, the router gets a deafult route and the internal OSPF routes. The external routes are filtered out. Stub feature is configured by command "area x stub" under the OSPFv3 routing configuration mode. It is important to configure both the ends by keyword stub.
Note: A deafult toute::/0 along with OSPF Internal routes are only received by stub router R2. Prefix AA3::33 is an external route and is filetered out, even though it is reachable.
Case Study 2: OSPFv3 Totally Stubby Area
In Totally stubby area, the stub router receieves only the default route and all other (intra, inter, external) are filtered out. The feature can be configured on any one router by command "area x stub no-summary".
Note: Stub Router, R2, receives only the default route ::/0.
Case Study 3: OSPFv3 Not So Stubby Area (NSSA)
The feature works with command "area x nssa". With NSSA, the routes receives only the Intra and Inter OSPF routes, all other routes (External) are filtered out. For NSSA, the configuration is done at both the ends.
Note: Stub Router R2, is receives only the Intra/Inter OSPF routes.
---DOC from https://supportforums.cisco.com/docs/DOC-25487
More Related OSPF Tips:
When setting up dynamic routing protocols, there are certainly a number of things that need to be configured correctly for everything to end up working as planned. On top of this, each of the different routing protocols has different elements that they expect to be configured first for each of them to operate correctly. This article takes a look at these requirements from the perspective of OSPF and shows the different commands that can be used to ensure proper OSPF neighborship configuration and communications between devices.
OSPF Neighborship Requirements
From the perspective of OSPF, there are a couple of things that must match for a OSPF neighborship to establish; these include:
- The devices must be in the same area
- The devices must have the same authentication configuration
- The devices must be on the same subnet
- The devices hello and dead intervals must match
- The devices must have matching stub flags
OSPF Neighborship Configuration Verification and Troubleshooting
Starting from the top of the list, the interfaces connecting devices must be on the same area. To display the various commands and what to look for, Figure 1 shows a simple lab has been setup with two devices that are connected together via an Ethernet connection.
Figure 1-Simple Lab
The first thing that is going to be checked by the OSPF device is whether the remote device is in the same area. No other processing will occur on the device until both devices have been configured with the same area. Figure 2 shows an example of the message given by the debug ip ospf adj command when the remote device is not in the same area. As can be seen from the figure, the remote device is configured into area 1 (notated as 0.0.0.1) while the local device is configured for area 2 (notated as 0.0.0.2).
Figure 2-Mismatched Areas
The second entry on the list was that each device must have matching authentication configuration; before any other information is exchanged between the devices they must agree on an authentication type (if any is configured). If the parameters are not the same on both sides, the neighborship process will never progress. Figure 3 shows the error message that will be displayed (from the debug ip ospf adj command) when an authentication mismatch occurs.
Figure 3-Authentication Mismatch
Another valuable command to use when troubleshooting OSPF is debug ip ospf hello. As the name suggests, this command shows debugging information for the hello event s between devices. Since a neighborship starts with a hello exchange, this is a valuable command to use.
The third entry on the list was that each device must be in the same subnet. Figure 4 shows an example of a message that shows the engineer that a mismatch exists between devices and upon closer inspection it shows that the subnet mask is configured differently on each device. In this case the remote device was configured in the 10.10.10.0/25 subnet while the local (connected) device was configured in the 10.10.10.0/24 subnet.
Figure 4-Subnet Mismatch
Hello and Dead interval mismatch
The fourth entry on the list is matching hello and dead intervals. When configuring the hellointerval on an interface, the device (With Cisco equipment) will automatically adjust the deadinterval; Figure 5 shows a case where the remote device was configured with a hello interval of 8 (Seconds) while the local device uses the default setting of 10.
Figure 5-OSPF hello and dead interval mismatch
Stub Flag Mismatch
The final entry on the list was that the device must agree on whether the area is a stub or not. Figure 6 shows an example of a message where the devices disagree on whether the area is a stub area or not.
Figure 6-Stub Flag Mismatch
While it can be often overlooked, a neighborship is the first thing that must be established before any communication will happen between devices. Each of the different routing protocols has their own requirements that must be met before this neighborship will establish. This article takes a look at the elements that must match for OSPF neighborships to establish and what commands to use to troubleshoot which misconfiguration potentially exists. Hopefully, the information in this article, when committed to memory, will help in future OSPF configuration endeavors.
More Related OSPF Tips:
AAA stands for Authentication, Authorization, and Accounting. AAA is a mechanism that is used to tell the firewall appliance who the user is (Authentication), what actions the user is authorized to perform on the network (Authorization), and what the user did on the network after connecting (Accounting). In this post we will focus on the first element of AAA (that is Authentication).
Types of Authentication supported on ASA appliances
Three types of Authentication are available for Cisco ASA firewalls:
1. User Authentication for accessing the security appliance itself.
2. User Authentication for accessing services through the security appliance. This is also called “cut-through proxy” and is used to authenticate users for accessing Telnet, FTP, HTTP, and HTTPs services located in the network through the firewall.
3. User Authentication for VPN tunnel access (IPsec or SSL VPN).
We will see a configuration example for the first type (authentication for accessing the security appliance for management using Serial Console, SSH, and Telnet access).
Authentication configuration example
In this example we assume that we have already installed and configured a AAA server (e.g Cisco ACS) running the TACACS+ authentication protocol. On the AAA server, we have configured a username/password account that the firewall administrators will use to authenticate. Assume also that the AAA server is located on our internal LAN network with address 10.1.1.1
Referring to the figure above, the firewall administrator (Admin) requests firewall access (serial console, SSH, or Telnet) (Arrow 1) for managing the appliance. The ASA firewall (Arrow 2) will request Authentication permission from the AAA server in order to prompt the admin user for Username/Password credentials. After the Admin successfully enters his credentials, the AAA server will give the permission to the Firewall to allow the user in.
Here is the configuration below:
! Specify a AAA server name (NY_AAA) and which protocol to use (Radius or TACACS+)
ASA(config)# aaa-server NY_AAA protocol tacacs+
! Designate the Authentication server IP address and the authentication secret key
ASA(config)# aaa-server NY_AAA (inside) host 10.1.1.1
ASA(config-aaa-server-host)# key secretauthkey
! Enable Authentication for management access
ASA(config)# aaa authentication serial console NY_AAA LOCAL
ASA(config)# aaa authentication telnet console NY_AAA LOCAL
ASA(config)# aaa authentication ssh console NY_AAA LOCAL
The “LOCAL” keyword at the end designates the use of the local firewall username database for authentication in case the AAA server authentication is not available (e.g AAA server is down).
Of course, to complete the scenario above, you need to properly configure the AAA Server with the internal IP address of the ASA firewall and the same authentication key (e.gsecretauthkey) as the one you configured on the ASA above.
---Article reference from http://www.tech21century.com/configuring-aaa-authentication-on-cisco-asa-firewall/
In small form factor, CGS-1000 switch is low-latency and designed for utilities
Cisco, which wants to expand its clout into the industrial networks used by power-generation utilities to support the electric grid, today announced an expansion of its "smart grid" portfolio with ruggedized and low-latency switches and other equipment intended for use in electric-power distribution systems.
"Utilities often have systems unique to them," said Jenny Gomez, marketing manager in Cisco's Connected Energy Business Unit that oversees the architecting of a wide range of equipment for networking and physical security to modernize utility networks while supporting their legacy systems that in some cases aren't being swapped out. As part of this effort, Cisco today introduced a number of products, including the CGS-1000 switch in a small form factor for use in a location such as an electric substation that's part of a complex, critical power-distribution system.
"The CGS-1000 is built to withstand harsh environments," pointed out Joe Ammirato, senior director of product management at Cisco's Connected Energy Business Unit. The ruggedized low-latency switch is intended to be able to work with utility sensors that often have serial interfaces, not Ethernet ones, Ammirato noted.
With experience gained over a few years in working with some utilities in North America and Europe, Cisco has been designing specialized switching, network access and security products for both data center and substation equipment under its so-called GridBlocks architecture. The push is part of Cisco's much-ballyhooed "Internet of Everything" initiative that's taking the company further into areas outside of traditional business IT networking.
The GridBlocks architecture supposes that Cisco will be able to provide equipment aimed not only at the substation tier, but also the system-control level where wide-area networks connect substations with each other and with control systems as well as SCADA and other event messaging.
The architecture also addresses utility data centers and control centers, plus devices and systems associated with residences and third-party elements. The Cisco GridBlocks architecture lists several other tiers for interchange and trans-national grid monitoring and tie-ins as well. In many cases, Cisco isn't coming up with entirely new products for the utilities but adapting its network segmentation, switching, security and management platforms to try and suit specialized needs utilities have.
Cisco is recommending MPLS as a core technology for utility use, especially in substations, says Ammirato, who points out that utility networks associated with the grid may not necessarily be IP-based at all today or they connect in a style not seen in modern IT business networks. For utilities intending to modernize, the challenge is in swapping out what can reasonably be changed while bridging older legacy systems that for one reason or another will remain related to the transmission grid.
---News from http://www.networkworld.com/news/2013/050713-cisco-ruggedized-switches-269475.html
More Cisco News and Reviews:
As of 12.2(55) SE, Cisco 2960s are layer 3 switches. Configuring Catalyst 2960s to route is pretty simple. The Switch Database Management template (SDM) needs to be changed to “lanbase-routing”. A reboot is (always) needed after changing the SDM template. After reboot, it’s just like enabling routing on any other L3 switch with the command “ip routing” from global config.
First we’ll change the SDM template:
SwitchA(config)#sdm prefer lanbase-routing
Changes to the running SDM preferences have been stored, but cannot take effect until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.
System configuration has been modified. Save? [yes/no]: y
Proceed with reload? [confirm]
After changing the SDM template, we are reminded that we’ll need to reboot and also given a command to verify the change after the next boot.
Now we verify:
SwitchA#show sdm prefer
The current template is "lanbase-routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 255 VLANs.
number of unicast mac addresses: 4K
number of IPv4 IGMP groups + multicast routes: 0.25K
number of IPv4 unicast routes: 4.25K
number of directly-connected IPv4 hosts: 4K
number of indirect IPv4 routes: 0.25K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 0.125k
number of IPv4/MAC security aces: 0.375k
The change was successful and we’re given the details about this SDM template.
Now seems like a good time to touch on the limitations of the layer 3 capabilities on 2960s. As we see in the output above, we’re limited to 8 routed interfaces. These will be SVIs. At this point, the Cisco 2960s don’t support routed physical interfaces (“no switchport”). Another important note is that we’re only allowed 16 static routes and there is no dynamic routing capability.
Now we’ll enable IP routing and configure a couple SVIs:
SwitchA(config)#int vlan 15
SwitchA(config-if)#ip add 192.168.15.1 255.255.255.0
SwitchA(config-if)#int vlan 25
SwitchA(config-if)#ip add 192.168.25.1 255.255.255.0
SwitchA#sh ip route
C 192.168.15.0/24 is directly connected, Vlan15
C 192.168.25.0/24 is directly connected, Vlan25
Even now, I’m still amazed that we can do this with a 2960. As expected, it’s working. We have two SVIs and we can see the routing table reflect this.
More Related Cisco 2960 Tips:
The Cisco Catalyst 3K family of switches supports the following three feature sets depending on the specific model of switch:
As visually summarized in Figure 1, the Cisco Catalyst 3560-E and 3750-E Series support the IP Base and IP Services feature sets, whereas the Cisco Catalyst 3560-X and 3750-X Series support the LAN Base, IP Base, and IP Services feature sets.
Figure1. Feature Set Overview
In particular, Figure 2 shows the main differences between the three feature sets supported on the Cisco Catalyst 3K switch family.
Figure2. Feature Set Characteristics and Differences
Each Cisco Catalyst 3750-E/3560-E or 3750-X/3560-X system is loaded with a universal Cisco IOS Software image. Universal Cisco IOS Software images contain all Cisco IOS Software features. The level of Cisco IOS Software functionality available is determined by the combination of one (or more) licenses installed on the device. A specific license file stored in the flash memory of the switch can unlock a specific Cisco IOS Software feature set, from the smallest one to the largest one (Figure 3).
Figure3. Feature Set Activation in a Universal Image
For the Cisco Catalyst 3750-E/3560-E Series, there can be two versions of universal images: plain no crypto universal images and universalk9 images (which offer all the Cisco IOS Software features, including strong crypto features).
For the Cisco Catalyst 3750-X/3560-X Series, in addition to the aforementioned universalk9 images, there are also images with the universalk9-npe designation in the image name. The reason for this alternate image type is that some countries have import regulations that require that the device does not support any strong data-plane crypto functionality, such as IEEE 802.1AE, in any form. To satisfy the import requirements of those countries, this universal image does not support any strong payload encryption (that is, it is of the no payload encryption type).
Note that for the aforementioned platforms "no universal" IP Base images are still available and posted on the cisco.com guest page. This is done so that those who have not purchased a Cisco SMARTnet contract can still get software updates for their LAN Base or IP Base images (or downgrade from IP Services to IP Base and get software updates). LAN Base or IP Base updates are offered as part of the software update policy (see Updating Software on the Cisco Catalyst 3750-E, 3560-E, 3750, and 3560 Series Switches).
---More details: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/white_paper_c11-579326_ps10745_Products_White_Paper.html
More Cisco Catalyst Switch Info and Tutorials: