Overblog Follow this blog
Administration Create my blog
Cisco & Cisco Network Hardware News and Technology

Recent posts

Configuring WCCP? GRE Redirection in WCCP Creates New Tunnel Interfaces

August 11 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Data Center

The WCCP (Web Cache Communication Protocol) was initially designed as a component of IOS whose purpose was to intercept HTTP traffic traversing a router and redirects that traffic to a local cache with the aim of reducing access times to web sites and conserving wide area bandwidth. Typically the packets are redirected from their destination web server on the Internet to a content engine that is local to the client. In some WCCP deployment scenarios, redirection of traffic may also be required from the web server to the client. WCCP enables you to integrate content engines into your network infrastructure. With the introduction of WCCPv2 the scope of the protocol widened to include traffic types other than HTTP allowing the protocol to be used as a more general interception mechanism. In WCCPv2 clients specify the nature of the traffic to be intercepted and forwarded to external devices which are then in a position to provide services, based upon the traffic type, such as WAN optimisation and application acceleration.

Cisco IOS Release 12.1 and later releases allow the use of either WCCP Version 1 (WCCPv1) or Version 2 (WCCPv2).

WCCP VRF Support

The WCCP VRF Support feature enhances the existing WCCPv2 protocol by implementing support for virtual routing and forwarding (VRF).

The WCCP VRF Support feature allows service groups to be configured on a per VRF basis in addition to those defined globally.

Along with the service identifier, the VRF of WCCP protocol packets arriving at the router is used to associate cache-engines with a configured service group.

The interface on which redirection is applied, the interface which is connected to cache engine, and the interface on which the packet would have left if it had not been redirected must be in the same VRF.

In Cisco IOS Release 12.2(33) SRE, this feature is supported only on Cisco 7200 NPE-G2 and Cisco 7304-NPE-G100 routers.

Configuring WCCP

Until you configure a WCCP service using the ip wccp {web-cache | service-number} global configuration command, WCCP is disabled on the router. The first use of a form of the ip wccp command enables WCCP. By default WCCPv2 is used for services, but you can use WCCPv1 functionality instead. To change the running version of WCCP from Version 2 to Version 1, or to return to WCCPv2 after an initial change, use the ip wccp version command in global configuration mode.

If a function is not allowed in WCCPv1, an error prompt will be printed to the screen. For example, if WCCPv1 is running on the router and you try to configure a dynamic service, the following message will be displayed: "WCCP V1 only supports the web-cache service." The show ip wccp EXEC command will display the WCCP protocol version number that is currently running on your router.

Using the ip wccp web-cache password command, you can set a password for a router and the content engines in a service group. MD5 password security requires that each router and content engine that wants to join a service group be configured with the service group password. The password can consist of up to eight characters. Each content engine or router in the service group will authenticate the security component in a received WCCP packet immediately after validating the WCCP message header. Packets failing authentication will be discarded.

SUMMARY STEPS

1. enable

2. configure terminal

3. ip wccp version {1 | 2}

4. ip wccp [vrf vrf-name] {web-cache | service-number} [group-address group-address] [redirect-list access-list] [group-list access-list] [password password [0| 7]]

5. interface type number

6. ip wccp [vrf vrf-name] {web-cache | service-number} redirect {out | in}

7. exit

8. interface type number

9. ip wccp redirect exclude in

Tunnel Interfaces

In IOS versions where WCCP is VRF aware, such as 15.0M and 15.1T, the use of GRE redirection will result in some new tunnel interfaces appearing. On the ASR platform these tunnel interfaces are also present from IOS XE release 2.5 onwards (although VRF support within WCCP on the ASR platform is not present until IOS XE release 3.1).

Examples of the new tunnel interfaces are shown below:

Router#show ip wccp summary
WCCP version 2 enabled, 3 services

Service     Clients   Routers   Assign      Redirect   Bypass    
-------     -------   -------   ------      --------   ------    
Default routing table (Router Id: 30.1.1.80):
web-cache   1         1         HASH        GRE        GRE       
61          1         1         HASH        GRE        GRE       
62          1         1         HASH        GRE        GRE       

Router#show ip interface brief | include Tun
Tunnel0                172.16.0.1      YES unset  up                    up     
Tunnel1                172.16.0.1      YES unset  up                    up     
Tunnel2                172.16.0.1      YES unset  up                    up     
Tunnel3                172.16.0.1      YES unset  up                    up     
Router#

The tunnels are created automatically to process outgoing GRE encapsulated traffic for WCCP. They appear when a cache engine connects and requests GRE redirection. They're not created directly by WCCP, but indirectly via a tunnel API. WCCP has no direct knowledge of these tunnel interfaces, but knows enough to cause packets to be redirected to them. This results in the appropriate encapsulation being applied, after which the packet is then sent to the cache engine. Note that these interfaces are not used in connection with incoming WCCP GRE return packets.

There is one tunnel created per service group that is using GRE redirection, plus one additional tunnel to provide an IP address to allow the other tunnel group interfaces to be unnumbered but still enabled for IPv4. Some information about the tunnels is shown with the command show tunnel groups wccp, although this is unlikely to be useful to the end-user other than to confirm the connection between the tunnels and WCCP.

Router#show tunnel groups wccp             
 WCCP : service group 0 in "Default", ver v2, assgnmnt: hash-table
   intf: Tunnel0, locally sourced
 WCCP : service group 317 in "Default", ver v2, assgnmnt: hash-table
   intf: Tunnel3, locally sourced
 WCCP : service group 318 in "Default", ver v2, assgnmnt: hash-table
   intf: Tunnel2, locally sourced
Router#show tunnel interface t0
Tunnel0
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 30.1.1.80
   Application ID 2: WCCP : service group 0 in "Default", ver v2, assgnmnt: hash-table
   Linestate - current up
   Internal linestate - current up, evaluated up
Router#show tunnel interface t1
Tunnel1
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 172.16.0.1
   Application ID 2: unspecified
   Linestate - current up
   Internal linestate - current up, evaluated up
Router#show tunnel interface t2
Tunnel2
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 30.1.1.80
   Application ID 2: WCCP : service group 318 in "Default", ver v2, assgnmnt: hash-table
   Linestate - current up
   Internal linestate - current up, evaluated up
Router#show tunnel interface t3
Tunnel3
   Mode:multi-GRE/IP, Destination UNKNOWN, Source 30.1.1.80
   Application ID 2: WCCP : service group 317 in "Default", ver v2, assgnmnt: hash-table
   Linestate - current up
   Internal linestate - current up, evaluated up
Router#

Note that service group number shown above is the internal tunnel representation of the WCCP service group number. Group 0 is the web-cache service, but for dynamic services subtract 256 to convert to the WCCP service group number. For interfaces used for redirection, the source address shown is the WCCP router ID.

Information relating to the connected cache engines and encapsulation, including software packet counters, can be seen with the command "show adjacency <tunnel-interface> ...":

Router#show adjacency t0              
Protocol Interface                 Address
IP       Tunnel0                   30.1.1.82(3)
Router#show adjacency t0 encapsulation
Protocol Interface                 Address
IP       Tunnel0                   30.1.1.82(3)
  Encap length 28
  4500000000000000FF2F7D2B1E010150
  1E0101520000883E00000000
  Provider: TUNNEL
  Protocol header count in macstring: 3
    HDR 0: ipv4
       dst: static, 30.1.1.82
       src: static, 30.1.1.80
      prot: static, 47
       ttl: static, 255
        df: static, cleared
      per packet fields: tos ident tl chksm
    HDR 1: gre
      prot: static, 0x883E
      per packet fields: none
    HDR 2: wccpv2
       dyn: static, cleared
      sgID: static, 0
      per packet fields: alt altB priB
Router#show adjacency t0 detail
Protocol Interface                 Address
IP       Tunnel0                   30.1.1.82(3)
                                   connectionid 1
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 1
                                   Encap length 28
                                   4500000000000000FF2F7D2B1E010150
                                   1E0101520000883E00000000
                                   Tun endpt
                                   Next chain element:
                                    IP adj out of Ethernet0/0, addr 30.1.1.82
Router#show adjacency t0 internal
Protocol Interface                 Address
IP       Tunnel0                   30.1.1.82(3)
                                   connectionid 1
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 1
                                   Encap length 28
                                   4500000000000000FF2F7D2B1E010150
                                   1E0101520000883E00000000
                                   Tun endpt
                                   Next chain element:
                                    IP adj out of Ethernet0/0, addr 30.1.1.82
                                    parent oce 0x4BC76A8
                                    frame originated locally (Null0)
                                   L3 mtu 17856
                                   Flags (0x2808C4)
                                   Fixup enabled (0x40000000)
                                         GRE WCCP redirection
                                   HWIDB/IDB pointers 0x55A13E0/0x35F5A80
                                   IP redirect disabled
                                   Switching vector: IPv4 midchain adj oce
                                   IP Tunnel stack to 30.1.1.82 in Default (0x0)
                                    nh tracking enabled: 30.1.1.82/32
                                    IP adj out of Ethernet0/0, addr 30.1.1.82
                                   Adjacency pointer 0x4BC74D8
                                   Next-hop 30.1.1.82
Router#

For more information on configuring WCCP, please refer to the following document:

http://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/configuration/15-1mt/iap-wccp.html

Related Information

Common WAAS/WCCP issues on interactions with Security Devices

Troubleshooting Prepositioning on WAAS 4.1.1 and above

Topic from https://supportforums.cisco.com/document/60636/gre-redirection-wccp-creates-new-tunnel-interfaces

More Cisco and IT...Networking Topics you can visit: http://blog.router-switch.com/

Read more

How to Stack Cisco 3750E and 3750X Switches?

August 7 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Switches - Cisco Firewall

The issue: “There are two Cisco 3750 switches: WS-C3750E-48PD-SF and WS-C3750X-48PF-L. Both have universal IOS. So can we make the stacking of these two Cisco switches?”

How to STACK the Cisco 3750E and 3750X one? Firstly, we should know the license the two 3750s have. Well, the switch 3750E has IP Base license and the 3750X has LAN Base license. In fact, the 3750E and the 3750x-LAN base are not compatible to stack.

Cisco 3750x LanBase can only stack with other LanBase. 3750x IPBase can stack with any other 3750 (with the exeption of 3750x lanbase and some older 3750 with 16 Mb of memory)

So we need to have a license upgrade the 3750x from lanbase to ipbase and then they are able to stack with each other.

It is a license thing: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/data_sheet_c78-584733.html "The Cisco Catalyst 3750-X Series Switches with LAN Base feature set can only stack with other Cisco Catalyst 3750-X Series LAN Base switches. A mixed stack of LAN Base switch with IP Base or IP Services features set is not supported."

A Cisco 3750 switch can be stacked with any other model of Cisco 3750 switches but 3750X to

Participate IP services feature set enabled otherwise Basic routing functions, including static routing and the Routing Information Protocol (RIP) will be in use.

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807811ad.shtml

In stacking 3750, 3750G or 3750X IOS should be identical.

https://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/prod_white_paper09186a00801b096a.html

This discussion you can read here…

https://supportforums.cisco.com/discussion/11623571/stacking-switch-3750e-and-3750x

More Related Topics

How to Upgrade the License from IP Base to IP Services on 3750-X Stack?

Cisco Switch Stacking Using a Couple of Cisco Catalyst 3650

Cisco 3750 Stacking Configuration

Read more

An Example to Upgrade IOS on Cisco 4500X Switch

July 22 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Switches - Cisco Firewall

Kingston 32Gb USB Flash with Metal Casing-Using a Kingston USB stick to upgrade the IOS on a Cisco 4500X Switch

Kingston 32Gb USB Flash with Metal Casing-Using a Kingston USB stick to upgrade the IOS on a Cisco 4500X Switch

How to upgrade the IOS/Software on a Cisco 4500X switch? A Consultant named Roger Perkin (Who is for a Cisco Gold Partner in the UK) shared his experience of Upgrading IOS on Cisco 4500X Switch. What’s it? Let’s have a look.

Roger Perkin said that it will not be covering how to do a hitless upgrade using ISSU with 2 switches in a VSS pair. This process is performed on two switches which are not in production. So to perform the upgrade he has disconnected the VSS link and will upgrade each switch in turn and will then connect the VSS link again.

First copy your image file into the bootflash: of the switch, this can be done via TFTP or USB.

USB is the much easier solution, for this to work you need a compatible USB stick, I have always used a Kingston brand and have never had any problems.(This is the exact USB stick he used for upgrading IOS on Cisco Switches)

Insert the USB stick into the slot on the front of the Cisco 4500X switch as shown above.

From the CLI issue the command dir usbb0: If you get (No such device) your USB is not supported

4500X-SW-01#dir usb0:

%Error opening usb0:/ (No such device)

If your USB is supported this is the output you will see

4500X-SW-01#dir usb0:

Directory of usb0:/

176 -rwx 173555452 Mar 23 2015 18:59:44 +00:00 cat4500e-universalk9.SPA.03.05.03.E

You now need to copy this image from the USB to the bootflash: using the following command

copy usb0:cat4500e-universalk9.SPA.03.05.03.E.152-1.E3.bin bootflash:

This will copy the image onto the bootflash of the switch.

You now need to tell the switch to boot this image.

There are 2 options to do this – Option 1 Rename old IOS

By default the config-register of the switches will be set to 0x2101 when the appliance is shipped out.

The last octet of “1” basically tells the appliance to IGNORE the boot variable string and boot the first valid IOS
(from top to bottom) found in the bootflash.

So you can either delete the old image or rename it. I prefer to rename it.

rename bootflash:OLD_IOS_filename.bin bootflash:OLD_IOS_filename.bin

If you now reload the switch it will boot the newer image.

Option 2 – change boot variable and config-register

The second option is to create a new boot variable

In global config enter the command.

boot system flash bootflash:cat4500e-universalk9.SPA.03.05.03.E.152-1.E3.bin (or your new image name)

Just this will not do anything as with the config register set to 0X2101 it will ignore the boot variable set.

If you change the config-register to 0X2102 the switch will then reference the boot variable.

In global config

config-register 0x2102

Save the config and reload the switch.

You may need to delete any other boot variable settings

Check this with sh ver | inc boot

If there is a second one referencing the old image delete it.

Repeat this operation on the second switch and when both have booted using the new image connect up the VSS link.

Reference from http://www.rogerperkin.co.uk/ccie/switching/4500x/how-to-upgrade-ios-on-cisco-4500x-switch/

More Topics Related to Cisco 4500 Series

What’s New on Cisco Catalyst 4500 VSS?

VSS on Cisco 4500/4500X Switches

Cisco VSS Configuration: Cisco Catalyst 6500 Virtual Switching System

A Sample VSS Configuration for 2x Cisco Cat6500 with Supervisor 720

Cisco 4500 VSS Requirement-Software, Hardware and Licensing

Cisco Catalyst Switches for the Different Types of Campuses

Read more

What’s The New of Cisco Catalyst 4507R+E and 4510R+E Chassis?

July 17 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Switches - Cisco Firewall

WS-C4507R-E and WS-C4510R-E-Redundant Sups

WS-C4507R-E and WS-C4510R-E-Redundant Sups

Two new redundant chassis, the Catalyst 4507R+E and 4510R+E had been introduced to Cisco Catalyst 4500E family. What’s the new of them? WS-C4507R+E, as the name, is a new 7-slot redundant chassis. And WS-C4510R+E, is a 10-slot redundant chassis. WS-C4507R+E continues to support five line card slots and two supervisor slots, like the WS-C4507R-E chassis. Similarly, the WS-C4510R+E chassis continues to support eight line card slots and two supervisor slots, like the WS-C4510R-E chassis.

Compared to the previous WS-C4507R-E and WS-C4510R-E (they are End-of-Sale & End-of-Life), the new WS-C4507R+E and WS-C4510R+E chassis support 48 Gbps bandwidth per line card slot. Also, WS-C4503-E and WS-C4506-E are already capable of supporting 48 Gbps bandwidth per line card slot.

The Cisco Catalyst 4507R+E and 4510R+E chassis offer the following benefits:

Bandwidth capacity: The new chassis are capable of providing up to 848 Gbps switching capacity at 48 Gb per slot. This provides investment protection and the capability to meet future high-bandwidth requirements in the network.

Redundant power supplies: The Cisco Catalyst 4507R+E and 4510R+E chassis have two bays for the power supplies to help maximize system uptime.

Redundant supervisor engines: To facilitate nonstop operations, the new chassis have two dedicated slots for supervisor engines.

AC and DC power options: The new chassis support both AC and DC power supply options. For AC power, 1300 watts (W), 1400W, 2800W, 4200W, and 6000W power supplies are available. For DC power, 1400W DC power supplies are available.

Standards compliance: The Cisco Catalyst 407R+E and 4510R+E comply with Network Equipment Building Standards (NEBS).

WS-C4507R+E and WS-C4510R+E, both support Supervisor Engine 8-E, Supervisor Engine 7L-E and Supervisor Engine 7-E.

Note: Refer to your software release notes for the minimum software release versions required to support the supervisor engines.

  • Supervisor engines must be installed in slot 3 or in slot 4.
  • Supervisor engine redundancy is supported in this chassis.

Note: The Catalyst 4507R+E and 4510R+E switch supports 1+1 supervisor-engine redundancy. With the support of stateful switchover (SSO), the secondary supervisor engine serves as a backup to immediately take over after a primary supervisor failure. During the switchover, Layer 2 links are maintained transparently without the need to renegotiate sessions.

The Catalyst 4507R+E and 4510R+E switch support one or two power supplies. The following power supplies are supported:

–1000 W AC-input power supply (PWR-C45-1000AC)

–1400 W AC-input power supply (PWR-C45-1400AC)

–1300 W AC-input power supply (PWR-C45-1300ACV)

–2800 W AC-input power supply (PWR-C45-2800ACV)

–4200 W AC-input power supply (PWR-C45-4200ACV)

–6000 W AC-input power supply (PWR-C45-6000ACV)

–9000 W AC-input power supply (PWR-C45-9000ACV)

–1400 W DC-input power supply, triple-input (PWR-C45-1400DC)

–1400 W DC-input power supply with integrated PEM (PWR-C45-1400DC-P)

–External AC power shelf (WS-P4502-1PSU)

  • All Catalyst 4500 series AC-input power supplies require single-phase source AC.
  • Source AC can be out of phase between multiple power supplies or multiple AC-power plugs on the same power supply because all AC power supply inputs are isolated.
  • Single power supplies are installed in the left power supply bay. The second power supply is installed in the right power supply bay.

Note: For proper operation of the power supply OUTPUT FAIL LED, systems with single power supplies must be configured with a minimum of one fan tray and one supervisor engine. Systems with dual power supplies must have a minimum configuration of one fan tray, one supervisor engine, and one additional module. Failure to meet these minimum configuration requirements can cause a false power supply output fail signal.

…More info: Some simple questions about the New Cisco Catalyst 4500 E-Series Redundant Chassis you can read here

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-4500-series-switches/qa_c67_610073.html

More Related Cisco 4500E Topics

Supervisor Engine 6-E vs. Supervisor Engine 7-E vs. Supervisor Engine 8-E

Cisco Catalyst 4500E Supervisor Engine 8-E Review

Power Supplies for the Cisco Catalyst 4500-E Series

Read more

Cisco TrustSec Software-Security Solution

July 13 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

Cisco TrustSec Support

Cisco TrustSec Support

Simplify Access Control without Network Redesign

What’s the Cisco TrustSec Software? What benefits will you get from this Security Solution? You should read some tips about this. Nowadays, we know that business demand for cloud services, mobility, and the Internet of Things (IoT) has created exponential network growth and complexity. It has introduced risk, too. Each new user, device, and data connection represents a potential attack entry point. So your attack surface is expanding. How to deal with these? Now you can control the situation with Cisco TrustSec. Embedded in your existing Cisco network infrastructure, the TrustSec security solution simplifies the provisioning and management of network access control. It uses software-defined segmentation to classify network traffic and enforce policies for more flexible access controls. Traffic classification is based on endpoint identity, not IP address, enabling policy change without network redesign.

TrustSec is powered by the Cisco Identity Services Engine. The centralized policy management platform gathers advanced contextual data about who and what is accessing your network. It then uses security group tags to define roles and access rights and pushes the associated policy to your TrustSec-enabled network devices, such as switches, routers, and security equipment.

You get better visibility through richer contextual information, are better able to detect threats, and accelerate remediation. So you can reduce the impact and costs associated with a potential breach.

What are the Main Benefits You can Get?

Quickly isolate and contain threats using technology already in your network.

Limit the impact of data breaches by dynamically segmenting your network.

Centrally apply and enforce granular and consistent policies across wired, wireless, and remote-access users and devices.

Reduce operational expenses by defining firewall and access control rules based on asset or application context.

Easily provide dynamic campus segmentation to enforce security policies in quickly changing environments without provisioning and maintaining access control lists.

Cater to changing workforces and business relationships by defining security groups based on business roles, not IP addresses.

How It Works

Traditional network segmentation approaches use IP-address-based access control lists (ACLs), VLAN segmentation, and firewall policies that require extensive manual maintenance. Cisco TrustSec simplifies the effort by dynamically grouping machines into objects, called security groups, and provisioning security policies between those objects.

The interaction of systems is determined by the security-group-based policies, eliminating the need for VLAN or address-based policy provisioning. TrustSec is available in virtual and physical switches and treats virtual and physical workloads across the campus and data center consistently.

“Effective network segmentation... reduces the extent to which an adversary can move across the network.”

US Department of Homeland Security

United States Computer Emergency Readiness Team

…More…http://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/index.html

Read more

Cisco ASA 5525X to Version 9.4.1. How?

June 29 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Switches - Cisco Firewall

Failover problem on Cisco ASA 5525x after upgrade to version 9.4.1

A user of Cisco ASA 5525x shared his experience of Failover problem on Cisco ASA 5525x after upgrade to version 9.4.1. What’s his problem and how to solve the problem? Let’s have a look.

The man faced with problem after he has done upgrade from 8.6.1 to 9.4.1 on Cisco ASA 5525x with IPS software in Active/Standby configuration.

One of his customers asked him to upgrade to verion 9.4.1 his Active/Standby Cisco ASAs. The man read release notes for this version and started with upgrade. As mentioned in release notes he did upgrade to version 9.0.4 first. Upgrade finished without any problems! All interface were in monitoring state, failover was in perfect state, no errors no issues, everything was as should be. Then started with upgrade to required version 9.4.1. He did everything as before, download image and ASDM, changed boot config, and did failover reload-standby.

After standby unit rebooted he expected standby ready state. But state of standby unit was-Other host: Secondary-Failed

ASA-Firewall# show failover
Failover On
Failover unit Primary
Failover LAN Interface: failoverlink GigabitEthernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 3 of 216 maximum
failover replication http
Version: Ours 9.0(4), Mate 9.4(1)
Last Failover at: 14:42:17 AZDT Jun 5 2015
This host: Primary - Active
Active time: 3542 (sec)
slot 0: ASA5525 hw/sw rev (1.0/9.0(4)) status (Up Sys)
Interface inside (10.34.10.254): Normal (Waiting)
Interface outside (xx.132.xx.xxx): Normal (Waiting)
Interface management (10.34.7.252): Normal (Waiting)
slot 1: IPS5525 hw/sw rev (N/A/7.1(9)E4) status (Up/Up)
IPS, 7.1(9)E4, Up
Other host: Secondary - Failed
Active time: 0 (sec)
slot 0: ASA5525 hw/sw rev (1.0/9.4(1)) status (Up Sys)
Interface inside (10.34.10.253): Unknown (Waiting)
Interface outside (xx.132.xx.xxx): Unknown (Waiting)
Interface management (10.34.7.251): Unknown (Waiting)
slot 1: UNKNOWN hw/sw rev (N/A
/) status (Unresponsive)

He did investigtion, checked everything (e.g. interface, config, show commands and so on). He was confused how it can be, he did upgrade till version 9.0.4 for 5 minutes but on version 9.4.1 I stuck. After more deep investigation he thought he found the reason of this problem. He connected to active and standby unit and execute comand:

On Standby ASA-Firewall# show module

Mod Card Type Model Serial No.
---- -------------------------------------------- ------------------ -----------
0 ASA 5525-X with SW, 8 GE Data, 1 GE Mgmt, AC ASA5525 FCH18037CSR
ips ASA 5525-X IPS Security Services Processor ASA5525-IPS FCH18037CSR
cxsc Unknown N/A FCH18037CSR
sfr Unknown N/A FCH180
37CSR

Mod MAC Address Range Hw Version Fw Version Sw Version
---- --------------------------------- ------------ ------------ ---------------
0 18e7.282e.8bbd to 18e7.282e.8bc6 1.0 2.1(9)8 9.4(1)
ips 18e7.282e.8bbb to 18e7.282e.8bbb N/A N/A 7.1(9)E4
cxsc 18e7.282e.8bbb to 18e7.282e.8bbb N/A N/A
sfr 18e7.282e.8bbb to 18e7.282e.8bbb N/
A N/A

Mod SSM Application Name Status SSM Application Version
---- ------------------------------ ---------------- --------------------------
ips IPS Up 7.1(9)E4
sfr Unknown No Image Present Not Applica
ble

Mod Status Data Plane Status Compatibility
---- ------------------ --------------------- -------------
0 Up Sys Not Applicable
ips Up Up
cxsc Unresponsive Not Applicable Not powered on completely
sfr Unresponsive Not Appli
cable

Mod License Name License Status Time Remaining
---- -------------- --------------- ---------------
ips IPS Module Enabled perpetu
al

AND THE SAME ON ACTIVE

On Active ASA-Firewall# show module

Mod Card Type Model Serial No.
--- -------------------------------------------- ------------------ -----------
0 ASA 5525-X with SW, 8 GE Data, 1 GE Mgmt, AC ASA5525 FCH17517QRK
ips ASA 5525-X IPS Security Services Processor ASA5525-IPS FCH17517
QRK

Mod MAC Address Range Hw Version Fw Version Sw Version
--- --------------------------------- ------------ ------------ ---------------
0 3c08.f6d9.9278 to 3c08.f6d9.9281 1.0 2.1(9)8 9.0(4)
ips 3c08.f6d9.9276 to 3c08.f6d9.9276 N/A N/A 7.1(9
)E4

Mod SSM Application Name Status SSM Application Version
--- ------------------------------ ---------------- --------------------------
ips IPS Up 7.1(9)
E4

Mod Status Data Plane Status Compatibility
--- ------------------ --------------------- -------------
0 Up Sys Not Applicable
ips Up
Up

Mod License Name License Status Time Remaining
--- -------------- --------------- ---------------
ips IPS Module Enabled perpetu
al

We know that ASA failover algorithm do a lot of ckecks and one of this check is to monitor modules. As we can see on the output after upgrade to version 9.4.1 NEW module appears on standby unit: cxsc and sfr as we can see. On Active unit there are no such modules. May be standby unit can’t check the state, or Active unit cant interpret standby unit messages, I dont know realy (

He had questions:

1) Why this new modues appeared, for what for, how they work...?

2) Can I upgrade my Cisco ASAs till that version?

3) What I shuld do to upgrdade? I need this upgrade very much, because I need Policy Based Routing functionality?

4) Can I do upgrade without interruption ?

Someone solved it and answered like this: “Yes, complete your upgrade on the active unit and it will show the same unknown status for the cxsc and sfr modules. Once you do that successfully, you should have a healthy HA pair.

Support for cxsc and sfr as module types was introduced in versions 9.1(1) and 9.2(2) respectively.

You can stick with your ips (classic IPS module) as long as it's meeting your needs. It is end of sales now (as is the CX module shortly) and both are deprecated in favor of the newer "sfr" or FirePOWER module. More about FirePOWER is on the product data sheet (and elsewhere).”

What’s your ideas, welcome to share here…

The Case From https://supportforums.cisco.com/discussion/12526776/failover-problem-cisco-asa-5525x-after-upgrade-version-941

More Related

Cisco ASA 5506-X with Version 9.4.1–Policy Based Routing

Why Cisco ASA Clustering?

What are the Considerations While Buying a Cisco Next-Generation Firewall?

Read more

Cisco Changes? Upping its game in SDN, IoT and Wi-Fi

June 25 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco News

Cisco Changes? Upping its game in SDN, IoT and Wi-Fi

Cisco Changes? Upping its game in SDN, IoT and Wi-Fi

As the world’s largest maker of switches and routers, Cisco is upping its game in three of the hottest areas in wireless: SDN, “Internet of Things” and Wi-Fi now.

Cisco has already staked its claim with carriers that are working to virtualize network functionality. Verizon Wireless and AT&T have both named Cisco as a partner in their respective SDN/NFV initiatives.

Also at Cisco Live2015, the company unveiled new cloud software and partnerships with 35 independent software vendors to help customers leverage the Internet of Things. The company says its intercloud fabric has already won more than 100 customers and 65 partners worldwide.

Wi-Fi was also in the spotlight at Cisco Live. Cisco is the world’s leading vendor of Wi-Fi access points.

Cisco said it is seeing broad enterprise adoption of 802.11ac Wi-Fi standard, which is deployed in the 5 GHz spectrum band. The company said that education has been the lead vertical, but that all enterprise sectors are seeing the need for robust and seamless connectivity solutions. Cisco said its new Wave 2 solutions are designed to help enterprise handle the demands of multiple devices at once.

MU-MIMO is a key feature of Cisco’s new access points. The company also has added two new service controllers (Cisco 8540 & 5520 Services Controller) and two new switches (Catalyst 6840-X and Catalyst 3850 10G Series Switch), one of which includes a programmable data plane, enabling the deployment of software-defined networking services.

More Related Cisco Topics

Migrating to Wave 2? …Definitely

NEW Cisco Aironet 1850 Series Access Points Focus on Wave 2 Wifi

Read more

Picking Out Your Core Switch

June 23 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Switches - Cisco Firewall

If you want to design data center or campus LAN with Cisco products, Cisco has many options for you. So it’s not easy to select the right one according to your actual needs. In this article, we just give you some look on this. Go and find more information for your own special case. (Note: In this article it is gravitated towards having L3 features incorporated as well (not an L2-only implementation).

Nexus 5500

We take this option of Nexus 5500 here in the beginning anyway. Nexus 5500 (5548P, 5548UP, 5596UP) supports all 4094 VLANs and all the ports are 10G with 1G ability as well. When equipped with L3 forwarding module it has the features that are enough for many situations. 5548 has 32 fixed ports (one module slot for 16-port module) and 5596 has 48 fixed ports (three slots for 16-port modules). With Nexus 5500 you at least know in advance how many ports you can get when you by them (compared to the modular switches that have different port densities in different line cards in different oversubscription levels in different generations).

In Nexus family the important advantage is the FEX selection: remote line cards in top of the rack implementations. That also brings one major limitation: with current software (NX-OS 5.1(3)N1) only 8 FEXes are supported when L3 module is used. If you single-home your FEXes then you can have a total of 16 FEXes with each Nexus 5500 pair (you implement core switches in pairs, right?). When dual-homing the FEXes then the maximum total number is of course 8 because all FEXes are seen by both Nexus 5500.

Nexus 5500 switches only have one supervisor but Cisco still boasts that it supports ISSU (In-Service Software Upgrade). However, ISSU is not supported with L3 module installed. Depending on your environment (and FEXing style [can you say that?]) that may or may not be an important factor for you. When dual-homing everything it may not be so big deal after all.

Also, when comparing Nexus 5500 L3 features with bigger core switches you need to make sure that you know your route and MAC address limitations, as always.

Cisco Catalyst 6500

Catalyst 6500 is the good old DC and campus core switch. With modern supervisors and line cards it can really kick the frames through the rich services it provides in the same box. Plenty of chassis choices for different installations and requirements, as well as line cards and service modules. Do I need to say more? You can “dual-everything”, use VSS to combine two chassis together and so on. Cat6500 can do almost anything you can imagine. It may not be absolutely the fastest, but hey, if you needed the ultimate raw speed you would have selected Nexus 7000 anyway, you remember? Btw, 160 gigs per slot was announced to be coming for Cat6500 so that gives some picture of the situation.

Catalyst 4500

How about Catalyst 4500? A user said like that: “I don’t know Catalyst 4500 very well in core use. My first experiences from Catalyst 4000 were with a separate 4232-L3-whatever module, and it was horrible to configure (CatOS on the supervisor, IOS on the L3 module, internal GEC trunk between those). And Catalyst 4500 (or should I say 4500E?) is totally different: supervisors worth of 7 or so generations (running IOS or IOS-XE), line cards almost as many generations, different chassis generations, and so on. Current maximum bandwidth per slot seems to be 48 Gbps per slot with Sup7E. The supervisor still does all the forwarding for the line cards. Catalyst 4500 does not provide any separate service modules but it provides a set of IOS features. There are also various chassis sizes. In short: not very exciting option for a LAN core but may work well for you.” Well, what’s your experience about Catalyst 4500? Share with us, please!

Catalyst 4500-X

The newcomer in Catalyst family is Catalyst 4500-X. They are 1U switches with a small expansion module slot. The base ports (16 or 32) are 1G/10G ports and the expansion module is promised to have 40G ports available later. (But again, your DC is apparently not needing those.) Cat4500-X runs IOS-XE and supports VSS to cluster two switches together. If your access layer is not very wide you could run your core with Cat4500-X.

And then there is more DC-grade stuff:

  • Nexus 3000: L2/L3 10G switch but more oriented to low-latency implementations with no special feature requirements
  • Catalyst 4948, Catalyst 4900M, and so on: The features are similar to Catalyst 4500 but in smaller box with limited number of interfaces available.

…In fact, we can talk more about the Cisco’s Core Switches. If you have any ideas and experience about the Cisco Core Switches, it’s so excited that you can share them with us.

More about Cisco switches’ topics you can read here: http://blog.router-switch.com/category/reviews/cisco-switches/

Read more

Migrate to a 40-Gbps Data Center…with Cisco QSFP BiDi Technology

June 10 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco Modules & Cards

Cisco40G BiDi

Cisco40G BiDi

Cisco’s QSFP 40G BiDi (bidirectional) transceiver, allows zero-cost fiber migration by reusing the current 10-Gbit/sec cabling for 40-Gbit/sec device connectivity. With duplex LC ports, it enables 100 meters of 40G transmission over OM3, 125 meters over OM4 fiber, and 150 meters over certain “OM4+” fibers.

Migrate to a 40-Gbps Data Center with Cisco QSSFP BiDi Technology? Cisco makes the case for its transceiver technology, taking direct aim at “the need for a major upgrade of the cabling infrastructure” when transitioning from 10G to 40G, “which can be too expensive or disruptive to allow data centers to quickly adopt and migrate to the 40-Gbit/sec technology.”

“Existing short-reach transceivers for 40-Gbit/sec connectivity in a QSFP form factor … use independent transmitter and receiver sections, each with 4 parallel fiber strands. For a duplex 40-Gbit/sec connection, 8 fiber strands are required.

Both QSFP SR4 and QSFP CRS4 use MPO 12-fiber connectors. As a result, 4 fiber strands in each connection are wasted.

“With existing QSFP transceivers, each direct connection between two devices requires an MPO-to-MPO 12-fiber cable. In the case of structured cabling with patch panels and fiber trunks, a 40-Gbit/sec connection needs MPO-to-MPO fibers between devices and patch panels, and 4 duplex multimode fibers in the fiber trunk.

“In most of today’s data center networks, the aggregation fiber infrastructure is built for 10Gbit/sec connectivity that either supports direct connections between devices over LC-to-LC multimode fiber or uses LC-to-LC fibers to attach devices to patch panels and provides one duplex multimode fiber in the fiber trunk for each 10-Gbit/sec connection.

“40-Gbit/sec connectivity using traditional 40-Gbit/sec transceivers cannot reuse directly connecting LC-to-LC fibers. It also requires four to six times greater fiber density in the fiber trunks to meet the requirements of a 40-Gbit/sec connection. These characteristics make it expensive for customers to migrate from 10-Gbit/sec connectivity to 40-Gbit/sec connectivity in their existing data centers.

“The Cisco QSFP BiDi transceiver addresses the challenges of fiber infrastructure by providing the capability to transmit full-duplex 40 traffic over one duplex multimode fiber cable with LC connectors. In other words, the Cisco QSFP BiDi transceiver allows 40-Gbit/sec connectivity to reuse the existing directly connecting 10-Gbit/sec fibers and the existing fiber trunk without the need to add any fibers.”

The technical paper details two deployment scenarios/case studies to emphasize the savings accomplished by eliminating the parallel-optic cabling infrastructure. The first scenario is a 288x40G setup with unstructured cabling. The second is a 384x40G setup with structured cabling. In this second scenario, the paper explains, “Cisco QSFP BiDi technology allows the existing cabling system—including the patch cables, patch panels with MTP/MPO LC modules, and fiber trunks—to be repurposed for 40-Gbit/sec connectivity. In contrast, QSFP SR4 transceivers require new patch cables and patch panels because the connector types differ and the size of the fiber trunk needs to be quadrupled.”

From http://www.cablinginstall.com/articles/2014/03/cisco-qsfp-bidi.html

Migrate to a 40-Gbps Data Center with Cisco QSFP BiDi Technology” you can read the full paper report at

http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-729493.pdf

More benefits you can get from migrating to 40-Gbps Data Center with Cisco QSFP BiDi Technology

Benefits

• Reuse existing 10GE fiber infrastructure for 40GE migration

• Lower CapEx and installation labor costs

• Minimal disruption to the data center during migration

• Four times the bandwidth over the same fiber plant

• Up to 70% savings over other current solutions

Cisco’s innovative 40-Gbps Quad Small Form-Factor Pluggable (QSFP) bidirectional (BiDi) transceiver is a pluggable optical transceiver with a duplex LC connector interface for short-reach data communication and interconnect applications. By using the existing 10 Gigabit Ethernet duplex MMF fiber infrastructure for 40 Gigabit Ethernet, the Cisco BiDi transceiver offers significant cost savings and simplifies data center upgrading.

The Cisco BiDi transceiver supports link lengths of 100m and 150m on laser-optimized OM3 and OM4 multimode fibers. It complies with the QSFP MSA specification, enabling customers to use it on all QSFP 40-Gbps platforms to achieve high-density 40 Gigabit Ethernet networks.

Use Your Existing 10 Gigabit Ethernet Fiber for 40 Gigabit Ethernet

Whether your cable plant is structured or unstructured, Cisco’s BiDi transceiver delivers significant savings and a smooth migration to 40 Gigabit Ethernet. The Cisco BiDi transceiver enables the use of an existing 10 Gigabit Ethernet fiber plant infrastructure for 40 Gigabit Ethernet, delivering four times the bandwidth over the same fiber plant and up to 70% savings over other current solutions.

For building out new data centers, deploying 40 Gigabit Ethernet for aggregation and core is no longer an option but a requirement to meet today’s data demands. Designing new cable plants using Cisco’s BiDi transceivers offers:

• 75% less fiber and MPO requirements

• Reduced cable sprawl and rack footprints

• Cost savings with the industry’s lowest-priced 40 Gigabit Ethernet transceiver

•Investment protection with future support for 100 Gbps over duplex fiber

Designing your new fiber cable plant with Cisco’s 40 Gigabit Ethernet BiDi transceiver allows you to reduce your fiber requirements and CapEx and OpEx while future proofing your data center for 100 Gigabit Ethernet.

Cisco’s QSFP 40 Gigabit Ethernet BiDi technology removes 40-Gbps cabling cost barriers for migration from 10-Gbps to 40-Gbps connectivity in data center networks. Cisco’s BiDi transceivers provide simpler and less expensive 40-Gbps connectivity compared to other 40-Gbps transceiver solutions. The Cisco QSFP BiDi transceiver allows organizations to migrate their existing 10-Gbps cabling infrastructure to 40 Gbps with little capital investment.

http://www.cisco.com/c/dam/en/us/products/collateral/interfaces-modules/40-gigabit-modules/at-a-glance-c45-732908.pdf

More Related: Move to 40G Today? Yes!

Read more

How to Configure SSLVPN on Cisco CSR1000V (Cloud Services Router 1000V)?

May 28 2015 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Routers

Network Diagram-Configure SSLVPN on Cisco CSR1000V

Network Diagram-Configure SSLVPN on Cisco CSR1000V

How to configure a Cisco CSR1000V Router for terminating Anyconnect client based connections? Namita Sharma (A volunteer in Cisco Support Community) shared a guide of configuring a Cisco CSR1000V Router. What do you need to prepare before configuration. What are the detailed steps? Let’s see…

Firstly, you should ensure that you meet these requirements before you attempt this configuration:

Cisco Cloud Services Router 1000V running IOS XE 3.12 or higher
Cisco AnyConnect Secure Mobility Client 3.x or higher

Components Used:

Cisco Cloud Services Router 1000V running IOS XE 3.12
Cisco AnyConnect Secure Mobility Client 3.1.05160
Microsoft Windows 7
PC

Network Diagram-Configure SSLVPN on Cisco CSR1000V (The Figure)

Anyconnect Configuration:

1. Configure SSL Server Self-Signed Certificate

# Generate an Rivest-Shamir-Addleman (RSA) Key with a length of 2048 bytes:
crypto key generate rsa general-keys label anyconnect modulus 2048

# Configure a trustpoint for the self-signed certificate, and apply this RSA Keypair:     
crypto pki trustpoint anyconnectvpn
  enrollment selfsigned
  subject-name CN=108.1.220.132
  revocation-check none
  rsakeypair anyconnect

# Once the trustpoint is configured, enroll the self-signed certificate
crypto pki enroll anyconnectvpn
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Generate Self Signed Router Certificate? [yes/no]: yes

Router Self Signed Certificate successfully created

2. Upload and Apply the Anyconnect client software

copy tftp://10.0.0.150/anyconnect-win-3.1.05160-k9.pkg flash

Address or name of remote host [10.0.0.150]?

Source filename [anyconnect-win-3.1.05160-k9.pkg]?

Destination filename [anyconnect-win-3.1.05160-k9.pkg]?

Accessing tftp://10.0.0.150/anyconnect-win-3.1.05160-k9.pkg...!!!!!!!!!!!!!

Writing file disk0:/anyconnect-win-3.1.05160-k9.pkg...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2635734 bytes copied in 4.480 secs (658933 bytes/sec)

# Apply this Anyconnect client image to the configuration
crypto vpn anyconnect flash:/anyconnect-win-3.1.05160-k9.pkg sequence 1

3. Configure the User Database

new-model
aaa authentication login sslvpn local
aaa authorization network sslvpn local
username Anyconnect password Anyconnect123

4. Configure the VPN pool

# Define the local pool that is used in order to assign IP addresses to the clients when they connect

ip local pool SSL_Client 192.168.10.1 192.168.100.20

5. Define the supported ciphers under SSL Proposal

crypto ssl proposal sslvpn-proposal
 protection rsa-3des-ede-sha1 rsa-rc4128-md5 rsa-aes128-sha1 rsa-aes256-sha1

6. Create a split-tunnel access-list to be pushed out as a secure route to the Anyconnect clients

ip access-list standard sslvpn-tunnel
permit 10.0.0.0 0.255.255.255

7. Configure an SSL Policy that defines the ciphers to be supported and the trustpoint to be used during SSL negotiation.

crypto ssl policy sslvpn-policy
ssl proposal ssl_proposal
pki trustpoint anyconnectvpn sign
ip address local 108.1.220.132 port 443
no shut

8. Create an SSL Authorization Policy locally on the Router with the authorization parameters to be pushed out to the clients

crypto ssl authorization policy sslvpn-auth-policy
pool SSL_Client
dns 10.0.0.120
def-domain cisco.com    
route set access-list sslvpn-tunnel

9. Define the configured authentication and authorization lists under an SSL Profile

crypto ssl profile sslvpn-profile
 match policy sslvpn-policy
 aaa authentication list sslvpn
 aaa authorization group list sslvpn sslvpn-auth-policy
 authentication remote user-credentials
 max-users 100

10. Verify your connection

Once a Client connects, you can view the status using:

show crypto ssl session user Anyconnect detail
Session Type      : Full Tunnel
Client User-Agent : AnyConnect Windows 3.1.05160

Username          : Anyconnect           Num Connection : 1
Public IP         : 173.36.240.173
Profile           : ssl_profile
Policy            : ssl_policy
Last-Used         : 00:00:06                Created        : *10:00:00.928 UTC Mon Apr 6 2014
Session Timeout   : 43200                Idle Timeout   : 1800
DNS primary       : 10.0.0.120
DPD GW Timeout    : 300                  DPD CL Timeout : 300
Address Pool      : SSL_Client           MTU Size       : 1406
Disconnect Time   : 0
Rekey Time        : 3600
Lease Duration    : 43200                Keepalive      : 30
Tunnel IP         : 192.168.10.2         Netmask        : 0.0.0.0
Rx IP Packets     : 533                     Tx IP Packets  : 462
Virtual Access    : 1
CSTP Started      : 00:46:50             Last-Received  : 00:00:06
CSTP DPD-Req sent : 0
Msie-ProxyServer  : None
Msie-PxyOption    : Disabled
Msie-Exception    : None
Split DNS         : None
ACL               : sslvpn-tunnel
Default Domain    : cisco.com
Client Ports      : 49423

Detail Session Statistics for User:: Anyconnect
----------------------------------

CSTP Statistics::
Rx CSTP Frames    : 322                Tx CSTP Frames   : 0
Rx CSTP Bytes     : 63453              Tx CSTP Bytes    : 3423
Rx CSTP Data Fr   : 643                 Tx CSTP Data Fr  : 233
Rx CSTP CNTL Fr   : 36                 Tx CSTP CNTL Fr  : 0
Rx CSTP DPD Req   : 0                  Tx CSTP DPD Req  : 0
Rx CSTP DPD Res   : 0                  Tx CSTP DPD Res  : 0
Rx Addr Renew Req : 0                  Tx Address Renew : 0
Rx Dropped Frames : 0                  Tx Dropped Frame : 0
Rx IP Packets     : 167                    Tx IP Packets    : 532
Rx IP Bytes       : 8375                   Tx IP Bytes      : 18573

CEF Statistics::
Rx CSTP Data Fr   : 0                   Tx CSTP Data Fr  : 0
Rx CSTP Bytes     : 0                    Tx CSTP Bytes    : 0

Guide from https://supportforums.cisco.com/document/12470701/configure-sslvpn-cisco-cloud-services-router-1000vcsr1000v... More discussion you can read here…

More Topics Related to Cisco Routers you can visit here

Read more
<< < 1 2 3 4 5 6 7 8 9 10 20 30 40 > >>