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

Posts with #cisco & cisco network tag

Cisco Universal PoE, Unleash the Power of Your Network

March 26 2014 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

The IEEE 802.3 Power over Ethernet (PoE) standard sets the maximum power that can be sourced by data terminal equipment (DTE) at 30W. This power is sourced over two pairs out of the four twisted pairs of conductors in a Class D, or better, cabling as specified in ISO/IEC 11801:1995.

Cisco-Universal-PoE.jpg

Cisco Universal Power over Ethernet (UPOE) is a Cisco proprietary technology that extends the IEEE 802.3 PoE standard to provide the capability to source up to 60W of power over standard Ethernet cabling infrastructure (Class D or better).

 Cisco-UPOE.jpg

Why Should I Care About Cisco UPOE?

Power over Ethernet has long been hailed as the single most critical innovation that has revolutionized and expedited the adoption of IP telephony in the enterprise market segment. The power rating for electronic products is trending down through advances in semiconductor technology, and the cost of power itself is trending up. UPOE extends the benefits offered by PoE technology to a much wider range of devices due to the higher power envelope.

Some of the key primary benefits of UPOE are:

Cisco UPOE offers high availability for power and guarantees uninterrupted services; a requirement for critical applications (e911).

Cisco UPOE lowers OpEx by providing network resiliency at lower cost by consolidating backup power into the wiring closet.

Cisco UPOE enables faster deployment of new campus access networking infrastructures by eliminating the need for a power outlet for every endpoint.

Cisco UPOE, in combination with Cisco EnergyWise, helps meet corporate sustainability mandates while lowering energy costs.

What Applications and End Devices Does Cisco UPOE Enable?

Cisco UPOE simplifies network infrastructures, extends high availability for power (PoE resiliency), and delivers lower total cost of ownership for connected environments such as virtual desktop infrastructure (VDI), financial trading floor, enterprise workspace, conference rooms, hospitality guest suites, and retail. Partnerships with industry leaders and in-house development together have resulted in a variety of end devices that are compatible with Cisco UPOE. A few notable end devices are:

Samsung integrated display VDI zero clients

LG Electronic Monitor using UPOE Power Splitter

BT, IPC and SpeakerBus IP Turrets

Cisco Catalyst compact switches

Personal Cisco TelePresence systems

Building management and physical security device

 

What Primary Verticals Does UPOE Address?

UPOE and the associated partner ecosystem (Cisco Developer Network) provide solutions for the following verticals:

Enterprise workspace

Financial trading floor

Hospitality

Retail

Enterprise facilities management

 

What Is the Effect of Cisco UPOE on Heat Dissipated Within the Cabling Infrastructure?

Cisco UPOE is an efficient mechanism for power delivery since it uses all the four twisted pairs of conductors within the Ethernet cabling to deliver power (as opposed to two twisted pairs used by PoE+). This effectively reduces the channel losses by half for the same power delivered over UPOE vs. PoE+. Moreover, the recommendation published by cabling standards — ISO/IEC and TIA/TR-42 as part of formal liaison communiqué with IEEE 802.3 — indicate that UPOE can be supported over the same standard cabling infrastructures that conform to PoE+ requirements.

 

On Which Switching Platform Is Cisco UPOE Being Introduced?

Cisco UPOE is being introduced on the Cisco Catalyst 4500E Series Switches, the most widely deployed modular access switching platform in the industry. The platform has time and again demonstrated leadership in this space, specifically with PoE+, where the Cisco Catalyst 4500 was the first enterprise-class switch to deliver PoE+ compliant switches, two years to the introduction of the IEEE PoE+ standard. UPOE is being introduced on the Cisco Catalyst 4500E platform in the form a new E-Series line card, WS-X4748-UPOE+E, that is compatible with Supervisor Engine 8-E, 7-E, 7L-E and beyond. Cisco UPOE is backward compatible with both PoE (IEEE 802.3af) as well as PoE+ (IEEE 802.3at).

 

What Is the UPOE Scalability on a Cisco Catalyst 4500E System?

Each WS-X4748-UPOE+E line card has a total available power budget of 1440W that can be allocated to the 48 front panel ports with a maximum of 60W per port. This provides the capability to power a maximum of 24 ports simultaneously at 60W. With five such line cards on a single system, the maximum number of ports that can simultaneously source 60W is 116. Moreover, each port also supports LLDP-based dynamic power negotiation capability that permits the end device to communicate the exact power requirement to the switch, which in turn enables smart budgeting of power to maximize the total number of UPOE devices that can be powered on a single line card.

How Is Power Budgeted to Individual Ports?

In addition to extending the power envelope defined by the IEEE 802.3 standard, UPOE also extends the LLDP-PoE dynamic power negotiation protocol defined by IEEE 802.3 to facilitate mutual identification and dynamic budgeting of power to individual ports. Additionally, UPOE also provides the users the capability to statically configure port power budget to enable devices that do not support the LLDP-PoE extensions for UPOE support.

How Does UPOE Tie in with Cisco’s Overall Enterprise Campus Access Strategy?

With the introduction of the Supervisor Engine 8-E, 7-E and 7L-E, the Cisco Catalyst 4500E has become Cisco’s leading modular campus access platform. The platform not only offers unprecedented switching bandwidth with line-rate switching to all user access ports and 10G uplinks but also has been the first platform to deliver next-generation services such as sub second ISSU, Flexible Netflow, Cisco TrustSec security, Wireshark as a hosted application, and medianet innovations. High availability and lower TCO continue to be the underlying goals for the platform. Cisco UPOE extends high availability for power while minimizing both CapEx and OpEx involved with power delivery.

 More Cisco Network Topics:

Cisco Catalyst 4500 Series Line Cards Overview

Need Cisco Inline Power, POE or the New POE+?

FAQ: Power over Ethernet (PoE) Power Requirements

Read more

Cisco Access Control Lists (ACLs)

February 13 2014 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

Access control lists (ACLs) can be used for two purposes on Cisco devices: to filter traffic and to identify traffic.

Cisco provides basic traffic filtering capabilities with access control lists (also referred to as access lists). Access lists can be configured for all routed network protocols (IP, AppleTalk, and so on) to filter the packets of those protocols as the packets pass through a router.

You can configure access lists at your router to control access to a network: access lists can prevent certain traffic from entering or exiting a network.

Access lists filter network traffic by controlling whether routed packets are forwarded or blocked at the router's interfaces. Your router examines each packet to determine whether to forward or drop the packet, on the basis of the criteria you specified within the access lists.

Access list criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol, or other information.

Note that sophisticated users can sometimes successfully evade or fool basic access lists because no authentication is required.

Why do you need to configure Cisco ACLs? For example, you can use access lists to restrict contents of routing updates or to provide traffic flow control. One of the most important reasons to configure access lists is to provide security for your network.

You should use access lists to provide a basic level of security for accessing your network. If you do not configure access lists on your router, all packets passing through the router could be allowed onto all parts of your network.

Access lists can allow one host to access a part of your network and prevent another host from accessing the same area. In the follow-up figure, host A is allowed to access the Human Resources network, and host B is prevented from accessing the Human Resources network.

Using-Traffic-Filters-to-Prevent-Traffic-from-Being-Routed-.jpg

You can also use access lists to decide which types of traffic are forwarded or blocked at the router interfaces. For example, you can permit e-mail traffic to be routed, but at the same time block all Telnet traffic.

Access lists should be used in "firewall" routers, which are often positioned between your internal network and an external network such as the Internet. You can also use access lists on a router positioned between two parts of your network, to control traffic entering or exiting a specific part of your internal network.

To provide the security benefits of access lists, you should at a minimum configure access lists on border routers—routers situated at the edges of your networks. This provides a basic buffer from the outside network, or from a less controlled area of your own network into a more sensitive area of your network.

On these routers, you should configure access lists for each network protocol configured on the router interfaces. You can configure access lists so that inbound traffic or outbound traffic or both are filtered on an interface.

Access lists must be defined on a per-protocol basis. In other words, you should define access lists for every protocol enabled on an interface if you want to control traffic flow for that protocol.

Full Guide of Cisco Access Lists from http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html

More Related Cisco ACLs Topics:

Cisco ACL In and Out Questions

Read more

Cisco Business Edition 6000 General Qs

November 26 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

Cisco Business Edition 6000 (BE 6000) is a packaged solution optimized for medium-sized business requirements. It is a combination of Cisco Unified Communications applications on the Cisco Unified Computing System (Cisco UCS) that offers midsize customers’ business agility and reduced TCO through server consolidation, operational efficiency and scalability, improved business continuity, and greater investment leverage.

Cisco BE 6000 consists of the following foundational elements:

• Cisco UCS C220 M3 Rack-Mount Server

• Cisco UC Virtualization Hypervisor

• Cisco Licensing

• Cisco Unified Communications Manager

• Cisco Instant Messaging and Presence with the Cisco Jabber messaging integration platform

• Cisco Unity Connection

• Cisco Prime Collaboration Provisioning

You can optionally install the following applications to the BE 6000 solution:

• Advance Video with Cisco TelePresence conferencing application

• Cisco Unified Contact Center Express

• Cisco Emergency Responder

• Cisco Paging Server

• Cisco Unified Provisioning Manger (older option of management application)

• Cisco Unified Attendant Console (not preloaded; needs to be purchased separately)

In addition, Cisco BE 6000 integrates with cloud-based Cisco WebEx Software-as-a-Service offerings including WebEx Connect IM and Presence, as well as WebEx Web Conferencing.

Cisco BE 6000 comes with two hardware options of Cisco UCS 220 M3 Server:

1. The Medium Density server supports a maximum of five virtual machines (four collaboration applications and one management application) - support for a maximum of 1200 devices.

2. The High Density server supports a maximum of nine virtual machines (eight collaboration applications and one management application) - support for a maximum of 2500 devices.

Note: Both options support a maximum 0f 1000 users.

What is the difference between Cisco Business Edition 6000 and generic unified communications applications on Cisco UCS ("UC on UCS")? The table will show you the Differences between Cisco BE 6000 and Deployments with Unified Communications Applications on Cisco UCS

Differences-Between-Cisco-BE-6000-and-Deployments-with-Unif.jpg

Maximum Capacities of Cisco BE 6000

Attribute

Capacity

Maximum number of users

1000 users

Maximum number of mailboxes and voicemail ports

1000 mailboxes and 24 voicemail ports per server

Message storage

Approximately 72,944 G.711 codec minutes

Number of contact center agents

100 agents and 10 supervisors

Number of presence users

1000 presence users

Number of devices supported

Medium Density server: 1200

High Density server: 2500

Maximum number of co-resident applications per server

Medium Density server: Five applications (4 collaboration + 1 management)

High Density server: Nine applications (8 collaboration + 1 management)

Busy-hour call attempts

5000

About Deployment Model-Cisco Business Edition 6000

Cisco BE 6000 supports fully featured redundancy for both LAN and WAN environments. You can deploy a redundant server for Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, and Cisco Unified Contact Center Express applications in a remote location over your WAN.

The Cisco BE 6000 Medium Density server supports up to five co-resident applications. However, the Cisco Virtualization Hypervisor software with license comes standard with Cisco BE 6000, and is entitled for two CPU sockets and 16 GB of virtual memory to deploy additional applications. Following are configuration scenario examples:

Scenario 1: Fully redundant configuration

• Cisco BE6000 Medium Density server 1: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, Cisco Unified Contact Center Express, and Cisco Unified Provisioning Manager (primary)

• Cisco BE6000 Medium Density server 2: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, and Cisco Unified Contact Center Express (secondary)

• Cisco BE6000 Medium Density server 3: Cisco Unified Attendant Console

Scenario 2: Redundancy for Cisco Unified Communications Manager with Cisco Unified Contact Center Express only

• Cisco BE6000 Medium Density server 1: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Presence, Cisco Unified Contact Center Express, and Cisco Unified Provisioning Manager (primary)

• Cisco BE6000 Medium Density server 2: Cisco Unified Communications Manager, Cisco Unified Attendant Console, and Cisco Unified Contact Center Express (secondary)

Scenario 3: Cloud-based IM and presence

• Cisco BE6000 Medium Density server 1: Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Contact Center Express, Cisco Unified Attendant Console, and Cisco Unified Provisioning Manager (primary)

• Cisco BE6000 Medium Density server 2: Cisco Unified Communications Manager, Cisco Unity Connection, and Cisco Unified Contact Center Express (secondary)

Optional Cisco Virtualization Foundation Edition is entitled for two CPU sockets and 32 GB of virtual memory and enables the VMware vCenter compatibility feature.

Cisco Business Edition 6000 supports more than two nodes in the cluster. You can deploy Cisco BE 6000 with more than three nodes in the cluster as long as the user count does not exceed 1000 users.

Is Cisco Prime Collaboration Provisioning bundled with Business Edition 6000 different from the enterprise version of Cisco Prime Collaboration Provisioning? I have been using Cisco Unified Provisioning Manager Business Edition to manage Business Edition 6000. How do I migrate to the new management application Cisco Prime Collaboration Provisioning? Can I install Cisco Business Edition 6000 on a different specifications-based Cisco UCS Server or on a third-party server? Can I install any third-party application server on Cisco Business Edition 6000 hardware? Etc. More Qs about Cisco BE6000 and its licensing options you can read the full page Cisco Business Edition 6000 Q&A

More Cisco BE6000 REVIEWS:

Cisco BE6000 (Business Edition 6000) Solution

Read more

Common Issues with ASA 8.6 Version

November 14 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

In this article it describes the issue faced by a user on ASA 8.6.

Here the Problem is:

User is using ASA 5525 with 8.6 versions, and he is trying to ping through different interfaces, however he is not able to do that. The test results are mentioned below:

     Can PING between the outside interface and the next hop (same subnet)

     Cannot PING between the inside interface and the next hop (same subnet)

     Cannot PING between the DMZ interface and the next hop (same subnet)

Please see below configuration for firewall for reference.

interface GigabitEthernet0/0

speed 100

duplex full

nameif outside

security-level 0

ip address 16.x.x.x 255.255.255.248

interface GigabitEthernet0/1

no nameif

security-level 0

no ip address

!

interface GigabitEthernet0/1.16

vlan 16

nameif inside

security-level 100

ip address 17.x.x.x 255.255.255.0

interface GigabitEthernet0/3

no nameif

security-level 0

no ip address

!

interface GigabitEthernet0/3.69

vlan 69

nameif dmz

security-level 50

ip address 18.x.x.x 255.255.255.0

access-list o_inside extended permit icmp any any

access-list o_inside extended permit icmp any any echo

access-list o_inside extended permit icmp 17.x.x.x (Inside interface) 255.255.0.0 18.x.x.x (DMZ interface) 255.255.255.0 

access-list o_inside extended permit icmp 17.x.x.x (Inside interface) 255.255.0.0 18.x.x.x (DMZ interface) 255.255.255.0

 

access-list o_dmz extended permit icmp any any

access-list outside extended permit icmp any any

access-list outside extended permit icmp any any echo-reply

icmp permit any outside

icmp permit any dmz

policy-map global_policy

class inspection_default

inspect icmp

inspect icmp error

 

route inside 17.x.0.0 (Whole inside interface subnet) 255.255.0.0 17.x.x.x (Internal Network) 1

route dmz 17.x.x.0 (Internal) 255.255.255.0 18.x.x.x (DMZ Nework) 1

route outside 18.x.x.0 (DMZ) 255.255.255.0 16.x.x.x (Outside Network) 1

User wants to know what should be added to achive the above mentioned result.

 

Solution:

ASA should by default without any configurations accept ICMP on its interface.

Check the output of "show arp" and see if you can see the IP address (and the MAC address) of the host/router you are trying to ping.

 

The 4 "static" configurations above are pretty basic but 2 of them are Static Identity NAT configurations that you probably won’t need in the new software

The below 2 configurations probably won’t need any corresponding configuration in the new ASA/software since the traffic should go through wihtout NAT configurations.

static (dmz,inside) 192.168.1.85 192.168.1.85 netmask 255.255.255.255

static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.255.0.0

 

The below Static NAT configurations you can easily convert using Auto NAT / Network Object NAT. Use "object" names that describe the setup better, use generic "object" names.

static (dmz,outside) 200.190.70.87 192.168.1.56 netmask 255.255.255.255

static (dmz,outside) 200.190.70.85 192.168.1.85 netmask 255.255.255.255

object network STATIC-1

host 192.168.1.56

nat (dmz,outside) static 200.190.70.87

 

object network STATIC-2

host 192.168.1.85

nat (dmz,outside) static 200.190.70.85

 

The best way to find possible problems with the ASA configurations is to use the "packet-tracer" command. This would tell you if some traffic is getting blocked by ACL or if the traffic is failing because of NAT

 

For a connection coming from behind "outside" you can use this format of the command

packet-tracer input outside tcp <source ip> 12345 <server nat ip> <destination port>

To test anything else you naturally just switch the "input <interface name>" to the one where the traffic is sourced from. You will naturally also have to check whether you need to use "tcp" or "udp" and also select a source/destination IP/port.

 

Taking the output of the following commands should help you to troubleshoot possible problems

 

You could take "packet-tracer" command output of both of the above mentioned cases. For example testing connectivity from "outside" to the "dmz" server. And the previous problem with testing connection from "inside" to "dmz" server.

 

If you are doing Dynamic PAT from "inside" to "dmz" then you should remove the above "static" commands that refer to "(inside,dmz)" then user wouldnt be able to connect from "dmz" to those "inside" IP addresses (of those static commands). This is the main reason why Dynamic PAT is not encouraged between local interfaces. It causes complexity for the NAT configurations when user have to add extra NAT configurations to override the possible problems caused by the Dynamic PAT

 

For the "management" interface you probably need any new NAT configuration.

 

The Dynamic PAT from "inside" to "dmz" means that you would need some Static Identity NAT configuration mentioned above also in the new software otherwise the ASA would drop the connection attempts.

nat (inside,dmz) after-auto source dynamic inside-pat-source dmz-pat-global

 

More Related Cisco ASA Topics:

Cisco Released Cisco ASA Software 9.0

Cisco ASA 8.4 vs. Typical NAT/PAT Configuration

Read more

Multiple Vulnerabilities in Cisco Products Could Cause Remote Denial of Service

October 18 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

Multiple vulnerabilities have been discovered in several Cisco products, including Cisco Adaptive Security Appliance (ASA) 5500 Series, Cisco Catalyst 6500 Series ASA and Firewall Services Module (FWSM), Cisco 7600 Series Routers ASA and FWSM, Cisco ASA 1000V Cloud Firewall, as well as Cisco 1000 Series Aggregation Services Routers (ASR) running Cisco IOS XE. These products provide firewall, intrusion prevention, remote access, and other services. Successful exploitation of these vulnerabilities could result in denial of service conditions or reboot of the affected device.

SYSTEMS AFFECTED:

Cisco Adaptive Security Appliance (ASA) Software for:

Cisco Firewall Services Module (FWSM) Software for:

Cisco IOS XE Software for:

  • Cisco 1000 Series Aggregation Services Routers (ASR)

RISK:

Government:

  • Small government entities: High
  • Large and medium government entities: High

Businesses:

  • Large and medium business entities: High
  • Small business entities: High

 

Home users: N/A

 

DESCRIPTION:

Multiple Cisco products are vulnerable to a remote Denial of Service condition. The details of each vulnerable Cisco product are provided below.


Cisco Adaptive Security Appliance (ASA) 5500 Series, Cisco Catalyst 6500 Series ASA and Firewall Services Module (FWSM), Cisco 7600 Series Routers ASA and FWSM, Cisco ASA 1000V Cloud Firewall

 

To exploit these vulnerabilities, an attacker needs to create a specially crafted packet that will cause a denial of service condition when processed by the appliance. Affected versions of Cisco ASA and FWSM software will vary depending on the specific vulnerability.

 

The details of the vulnerabilities are as follows:

  • Cisco ASA and Cisco FWSM are prone to a remote denial-of-service vulnerability because they fail to properly process an incoming IKE version 1 message. An attacker can exploit this vulnerability by sending a crafted IKE message, causing a reload of an affected device, denying service to legitimate users. Switching to IKE version 2 will mitigate this vulnerability. This issue is being tracked by Cisco Bug IDs CSCub85692 and CSCud20267 (CVE-2013-1149).
  • Cisco FWSM for the Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers is prone to a denial-of-service vulnerability due to the incorrect processing of URLs. Specifically, this issue occurs when clients make requests through the auth-proxy feature. An attacker can exploit this issue to cause a vulnerable device to reload, triggering a denial-of-service condition. Disabling AAA for network access control and HTTP(S) listening ports to authenticate network users, if feasible, will mitigate this vulnerability. This issue is tracked by Cisco Bug ID CSCtg02624 (CVE-2013-1155).
  • Cisco Adaptive Security Appliance (ASA) is prone to a remote denial-of-service vulnerability. Specifically, this issue occurs in the URL processing code of the authentication proxy feature. An attacker can exploit this vulnerability by sending a crafted URL, causing a reload of an affected device, denying service to legitimate users. This issue is being tracked by Cisco Bug ID CSCud16590 (CVE-2013-1150).
  • Cisco Adaptive Security Appliance (ASA) is prone to a remote denial-of-service vulnerability due to an implementation error in the code that validates the digital certificates used during authentication. An attacker can exploit this issue by using a crafted certificate to trigger an authentication operation on an affected device, causing a reload of an affected device, denying service to legitimate users. This issue is being tracked by Cisco Bug ID CSCuc72408 (CVE-2013-1151)
  • Cisco Adaptive Security Appliance (ASA) is prone to a remote denial-of-service vulnerability that occurs in the DNS inspection engine code. Specifically, this issue occurs because of improper processing of certain fields in DNS messages. An attacker can exploit this issue by sending a crafted DNS message, causing a reload of an affected device, denying service to legitimate users. Disabling DNS inspection, if feasible, will mitigate this vulnerability. This issue is being tracked by Cisco Bug ID CSCuc80080 (CVE-2013-1152).

 

Cisco IOS XE Software for Cisco 1000 Series Aggregation Services Router (ASR).

To exploit these vulnerabilities, an attacker needs to create a specially crafted packet that will cause a denial of service when processed by the software. Affected versions of Cisco IOS XE Software for 1000 Series ASR will vary depending on the specific vulnerability.

 

The details of the vulnerabilities are as follows:

  • Improper handling of fragmented IPv6 multicast and IPv6 MVPN traffic by Cisco 1000 Series ASR with ASR1000-ESP40 or ASR1000-ESP100 may allow an attackers to cause a reload of the affected devices, denying service to legitimate users. This issue is being tracked by Cisco Bug IDs CSCtz97563 and CSCub34945 (CVE-2013-1164).
  • Improper handling of specific L2TP packets by Cisco 1000 ASR may allow an attackers to cause a reload of the affected devices, denying service to legitimate users. Repeated attacks will result in a sustained denial of service. This issue is being tracked by Cisco Bug ID CSCtz23293 (CVE-2013-1165).
  • Improper handling of packets by Cisco 1000 Series ASR configured for bridge domain interface (BDI) may allow attackers to cause a reload of the affected devices, denying service to legitimate users. Repeated attacks will result in a sustained denial of service. This issue is being tracked by Cisco Bug ID CSCtt11558 (CVE-2013-1167).
  • Improper handling of a large number SIP packets by Cisco 1000 Series ASR when configured for VRF-aware NAT and SIP ALG may allow an attackers to cause a reload of the affected devices, denying service to legitimate users. Repeated attacks will result in a sustained denial of service. This issue is being tracked by Cisco Bug ID CSCuc65609 (CVE-2013-1166).

 

RECOMMENDATIONS:

We recommend the following actions be taken:

  • Upgrade vulnerable Cisco products immediately after appropriate testing.
  • Consider migrating from IKE version 1 to IKE version 2.

 

REFERENCES:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130410-asa

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130410-fwsm

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130410-asr1000

 

More Related Topics:

Cisco Patches Flaw in Security Appliances, Switches, Routers

Cisco IOS Updates Fix Eight Denial of Service Vulnerabilities

Cisco to Unveil New Catalyst Access Switch to Converge Wired&Wireless Networking

Read more

A Basic ASA Setup for a Native IPv6 Network

September 3 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

For the ASA firewall, IPv6 feature support has been available and can be set up quickly. In this article it focuses on a basic ASA setup for a native IPv6 network.   As you will see, there are very few commands required to have your ASA firewall join an IPv6 ready network.

Here is a quick way to configure up your ASA firewall for IPv6 connectivity. 

BASIC CONFIGURATION

STEP#1-Enable IPv6 on the interface and configure up the global IPv6 address.

interface vlan 2

ipv6 enable

ipv6 address 2001:db8:2:3::1/64

 

This will assign the IPv6 global address to the interface.  When you enter IPv6 enable, a link local address is automatically generated (this is based on your mac address).  With the IPv6 address command above, you are manually specifying the global, however the ASA also allows for autoconfig which will receive stateless configurations based on RA router advertisement messages. 

 

For more details, you can review the following reference guide document:

http://www.cisco.com/en/US/docs/security/asa/asa83/command/reference/i3.html#wp1897428

 

STEP#2-Verify IPv6 configuration.

show ipv6 interface

Example:

outside is up, line protocol is up

  IPv6 is enabled, link-local address is fe80::21e:7aff:fe11:45c 

  Global unicast address(es):

            2001:db8:2:3::1, subnet is 2001:db8:2:3::/64 

  Joined group address(es):

            ff02::1

            ff02::2

            ff02::1:ff00:1

            ff02::1:ff11:45c

  ICMP error messages limited to one every 100 milliseconds

  ICMP redirects are enabled

  ND DAD is enabled, number of DAD attempts: 1

  ND reachable time is 30000 milliseconds

  ND advertised reachable time is 0 milliseconds

  ND advertised retransmit interval is 1000 milliseconds

  ND router advertisements are sent every 200 seconds

  ND router advertisements live for 1800 seconds

  Hosts use stateless autoconfig for addresses

 

STEP#3-Define an IPv6 default route.

ipv6 route outside ::/0 next_hop_ipv6_addr

Using ::/0 is equivelant to “any”.  The IPv6 route command is functionally similar to the IPv4 route.

 

STEP#4-Define IPv6 access-lists (optional).

IPv6 access-lists are functionally the same as IPv4.  They are parsed sequentially and have an implicit deny at the end.

 

Example:

ipv6 access-list test permit tcp any host 2001:db8::203:A0FF:FED6:162D

access-group test in interface outside

 

The above is permitting traffic to a specific server 2001:db8::203:A0FF:FED6:162D.

 

Securing the Firewall:

If you plan to configure auto-config for the IPv6 global address on the ASA, you should limit the amount of router advertisements (RA) to known routers in your network.  This will help prevent the ASA from being auto configured from unknown routers.

 

ipv6 access-list outsideACL permit icmp6 host fe80::21e:7bff:fe10:10c any router-advertisement

ipv6 access-list outsideACL deny icmp6 any any router-advertisement

access-group outsideACL in interface outside

interface vlan2

nameif outside

security-level 0

ipv6 address autoconfig

ipv6 enable 

The above access-list when applied on the ASA will limit receiving router advertisements (RA) from only the router specified.  All other RAs will be denied.

 

If you wish to prevent the ASA from sending out router advertisements (RA) on a specific interface, you may suppress them with the following interface command:

interface vlan2

ipv6 nd suppress-ra 

Neighbor discovery will continue to be operational even though RA suppression has been configured.

 

For further information, please check out the following documentation on cisco.com:

ASA 8.3 IPv6 configuration guide:

http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/config.html

ASA 8.3 IPv6 command reference:

http://www.cisco.com/en/US/docs/security/asa/asa83/command/reference/i3.html

Reference from https://supportforums.cisco.com/docs/DOC-15973

More Related:

How to Enable IPv6 Support on a Cisco Catalyst 3560 Switch?

First Hop Redundancy Protocols in IPv6 HSRP + GLBP

What Hardware Vendor IPv6 Support

IPv6 OSPF/v3: Case Study

Cisco IPv6 Static Address Configuration Tech Tips

Read more

One Platform Kit (onePK) for Developers

August 6 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

Cisco onePK, short for One Platform Kit, is an easy-to-use developer’s toolkit for innovation, automation, and service creation. onePK delivers the benefits of network programmability on Cisco routers and switches. onePK allows you to tie your network more effectively to ever changing application needs, providing improved business agility and decreased opex. onePK allows your network’s power to be unleashed in new ways for a faster, more flexible, and intelligent infrastructure.

What Problems Does It Help Solve?

Need for deeper access to information stored within network devices

Need to exercise greater or more precise control over flows and routes

Need to extract particular packets for modification and reinjection

Need to improve quality of service based on custom parameters

Need to add services to the network without making a huge infrastructure investment

Need to allow programmers to augment network operation in response to application-specific business logic

Need to bridge the operational gap between disparate systems

Need to deploy a gateway or network service without adding hardware or constraining functionality based on physical connectivity

 

Applications of onePK for Specfiic Customer Types

Improve visibility and control over network operations (all market segments)

Reduce hardware footprint for new services or gateway functions (enterprise and service provider)

Automate new service provisioning for customers (cloud service provider)

Deliver more consistent quality of service to multimedia service customers (service provider)

Achieve higher levels of data security when transmitting over untrusted networks (government/defense)

Improve the perceived speed of the application to users of hyperscale data center services (for example, social media websites)

Orchestrate new services or additional resources more quickly and cost-effectively (data centers and service providers)

Modify packets to enhance security, reliability, or performance for customers (data centers and service providers)


One Platform Kit (onePK)

onePK is a flexible development environment that supports C or Java programs. Your source code can be written and compiled using any tools that you want. The onePK infrastructure is built right into the operating system of all Cisco platforms and communicates with the onePK presentation layer, supporting the developer’s C or Java programs.

onePK-Language-of-Choice.jpg

This architecture gives users maximum deployment flexibility. onePK along with Cisco’s container support allows the user to host applications on the device processor board, a services blade available with some Cisco platforms or a separate server, that communicates to the onePK infrastructure using a secure communications channel.

Because the API is consistent across all Cisco platforms, the developer can write an application once and have that application deployed on any switch or router.

 

What Are the Benefits of onePK?

Build, automate, improve: Create new or improve existing applications and services, increase productivity

Speed and faster adaptability: Provide flexibility for rapidly changing business needs and reduced operating costs

Extend: Extend the functionality of your network

New Revenue Opportunities: Provide monetization of new applications or services, create services more quickly with code that you can write once and run anywhere

 

Simplicity, integration, and the power of choice

Utilize with your programming language and tools of choice

Run it on any server or right in the network device

 

More Related:

Cisco IOS Versions and Naming Overview

Read more

IPv6 OSPF/v3: Case Study

May 20 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

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.

IPv6-OSPFv3-Case-Study01.png

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.

Prerequisite

Topology Diagram

IPv6-OSPFv3-Case-Study02.png

Configuration

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.

IPv6-OSPFv3-Case-Study03.png

IPv6-OSPFv3-Case-Study04.png

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".

IPv6-OSPFv3-Case-Study05-copy-1.png

IPv6-OSPFv3-Case-Study06.png

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.

IPv6-OSPFv3-Case-Study07.png

IPv6-OSPFv3-Case-Study08.png

Note: Stub Router R2, is receives only the Intra/Inter OSPF routes.

References

Implementing OSPF for IPv6

---DOC from https://supportforums.cisco.com/docs/DOC-25487

More Related OSPF Tips:

How to Troubleshoot OSPF?

OSPF, How to Configure OSPF in the Cisco IOS?

How to Configure OSPF in a Single Area?

Read more

OSPF Neighborship Troubleshooting

May 17 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

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:

  1. The devices must be in the same area
  2. The devices must have the same authentication configuration
  3. The devices must be on the same subnet
  4. The devices hello and dead intervals must match
  5. 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.

OSPF-Neighborship-Troubleshooting01.jpg

Figure 1-Simple Lab

 

Mismatched Areas

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).

OSPF-Neighborship-Troubleshooting02.jpg

Figure 2-Mismatched Areas

 

Authentication Mismatch

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.

OSPF-Neighborship-Troubleshooting03.jpg

Figure 3-Authentication Mismatch

 

Subnet 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.

OSPF-Neighborship-Troubleshooting04.jpg

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.

OSPF-Neighborship-Troubleshooting05.jpg

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.

OSPF-Neighborship-Troubleshooting06.jpg

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:

How to Troubleshoot OSPF?

Read more

the Difference between a Layer-3 Switch and a Router

May 2 2013 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco & Cisco Network

In general, a Layer-3 switch (routing switch) is primarily a switch (a Layer-2 device) that has been enhanced or taught some routing (Layer 3) capabilities. A router is a Layer-3 device that simply does routing only. In the case of a switching router, it is primarily a router that may use switching technology (high-speed ASICs) for speed and performance (as well as also supporting Layer-2 bridging functions).

As illustration, here are some examples
Layer-2 switches
Cisco: Catalyst 2950, 2960 series

Layer-3 switches or routing switches
Cisco: Catalyst 3550, 3560, 3750, 4500, 6500 series
Juniper: EX series

Routers (with some bridging and/or security features) or switching routers
Cisco: 1800, 1900, 2600, 2800, 2900, 3700, 3800, 3900, 7200, 7600, ASR 1000 series
Juniper: MX series, J series, M series

Several factors have created significant confusion surrounding the subject of Layer-3 switch and Layer-3 switching. Some of this bewilderment arises from the recent merging of several technologies. In the past, switches and routers have been separate and distinct devices. The term switch was reserved for hardware-based platforms that generally functioned at Layer-2. For example, ATM switches perform hardware-based forwarding of fixed-length cells whereas Ethernet switches use MAC addresses to make forwarding decisions. Conversely, the term router has been used to refer to a device that runs routing protocols to discover the Layer-3 topology and makes forwarding decisions based on hierarchical Layer-3 addresses. Because of the complexity of these tasks, routers have traditionally been software-based devices. Routers have also performed a wide variety of "high touch" and value added features such as tunneling, data-link switching (DLSw), protocol translation, access lists, and Dynamic Host Configuration Protocol (DHCP) relay.

To understand better of switching router and routing switch differences, following is an illustration. In early Cisco switches (i.e. Catalyst 3500 switches), there are only basic Layer-2 capabilities such as bridging and switching. With newer models (i.e. Catalyst 3550 or 3560 switches), there are also some routing capabilities such as terminating multiple Layer-3 interfaces and running dynamic routing protocol. In router world, early Cisco routers (i.e. 1600 or 2500 model), there are only basic Layer-3 capabilities such as running dynamic routing protocol, terminating Serial ports, and running non-IP protocols such as IPX and SNA. With newer models (i.e. 1700, 1800, 2600 or 2800 models), there are also some Layer-2 capabilities such as bridging and switching. In addition there are some WIC (WAN Interface Cards) and NM (Network Modules) with Ethernet ports supporting bridging and switching in those newer router models even further such as WIC-4ESW Ethernet Switching card for 1700 series, HWIC-4ESW High-Density Ethernet Switching card for 1800 and 2800 series, and NM-16ESW Ethernet Switching module for 2600 and 2800 series.

As a broad category, routing switches use hardware to create shortcut paths through the middle of the network, by bypassing the traditional software-based router. However, unlike traditional routers that utilize general-purpose CPUs for both control-plane and data-plane functions, Layer-3 switches use high-speed application specific integrated circuits (ASICs) in the data plane. By removing CPUs from the data-plane forwarding path, wire-speed performance can be obtained. This results in a much faster version of the traditional router. In Cisco world, this routing switch ASIC technology implementation as example applies to Catalyst 6500 switch series. These kind of switches are typically blade or module based switch which you have to specify which "switch brain" (called Supervisor Engine in Cisco world) and which port modules you like the switch to have.

In the case of a switching router as primarily a router that uses switching technology (high-speed ASICs) for speed and performance (as well as also supporting Layer-2 bridging functions), there are Cisco 7600 series and Juniper MX series routers as examples. These kind of routers are typically blade or module-based router which you have to specify which "router brain" (also called Supervisor Engine in Cisco world) and which port modules you like the router to have.

Further, the Cisco 7600 series router Supervisor Engine modules are compatible with the Cisco Catalyst 6500 series switch due to identical architecture between the router and the switch. In other words, you could use the same Supervisor Engine model on either Cisco 7600 series router or Catalyst 6500 series switch.

Some network topologies as illustrations
1. Single Router

                                        Internet
                                            |
                                            | 1.1.1.0/24
                                            |
                                         Router
                                            |
                             LAN 1 with Unmanaged Switch (UM)
                                       10.0.1.0/24


2. Single Router with multiple LAN subnets

                                        Internet
                                            |
                                            | 1.1.1.0/24
                                            |
                                         Router --- LAN 2 with UM 10.0.2.0/24
                                            |
                                      LAN 1 with UM
                                       10.0.1.0/24


3. Single Router with single connection to a switch and with multiple LAN subnets (also known as "Router on A Stick" design)

                                        Internet
                                            |
                                            | 1.1.1.0/24
                                            |
                                         Router
                                            *
                                            * Single Connection to a Switch using feature  called Trunking
                                            *
                                  Layer-2 Managed Switch
                                    |       |       |
                                    |     LAN 2     |
                                    |    with UM    |
                                    |  10.0.2.0/24  |
                                    |               |
                                  LAN 1           LAN 3
                                 with UM         with UM
                               10.0.1.0/24     10.0.3.0/24


4. Single Router with Layer-3 Switch and with multiple LAN subnets

                                        Internet
                                            |
                                            | 1.1.1.0/24
                                            |
                                     Internet Router
                                            |
                                            | 10.0.0.0/24
                                            |
                                      Layer-3 Switch
                                     |     |       |
                                     |   LAN 2     |
                                     |   with UM   |
                                     | 10.0.2.0/24 |
                                     |             |
                                   LAN 1         LAN 3
                                  with UM       with UM
                                10.0.1.0/24   10.0.3.0/24


5. Multiple Routers with multiple unmanaged (dumb) switches and with multiple LAN subnets

                                        Internet
                                            |
                                            | 1.1.1.0/24
                                            |
                                     Internet Router
                                            |
                                            | 10.0.0.0/24
                                            |
                                   Unmanaged Switch (UM)
                                     |     |       |
                                     |  Router 2   |
                                     |     |       |
                                     |   LAN 2     |
                                     |   with UM   |
                                     | 10.0.2.0/24 |
                                     |             |
                                  Router 1      Router 3
                                     |             |
                                   LAN 1         LAN 3
                                  with UM       with UM
                                10.0.1.0/24   10.0.3.0/24

Of the variety of other switching devices and terminology released by vendors, Layer-4 and Layer-7 switching have received considerable attention. In general, these approaches refer to the capability of a switch to act on Layer 4 (transport layer) information contained in packets. For example, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port numbers can be used to make decisions affecting issues such as security and Quality of Service (QoS). However, rather than being viewed as a third type of campus switching devices, these should be seen as a logical extension and enhancement to the two types of switches already discussed. In fact, both routing switches and switching routers can perform these upper-layer functions.

 

More Related Network Hardware Tips and Guides

Use Layer-3 Switch or Router?

Layer 2 Switches & Layer 3 switches

Cisco Catalyst 2960 LAN Base Series & Catalyst 2960 LAN Lite Series

Main Network Hardware’s Difference: Integrated Devices, Router, Network Switch & Firewall

Read more
<< < 1 2 3 4 5 6 7 > >>