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

Posts with #networking tag

Fat, Thin, and Fit APs in WLAN Network

December 20 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Cisco Wireless - Cisco Wireless AP, #Networking, #Cisco & Cisco Network

You should hear of the Fat, Thin, and Fit APs. What are they?

The terms thin and fat have been applied to WLAN access points (APs) in many different ways.

  • Some vendors use thin AP to refer to entry-level/residential-grade products with few advanced features, in comparison to fat APs rich with enterprise network features like VLAN tagging and SNMP-based management.
  • Some use thin AP to refer to products that can't be configured or used on their own, but instead are part of a WLAN switching system that governs both setup and operation. In this case, a fat AP is any stand-alone AP, no matter how extensive that AP's feature set.
  • Some use thin AP to refer to products that offload selected tasks to an upstream server -- for example, communicating with 802.1X Authentication Servers, generating encryption keys, acting as a VPN gateway, or re-routing traffic for cross-network mobility. In comparison, any of these tasks could be performed directly on a fat AP, without relying on an upstream server.

In the autonomous architecture, the WTPs (Wireless Termination Point) completely implement and terminate the 802.11 function so that frames on the wired LAN are 802.3 frames. Each WTP can be independently managed as a separate network entity on the network. The access point in such a network is often called a Fat AP.

FAT APs in Autonomous WLAN Network Architecture

 

During the initial stages of WLAN deployment, most APs were autonomous APs, and manageable as independent entities in the network. During the past few years, centralized architectures (discussed next) with ACs and WTPs have gained popularity. The primary advantage of the centralized architecture is that it provides network administrators with a structured and hierarchical mode of control for multiple WTPs in the enterprise.

Centralized Architecture

The centralized architecture is a hierarchical architecture that involves a WLAN controller that is responsible for configuration, control, and management of several WTPs. The WLAN controller is also known as the Access Controller (AC). The 802.11 function is split between the WTP and the AC. Because the WTPs in this model have a reduced function as compared to the autonomous architecture, they are also known as Thin APs. Some of the functions on the APs are variable, as discussed in the following section.

Thin APs in Centralized WLAN Network Architecture

 

Distributed Architecture

In the distributed architecture, the various WTPs can form distributed networks with other WTPs through wired or wireless connections. A mesh network of WTPs is one example of such an architecture. The WTPs in the mesh can be linked with 802.11 links or wired 802.3 links. This architecture is often used in municipal networks and other deployments where an outdoor component is involved. This article does not address the distributed architecture.

WTP Functions Fat, Thin, and Fit APs

To understand the autonomous and centralized architecture, it is useful to look at the functions performed by the APs. We start with the Fat APs, which form the core of the autonomous architecture, followed by the Thin APs, which were specified as part of the WLAN switch- or controller-based centralized architecture. The article will then outline the functions of a new variant called the Fit AP, an optimized version of the AP for centralized architectures.

Fat Access Points

Figure1 shows an example of an autonomous network with a fat access point. The AP is an addressable node in the network with its own IP address on its interfaces. It can forward traffic between the wired and wireless interfaces. It can also have more than one wired interface and can forward traffic between the wired interfaces similar to a Layer 2 or Layer 3 switch. Connectivity to the wired enterprise can be through a Layer 2 or Layer 3 network.

It is important to understand that there is no backhauling of traffic from the Fat AP to another device through tunnels. This aspect is important and is addressed when discussing the other AP types. In addition, Fat APs can provide router-like functions such as the Dynamic Host Configuration Protocol (DHCP) server capabilities.

Management of the AP is done through a protocol such as the Simple Network Management Protocol (SNMP) or the Hypertext Transfer Protocol (HTTP) for Web-based management and a Command-Line Interface (CLI). To manage multiple APs, the network manager has to connect to each AP through one of these management schemes. Each AP shows up on the network map as a separate node. Any aggregation of the nodes for management and control has to be done at the Network Management System (NMS) level, which involves development of an NMS application.

Fat APs also have enhanced capabilities such as Access Control Lists (ACLs), which permit filtering of traffic for specific WLAN clients. Another significant capability of these devices is configuration and enforcement of Quality of Service (QoS)-related functions. For example, traffic from specific mobile stations might need to have a higher priority than others. Or, you might need to insert and enforce IEEE 802.1p priority or Differentiated Services Code Point (DSCP) for traffic from mobile stations. In summary, these APs act like a switch or router in that they provide many of the functions of such devices.

The downside of such APs is complexity. Fat APs tend to be built on powerful hardware and require complex software. These devices are expensive to install and maintain because of the complexity. Nevertheless, the devices have uses in smaller network installations.

Some Fat AP installations still use a controller at the back end for control and management functions. These controllers lead to a slightly scaled-down version of the Fat AP, called, not surprisingly, a Fit AP, discussed later.

Thin Access Points

As their name indicates, Thin APs are intended to reduce the complexity of APs. An important motivation for this reduction is the location of APs. In several enterprises, APs are plenum-mounted (and thus in hard-to-reach areas) so that they can provide optimum radio connectivity for end stations. In environments like warehouses, this is even more evident. For such reasons, network managers prefer to install APs just once and not have to perform complex maintenance on them.

Thin APs are often known as intelligent antennas, in that their primary function is to receive and transmit wireless traffic. They backhaul the wireless frames to a controller where the frames are processed before being switched to the wired LAN (see the Figure ‘Thin APs in Centralized WLAN Network Architecture’).

The APs use a (typically secure) tunnel to backhaul the wireless traffic to the controller. In their most basic form, Thin APs do not even perform WLAN encryption such as Wired Equivalence Privacy (WEP) or WiFi Protected Access (WPA/WPA2). This encryption is done at the controller the APs just transmit or receive the encrypted wireless frames, thereby keeping the APs simple and avoiding the necessity to upgrade their hardware or software.

The introduction of WPA2 necessitated encryption on the controller. Although WPA was hardware-compatible with WEP and required only a firmware upgrade, WPA2 was not backward-compatible. Instead of replacing APs across the enterprise, network managers could just backhaul the wireless traffic to the controller where the WPA2 decryption was done, and the frames were sent on the wired LAN.

The protocol between the AP and the controller for carrying the control and data traffic was proprietary. Also, there is no capability to manage the AP as a single entity on the Layer 2/3 network it can be managed only through the controller, to which the NMS can communicate through HTTP, SNMP, or CLI/Telnet. A controller can manage and control multiple APs, implying that the controller should be based on powerful hardware and often be able to perform switching and routing functions. Another important requirement is that the connectivity and tunnel between the AP and the AC should ensure low delay for packets between those two entities.

With Thin APs, QoS enforcement and ACL-based filtering are handled at the controller not a problem because all the frames from the AP have to pass through the controller anyway. Centralized control functions for ACLs and QoS are not new they were implemented in networks with Fat APs too. Such installations have controllers that act as the gateway for managing traffic from APs to the wired network. However, the controller function takes on a new dimension with Thin APs, especially with respect to the data plane and forwarding functions. The controller function subsequently was integrated into Ethernet switches that connected the wireless and wired LANs the motivation for the family of devices known as WLAN switches.

The Wireless MAC architecture in this scenario is known as the Remote MAC architecture. The entire set of 802.11 MAC functions is offloaded to the WLAN controller, including the delay-sensitive MAC functions.

Fit Access Points

Fit APs are gaining in popularity in that they try to take advantage of the best of both worlds that is, the Fat APs and the Thin APs. A Fit AP provides the wireless encryption while using the AC for the actual key exchange. This approach is used for newer APs that use the latest wireless chipsets supporting WPA2. The management and policy functions reside on the controller that connects to multiple APs through tunnels.

Also, Fit APs provide additional functions such as DHCP relay for the station to obtain an IP address through DHCP. In addition, Fit APs can perform functions such as VLAN tagging based on the Service Set Identifier (SSID) that the client uses to associate with the AP (when the AP supports multiple SSIDs).

Two types of MAC implementations are possible with Fit APs, known as the Local MAC and the Split MAC architectures. Local MAC is where all the wireless MAC functions are performed at the AP. The complete 802.11 MAC functions, including management and control frame processing, are resident on the APs. These functions include time-sensitive functions (also known as Real Time MAC functions).

The Split MAC architecture divides the implementation of the MAC functions between the AP and the controller. The real-time MAC functions include functions such as beacon generation, probe transmission and response, control frame processing (for example Request to Send and Clear to Send RTS and CTS), retransmission, and so on. The non-real time functions include authentication and deauthentication; association and reassociation; bridging between Ethernet and Wireless LAN; fragmentation; and so on.

Vendors differ in the type of functions that are split between the AP and the controller, and in some cases, even about what constitutes real time. One common implementation of a Fit AP involves local MAC at the AP and control and management functions at the AP.

Reference from http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-13/wireless-lan-switches.html

More Related:

Something about the Cisco Wireless APs Supporting Cisco WLC

How Much You Know about Cisco Aironet Access Point?

Cisco Aironet 3802 AP to be Crowned “Wi-Fi Certified”

Read more

Cisco VoIP and Video Phones to Meet a Range of Needs

December 6 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco IP Phones

Do you have an “easy to use” Cisco IP Phone, such as Cisco IP Phone 8800 Series? Cisco always adds new IP Phones-the cost-effective IP communications to replace traditional phones. What are they? There are 4 main types of VoIP and Video Phones to meet your business needs.

The four series include:

  1. Unified SIP Phone 3900 Series
  2. Unified IP Phone 6900 Series
  3. Cisco IP Phone 7800 Series
  4. Cisco IP Phone 8800 Series

 

 

 

 

 

 

 

 

 

 

 

 

 

In today's business environment, your organization must meet the needs of a wide range of endpoint users with different communication styles and distinct workspaces. Some users want to communicate through their desk phones. Others prefer wireless devices. Still others lean toward soft clients.

The portfolio of Cisco IP phones includes user-friendly, full-featured IP phones to meet the needs of your entire organization, in areas ranging from:

  • The company lobby to the desks of your busiest managers
  • The manufacturing floor to the executive suite
  • The home office to the branch location and corporate offices, both small and large

Many Cisco IP Phones in the portfolio deliver new modes of collaboration, such as integrated HD voice, video, web conferencing, USB peripherals for extensibility and Bluetooth.

The portfolio includes:

Single- and Multi-Line VoIP Phones
These support a range of communication needs, from low-use to the most active-use environments

Basic to Full-Featured IP Phones
Our phones use Cisco Collaboration Solutions to cost-effectively meet your corporate objectives and boost profits.

HD Video Communications (Select Models)
See how this helps you reduce your travel costs and speed decision-making

Applications from Cisco Developer Partners
Enjoy a more personalized and productive IP phone experience with an array of business applications.

Your Choice of Deployment Options
Support for on-premises, from the cloud, or use a hybrid deployment of the two, based on your business needs

Centralized Management
Simplify administration with remote access. On some models, employees can register and activate phones themselves.

 

More Topics here:

What’s New on Cisco IP Phone 8800 Series

Updated: Cisco IP Phone 7800 Series

Cisco Unified IP Phones 9900, Transform How You Collaborate

How to Save Power on Cisco IP Phones?

Read more

What You can Do with Cisco AVB?

December 1 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco Switches - Cisco Firewall, #Cisco Technology - IT News

Cisco Simplifies Digitization of Audio Video Networks with IEEE Audio Video Bridging

Do you want more audio-video flexibility without spending too much money? If yes, you can try Cisco’s new AVB. What is Audio Video Bridging?

Audio video (AV) equipment deployments have traditionally been single-purpose, analog, point-to-point connections with one-way links. As AV deployments migrate to digital, they have continued to retain this inflexible point to-point architecture. This dedicated connection model also results in a mass of cabling that is difficult and costly to manage. In contrast, an open-standards based Ethernet infrastructure enables flexibility and transparent interoperability of multi-vendor AV equipment and integration of new services.

How did AVB come about, and what does it all mean? AVB is a set of technical standards created by the IEEE Audio Video Bridging Task Group. The IEEE AVB Task Group is a part of the IEEE 802.1 standards committee. IEEE 802.1 defined a set of standards that provided the means for highly reliable delivery of low-latency, time-synchronized AV streaming services through Layer 2 Ethernet networks.

The IEEE 802.1 Audio Video Bridging (AVB) standard enables this digital transition and accelerates the adoption of Ethernet-based AV deployments that are interoperable. The IEEE 802.1 AVB defines a mechanism whereby the endpoints and the network function as a whole. This allows high-quality AV streaming of professional AV over an Ethernet infrastructure. Instead of one-to-one, the network transport enables many-to-many seamless plug-n-play connections for multiple AV endpoints including talkers and listeners. This helps corporations lower total cost of ownership through fewer cables (CapEx) and no license fees for any proprietary technologies (OpEx). It also provides higher quality, time-synchronized AV with more scalability. This scalability includes a more efficient deployment, installation and management enabling new capabilities.

If you want to see how each standard interacts with AVB and for more about the subject, read the “Cisco Audio Video Bridging Design and Deployment for an Enterprise Network” white paper.

http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-736890.html

Cisco simplifies digitization of AV networks with AVB support on industry leading switches. With the Cisco IOS XE Software Release 16.3, Cisco has introduced support for the IEEE 802.1 AVB standard on select Cisco Catalyst 3850 and select Cisco Catalyst 3650 switches. It delivers the highest-capacity 1-,10- and 40-Gigabit Ethernet ports in the industry.

Cisco implements the AVB standards on select Catalyst 3850 and 3650 Series Switches.

The Catalyst 3850 and 3650 Series Switches include our widely deployed, industry leading managed access and aggregation switches. They are designed to deliver a comprehensive set of features to provide the best application experience, the highest levels of security, precise control and management of the network. They offer industry-leading scalability in the fixed configuration category of switches. As a result, they can be deployed as aggregation or access switches in large networks or as core switches in smaller networks.

Cisco’s Unified Access Data Plane application-specific integrated circuit (ASIC) powers the switches and can enable uniform wired-wireless policy enforcement, application visibility and control (AVC), flexibility and application optimization. Cisco Catalyst 3850 and 3650 Series Switches support full IEEE 802.3at Power over Ethernet Plus (PoE+), Cisco Universal Power over Ethernet, modular and field-replaceable network modules, RJ45 and fiber-based downlink interfaces, redundant fans and power supplies and innovative power-sharing functions to achieve a flexible and advanced redundant configuration. With speeds that reach 10 Gbps, Cisco Catalyst 3850 Multigigabit Ethernet Switches support current and next-generation wireless speeds and standards—including 802.11ac Wave 2—on existing cabling infrastructure.

Quite simply, these switches are designed to deliver a comprehensive set of features to provide the best application experience, the highest levels of security, and precise control and management of the network.

The Cisco Catalyst 3850 and 3650 switches offer industry-leading scalability in the fixed configuration category of switches. As a result, they can be deployed as aggregation or access switches in large networks or as core switches in smaller networks.

 

Cisco has also added rich next-generation capabilities to this platform.

Some examples include:

  • Programmability
  • AVB
  • MPLS
  • Services discovery gateway
  • Network as a sensor and enforcer
  • Encapsulated remote switchport analysis

Try using a Cisco Catalyst 3850 and 3650 Series switches to provide AVB. Whether you're in hospitality, government, enterprise or another industry, Cisco AVB is an ideal solution. Deploy it into your current audio-video setup: in conference rooms, auditoriums, and more.

Reference From http://www.cisco.com/c/dam/en/us/products/collateral/switches/at-a-glance-c45-737488.pdf

More Related:

Cisco AVB Switches

What is Audio Video Bridging?

Updated: Comparing the Newest Cisco 3850 Models

The New Cisco Catalyst 3650 Series Mini Switch

The Newest: Model Comparison for the Cisco Catalyst 3650 Models

Read more

Introducing Cisco Software-Defined Storage Solutions

November 23 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco & Cisco Network, #Technology, #IT, #Data Center

Today the Storage plays a more and more important role in the data center: from storing email messages and documents to saving business-critical information, intellectual property, and transaction detail. As businesses continue to become more connected, the old ways of storing and archiving data are changing to accommodate growing amounts of data and demand for anytime, anywhere access to information.

Historically, IT organizations transitioned from systems with individual disk drives to storage arrays that allowed disk drives to be grouped together to form a larger area of capacity. When fast and easy access to more capacity was needed, storage area networks (SANs) and network attached storage (NAS) emerged to deliver capacity over the network. More recently, integrated systems and hyper-converged infrastructure have been added to networks to simplify resource acquisition and deployment and facilitate easy scaling. As companies try to balance storage access, performance, and cost, software-defined storage is becoming more popular, taking this evolution a step farther.

Software-defined storage is the next phase of server virtualization technology, moving beyond virtual machines to virtual data stores. It combines industry-standard x86-architecture servers that are optimized for direct-attached storage (DAS) with a distributed software abstraction layer. This intelligent software transforms systems into a single, logical pool of cost-effective, scale-out storage resources that are easily integrated and managed within your data center.

Cisco Solutions for Software-Defined Storage

Our solutions provide the storage flexibility you need to support growing amounts of data and deliver fast access to information and innovation. You can choose from a variety of systems and expansion cards according to the capacity and performance needs of your users and applications. Our modular approach lets you:

• Reduce risk and complexity: You need confidence that your software-defined infrastructure will work right the first time. Cisco’s collaboration and validation with a large partner ecosystem of software vendors gives you a choice of proven solutions and reference architectures while helping your IT staff integrate storage innovation with your IT processes and business applications at low risk. As a result, you can easily procure the solution you need and accelerate implementation and deployment.

Cisco Solutions Deliver the Foundation for Software-Defined Storage Deployments

Target Environments

  • File, block, and object storage
  • Email servers
  • Collaboration environments
  • Video surveillance archiving
  • Content distribution networks
  • Data protection solutions
  • Private cloud storage

• Gain versatility: The Cisco Unified Computing System (Cisco UCS) portfolio offers a variety of server options for rightsizing your software-defined storage deployments. You can deploy Cisco UCS C-Series Rack Servers to support many common storage scenarios, and use Cisco UCS S-Series Storage Servers when you need highly scalable and available storage infrastructure (Figure 1).

• Scale on demand: You can scale the storage capacity, performance, and protocols used in your software-defined storage infrastructure at your pace and with a smaller increment of scale than with traditional large-scale storage solutions. With the flexibility to choose what to scale and when to scale it, you can start with a small configuration and expand to petabytes of capacity, and you can distribute I/O operations among servers to accelerate I/O operations.

• Improve the efficiency of your IT operations: Cisco UCS Manager provides the automation you need to be efficient. Role- and policybased management makes it easy to deploy terabytes to petabytes of storage capacity in minutes. Cisco UCS service profiles and storage profiles extend these capabilities, allowing you to specify the ways that servers and disk drives should be identified, configured, connected, and used. You can configure hundreds of storage servers as easily as you can configure one, in a repeatable manner.

• Reduce vendor lock-in: Whether you need to support a remote or branch office or a large enterprise data center, our broad ecosystem of partners offers what you need. We work together to test, validate, and document joint solutions so that you can get your softwaredefined storage solutions up and running quickly and with confidence.

Next Steps Call your Cisco sales representative or authorized partner to find out how Cisco UCS solutions can help you create the best software-defined storage solution for your business and applications.

From https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/software-defined-storage-solutions/software-defined-solution.pdf

 

More Related Topics

Cisco’s New Storage Optimized UCS Server-UCS S3260

New Cisco UCS S3260 Storage Server: A Dense and Powerful Server for Scale-out Storage

Cisco UCS S3260-The New Storage Building Blocks

Cisco UCS S3260 Storage Server Big Data and Analytics

Read more

New Cisco UCS S3260 Storage Server: A Dense and Powerful Server for Scale-out Storage

November 22 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco & Cisco Network

Cisco introduced the new Cisco UCS S-Series Storage Servers-S3260 into the market in earlier November. The S Series is a new storage-optimized server category in the Cisco Unified Computing System (UCS) portfolio designed specifically to address the needs of data intensive workloads such as Big Data, and for deploying software-defined storage, object storage, and data protection solutions.

The Cisco UCS S3260 Storage Server is a powerful, modular, and high-capacity storage-optimized rack server well suited for environments that need petabyte-scale storage. It provides dense, cost-effective storage to address your ever-growing data needs. Designed for a new class of data-intensive applications, it is simple to deploy and can handle many simultaneous uses, ranging from data protection to active archives to high performance computing, all within the same cluster.

Unlike some ultra-high-capacity servers, the S3260 has the right proportions of compute and storage to meet the demands of modern, storage-intensive workloads. Like the rest of the UCS portfolio, the S3260 is a powerful server with industry-leading networking, and it now offers over 600TB of capacity. Whether you experience a growth of data or a growth in demand for that data, the S3260 can handle it.

Key UCS S3260 Storage Server features for scale-out storage:

  • 1 or 2 server nodes per chassis
  • Cisco Integrated Management Controller (CIMC) allows pooling of drives and dynamic allocation of these drives to server nodes
  • Up to 56 top-loading 3.5” disk drives with support for partially populated chassis and as-needed expansion
  • Optional additional 4 rear-loading 3.5” disk drives (if only one server node is used)
  • 2 dedicated 2.5” SSD slots per server node (for system software)
  • 4x 40Gbps of I/O throughput with various network connectivity options

UCS S3260 hardware features that help create a leading cloud storage solution.

Now let’s read some details of the new UCS S3260 hardware from the following video.

Introducing the New Cisco UCS S-Series Storage Servers

https://youtu.be/dYMknAsXgH4

More Related Topics

Cisco’s New Storage Optimized UCS Server-UCS S3260

Cisco UCS S3260-The New Storage Building Blocks

Cisco UCS S3260 Storage Server Big Data and Analytics

 

More REVIEWS

Active Archive with Cisco UCS

Multi-region private cloud storage with SwiftStack software and Cisco UCS S-Series servers

http://learn.swiftstack.com/rs/034-CBF-009/images/Solution-Brief-SwiftStack-Cisco-UCS.pdf

Read more

The Latest Cisco 4000 Model Comparison

November 10 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco Routers

The new ISR 4221 of Cisco ISR 4000 family was introduced to customers. The present Cisco 4000 family has main six platforms: the 4451, 4431, 4351, 4331, 4321 and the new 4221 ISRs.

The latest ISR 4221 is mightier than the ISR G2, vis-à-vis ISR 1921 and 1941. It is a desktop-like, industrially designed 1RU box priced cost-effectively for mid-markets.

What other features of Cisco ISR 4221 you should know? Read these 3 questions to get the answers.

Q. Is a console port available on the Cisco 4000 Series?

A. The Cisco 4000 Series has the option of the regular RJ-45 console port as well as the USB console port. As with the ISR G2 routers, only one console port can be used at a time, with preference given to the USB console port. The Cisco 4221 router has a combo RJ-45 port for AUX and Console.

Q. Is online insertion and removal (OIR) supported on the Cisco 4000 Series?

A. Yes, OIR is supported on the Cisco 4000 Series for the following scenarios:

● Surprise insertion or removal of any NIM in any of the NIM slots

● Surprise insertion or removal of any SM-X in the SM-X slots

● Surprise insertion or removal of any power supply or system PoE conversion module

● Surprise replacement of the system fan tray; note, however, that this replacement must take place quickly enough that the system does not overheat, and depending on altitude and ambient temperature, the amount of time can vary greatly

Note that SM-X and NIM modules allow replacement only for like-to-like modules. A faulty module can be replaced with a good module of the same type but cannot be replaced with a completely different module of a different type.

The Cisco 4221 does not support OIR.

Q. How many PVDM slots are present on the motherboard?­

A. There is only one PVDM slot on the motherboard across the Cisco 4000 Series. And the TDM cards CANNOT use the motherboard PVDMs.

The 4221 does not have any PVDM slot.

In the following part we will list the main Cisco 4000 model comparison, which help you know the main features of Cisco 4000 platforms.

ISR 4321 vs. ISR 4331 vs. ISR 4351 vs. 4431 vs. 4451

 

Feature

4321

4331

4351

4431

4451

Form factor

1 rack unit (RU)
Desktop

1 RU

2 RU

1 RU

2 RU

Integrated WAN ports

1 GE / SFP
1 GE

1 GE / SFP
1 GE
1 SFP

2 PoE GE / SFP
1 GE/ SFP

2 PoE GE / SFP
2 GE / SFP

2 PoE GE / SFP
2 GE / SFP

Performance

50 Mbps
Upgradable to 100 Mbps

100 Mbps
Upgradable to 300 Mbps

200 Mbps
Upgradable to 400 Mbps

500 Mbps
Upgradeable to 1 Gbps

1 Gbps
Upgradable to 2 Gbps

Management port

1 GE (Integrated Out of Band)

Network Interface Modules (NIM)

2

2

3

3

3

Enhanced Services Module (SM-X)

N/A

1 single-wide

2 single- or
1 double-wide

N/A

2 single- or
1 double-wide

Integrated Services Card (ISC) slots

1
(PVDM 4)

1
(PVDM 4)

1
(PVDM 4)

1
(PVDM 4)

1
(PVDM 4)

USB ports (type A)

1

1

2

2

2

Default/max Flash

4 GB / 8 GB

4 GB / 16 GB

4 GB / 16 GB

8 GB / 32 GB

8 GB / 32 GB

Default/max DRAM

4 GB / 8 GB

4 GB / 16 GB

4 GB / 16 GB

4 GB / 16 GB

4 GB / 16 GB

Power supply type

External: AC, PoE

Internal: AC, PoE

Internal: AC, PoE or DC

Internal: AC, PoE or DC

Internal: AC, PoE or DC

Redundant power supply

No

No

No

Yes
Internal RPS

Yes
Internal RPS

Module online insertion and removal (OIR)

Yes

Yes

Yes

Yes

Yes

Server virtualization platform (UCS E-Series)

N/A

2-core single-wide,
4-core single-wide

2 core single-wide,
4 core single-wide,
4 core double-wide,
6 core double-wide,
8 core double-wide

N/A

2-core single-wide,
4-core single-wide,
4-core double-wide,
6-core double-wide,
8-core double-wide

Advanced Security

4321

4331

4351

4431

4451

Zone-based firewall and NAT services

VRF-Aware Firewall and Network Address Translation (NAT)

Hardware VPN acceleration
(DES, 3DES, AES)

No

IPSEC VPN services

FlexVPN, Easy VPN remote server, Enhanced Easy VPN, Dynamic Multipoint VPN (DMVPN),
Group Encrypted Transport VPN (GET VPN), V3PN, MPLS VPN

SSL VPN

No

Intrusion prevention

Yes

Network foundation protection

ACL, FPM, control plan protection, control plane policing (CoPP), QoS, role-based CLI access, source-based RTBH, uRPF, SSHv2

Cisco Cloud Web Security

Yes

Identity-based networking

No

No

No

No

No

Cisco TrustSec

  • Security Group Tag Exchange Protocol (SXP), SGT over GETVPN
  • SGT over IPSEC
  • SGT over DMVPN
  • SGT-based ZBFW
  • Port/Layer 3 interface/IP/subnet-to-SGT mapping
  • SGT export in Flexible NetFlow

Unified Communications

4321

4331

4351

4431

4451

Local conferencing

Yes

Yes

Yes

Yes

Yes

Digital signal processor support

PVDM4

PVDM4

PVDM4

PVDM4

PVDM4

Cisco Unified Survivable Remote Site
Telephony support

Up to 50

Up to 100

Up to 750

Up to 1200

Up to 2000

Cisco Unified Communications
Manager Express support

Up to 50

Up to 100

Up to 250

Up to 350

Up to 450

Cisco Unity Express
(NM, SM, or ISM)

Use Cisco Unity Connection on UCSE

Use Cisco Unity Connection on UCSE

Use Cisco Unity Connection on UCSE

Use Cisco Unity Connection on UCSE

Use Cisco Unity Connection on UCSE

Cisco Unified Border Element (CUBE)
(SIP/H.323 sessions)

100

400

1000

3000

6000

nano Cisco Unified Border Element (nanoCUBE)
(sessions)

N/A

N/A

N/A

N/A

N/A

Digital voice and video (T1/E1 channels)

Up to 240

Up to 360

Up to 720

Up to 720

Up to 1200

Analog/BRI voice

Up to 8 ports (FXS, FXO, E/M, BRi)

Up to 12 ports (FXS, FXO, E/M, BRi)

Up to 20 ports (FXS, FXO, E/M, BRi)

Up to 12 ports (FXS, FXO, E/M, BRi)

Up to 20 ports (FXS, FXO, E/M, BRi)

Routing and Multicast

4321

4331

4351

4431

4451

IPv4 routing protocols

RIP v1/v2, EIGRP, OSPF, BGP, PBR, PfR

RIP v1/v2, EIGRP, OSPF, BGP, PBR, PfR

RIP v1/v2, EIGRP, OSPF, BGP, PBR, PfR

RIP v1/v2, EIGRP, OSPF, BGP, PBR, PfR

RIP v1/v2, EIGRP, OSPF, BGP, PBR, PfR

Multicast routing protocols

PIM-SM, mroute (static route), and MLD

PIM-SM, mroute (static route), and MLD

PIM-SM, mroute (static route), and MLD

PIM-SM, mroute (static route), and MLD

PIM-SM, mroute (static route), and MLD

IPv6 routing protocols

EIGRP, RIP, OSPFv3, IS-IS,
BGP and PBR

EIGRP, RIP, OSPFv3, IS-IS,
BGP and PBR

EIGRP, RIP, OSPFv3, IS-IS,
BGP and PBR

EIGRP, RIP, OSPFv3, IS-IS,
BGP and PBR

EIGRP, RIP, OSPFv3, IS-IS,
BGP and PBR

Wireless LAN

4321

4331

4351

4431

4451

Integrated 802.11 b/g/n access point

N/A

N/A

N/A

N/A

N/A

Integrated 802.11 a/b/g/n access point

N/A

N/A

N/A

N/A

N/A

Unified and autonomous mode

N/A

N/A

N/A

N/A

N/A

RP-TNC connectors for field-replaceable
optional high-gain antennas

N/A

N/A

N/A

N/A

N/A

Diversity (dual antennas)

N/A

N/A

N/A

N/A

N/A

Wireless LAN controller module

Available on UCS E-Series

Available on UCS E-Series

Available on UCS E-Series

Available on UCS E-Series

Available on UCS E-Series

Wireless WAN

4321

4331

4351

4431

4451

3G /4G LTE cellular

Yes*

Outdoor antennas

N/A

N/A

N/A

N/A

N/A

Integrated Switching

4321

4331

4351

4431

4451

Maximum switched Ethernet ports

N/A

24

48

N/A

48

Maximum switched Ethernet LAN ports with PoE

N/A

24

48

N/A

48

PoE support (wattage)
without PoE boost

120 W

250 W

500 W

250 W
(with optional power supply redundancy)

500 W
(with optional power supply redundancy)

PoE support (wattage)
with PoE boost

260 W

530 W

990 W

500 W
(no power supply redundancy)

950 W
(no power supply redundancy)

EtherSwitch Service Module type (width)

N/A

1 single

2 single or 1 double

N/A

2 single or 1 double

Application Services

4321

4331

4351

4431

4451

Intelligent Path Control

PfR

PfR

PfR

PfR

PfR

Network Contention Control

QoS, HQoS

QoS, HQoS

QoS, HQoS

QoS, HQoS

QoS, HQoS

Application Visibility

NBAR v2

NBAR v2

NBAR v2

NBAR v2

NBAR v2

WAN Optimization

ISR-WAAS

ISR-WAAS,
vWAAS on UCS E-Series

ISR-WAAS,
vWAAS on UCS E-Series

ISR-WAAS

ISR-WAAS,
vWAAS on UCS E-Series

Akamai Connect

Yes

Yes

Yes

Yes

Yes

Cisco Application Centric Infrastructure

Application Policy Infrastructure Controller (APIC) with Enterprise Module

Reference From http://www.cisco.com/c/en/us/products/routers/4000-series-integrated-services-routers-isr/models-comparison.html

More Related Topics:

The New ISR 4221, the New Cisco DNA-Ready Platform

Say Something about Cisco 4400 and 4300 Series

Migrating to Cisco 4000 Series ISR…Benefits You Get

Cisco 4000 Series ISR, Top Choice for Today’s Branch Offices

Read more

Cisco Catalyst 3850 Series Licenses

October 28 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco Switches - Cisco Firewall, #Technology, #Cisco License

LAN Base, IP Base and IP Services these 3 features are available with all Cisco Catalyst 3850 models. What are their features?

●   LAN Base: Enterprise access layer 2 switching features

●   IP Base: Enterprise access layer 3 switching features

●   IP Services: Advanced enterprise layer 3 switching (IPv4 and IPv6) features

1. The LAN Base feature set offers enhanced intelligent services that include comprehensive Layer 2 features, with up to 255 VLANs.

2. The IP Base feature set provides entry-level enterprise services in addition to all LAN Base features, with 1K VLANs. IP Base also includes the support for wireless controller functionality (mobility agent and mobility controller role; additional access point license required for mobility controller role), routed access, smart operations, FNF, and so on.

3. The IP Services feature set provides full enterprise services that include advanced Layer 3 features such as EIGRP, OSPF, BGP, PIM, and IPv6 routing such as OSPFv3 and EIGRPv6. All software feature sets support advanced security and MQC-based QoS.

The Cisco Catalyst 3850 Series Switches with LAN Base feature set can only stack with other Cisco Catalyst 3850 Series LAN Base switches. The same applies to IP Base and IP Services as well. A mixed stack of LAN Base switch with IP Base or IP Services feature set is not supported.

The 12-port and 24-port SFP+- and SFP-based models as well as the 48-port SFP+ model can only be ordered with IP Base or IP Services licenses. Therefore, in order to stack with LAN Base models, they need to be configured in LAN Base mode from the CLI.

Customers can transparently upgrade the software feature set in the Cisco Catalyst 3850 Series Switches through Cisco IOS Software CLI using the right to use (RTU)-based software upgrade process. Software activation enables the Cisco IOS Software feature sets. Based on the license’s type, Cisco IOS Software activates the appropriate feature set. License types can be changed, or upgraded, to activate a different feature set.

Software Policy for Cisco Catalyst 3850 Series Switches

Customers with Cisco Catalyst LAN Base and IP Base software feature sets will be provided with maintenance updates and bug fixes designed to maintain the compliance of the software with published specifications, release notes, and industry standards compliance as long as the original end user continues to own or use the product or up to one year from the end-of-sale date for this product, whichever occurs earlier. Customers with licenses for our IP Services software images require a service support contract such as Cisco SMARTnet Service to download updates. This policy supersedes any previous warranty or software statement and is subject to change without notice.

Cisco ONE Software for Cisco Catalyst 3850 Series

Cisco ONE Software for Access Switching is available for the Cisco Catalyst 3850 Series Switches.

Cisco ONE Software is a new way for customers to purchase and use our infrastructure software. It offers a simplified consumption model, centered on common customer scenarios in the data center, WANs, and LANs.

Cisco ONE Software and services provide customers with four primary benefits:

  • Software suites that address typical customer use scenarios at an attractive price
  • Investment protection of their software purchase through software services-enabled license portability
  • Access to ongoing innovation and new technology with Cisco Software Support Service (SWSS)
  • Flexible licensing models to smoothly distribute customer's software spend over time

For ordering information for Cisco ONE Software for the Cisco Catalyst 3850 Series Switches, go to http://www.cisco.com/c/en/us/products/software/one-access/switching-part-numbers.html.

Licenses for Cisco Catalyst 3850 Series Switches

Software Licenses

C3850-12-S-E

Cisco Catalyst 3850 12-port IP Base to IP Services RTU paper license

C3850-24-L-S

Cisco Catalyst 3850 24-port Switch LAN Base to IP Base RTU paper license

C3850-48-L-S

Cisco Catalyst 3850 48-port Switch LAN Base to IP Base RTU paper license

C3850-24-L-E

Cisco Catalyst 3850 24-port LAN Base to IP Services RTU paper license

C3850-48-L-E

Cisco Catalyst 3850 48-port LAN Base to IP Services RTU paper license

C3850-24-S-E

Cisco Catalyst 3850 24-port IP Base to IP Services RTU paper license

C3850-48-S-E

Cisco Catalyst 3850 48-port IP Base to IP Services RTU paper license

L-C3850-24-L-S

Cisco Catalyst 3850 24-port LAN Base to IP Base RTU electronic license

L-C3850-48-L-S

Cisco Catalyst 3850 48-port LAN Base to IP Base RTU electronic license

L-C3850-24-L-E

Cisco Catalyst 3850 24-port LAN Base to IP Services RTU electronic license

L-C3850-48-L-E

Cisco Catalyst 3850 48-port LAN Base to IP Services RTU electronic license

L-C3850-24-S-E

Cisco Catalyst 3850 24-port IP Base to IP Services RTU electronic license

L-C3850-48-S-E

Cisco Catalyst 3850 48-port IP Base to IP Services RTU electronic license

L-C3850-12-S-E

Cisco Catalyst 3850 12-port IP Base to IP Services RTU electronic license

Access Point Licenses

L-LIC-CT3850-UPG

Primary upgrade license SKU for Cisco 3850 wireless controller (e-delivery)

L-LIC-CTIOS-1A

1 access point adder license for Cisco IOS Software based wireless controller (e-delivery)

LIC-CT3850-UPG

Primary upgrade license SKU for Cisco 3850 wireless controller (paper license)

LIC-CTIOS-1A

1 access point adder license for the Cisco IOS Software based wireless controller (paper license)

Access Point License for Cisco Catalyst 3850: An access point license is required for Cisco Catalyst 3850 operating in mobility controller mode. No access point license is required for 3850 operating in mobility agent mode. This functionality is included in the IP Base feature set. Other devices that can act as mobility controller are the WLC 5760, WLC 5508, and WiSM2 wireless controllers. Access point licenses can be transferred only between two 3850 switches or between 3850 and 5760 controller and vice versa.

More info here: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3850-series-switches/data_sheet_c78-720918.html?referring_site=RE&pos=1&page=http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3850-series-switches/qa_c67-722110.html

 

More Related…

New: Cisco 3850 as Mobility Controller

Updated: Cisco StackPower Technology for Cisco Catalyst 3850 Switches

Updated: Comparing the Newest Cisco 3850 Models

How to Change a Switch Member Number in a Cisco 3850 Stack?

How to Form a Stack-Wise and Power-Stack with Cisco Catalyst 3850?

Cisco Catalyst 3850 Series-“Auto-Upgrade” Feature

Read more

Top 10 Facts about Cisco Wireless You Should Know

October 24 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco Wireless - Cisco Wireless AP, #Cisco & Cisco Network

In this article we will share 10 facts of Cisco wireless that you should know. Cisco Wireless related facts may make you shout out: “Really?”

really,top 10 facts...

If you have any suggestions for additions, please share with us or go to the original page to have a discussion.

Top 10 Cisco Wireless “Good to Know”

1) Controller interface vlan tagging, native vlan 1

Cisco Switches by default do not tag the native vlan.  Also by default, the native vlan is 1, therefore vlan 1 is untagged.

When establishing a trunk to a Cisco Wireless LAN Controller, it's important to be aware of how tagged vs untagged are identified.

(4400-A) >show interface summary

Interface Name   Port Vlan Id    IP Address      Type    Ap Mgr Guest

---------------  ---- ---------- --------------  -----   ------ -----

ap-manager       1    untagged   1.1.1.118       Static  Yes    No  

management       1    untagged   1.1.1.111       Static  No     No  

When going through a WLC's initial startup wizard, if untagged for the Management Interface’s vlan is desired, enter '0' (zero) when prompted for the management interface's vlan, as this is equivalent to 'untagged':

(Cisco Controller)

Welcome to the Cisco Wizard Configuration Tool

Use the '-' character to backup

Would you like to terminate autoinstall? [yes]:

<snip>

Management Interface VLAN Identifier (0 = untagged): 0

 

2) AP Image Names: w7 vs w8

ap image names:

w7 = standalone

w8 = lightweight

examples:

Lightweight/controller based/capwap/lwapp image:

Cisco IOS Software, C1130 Software (C1130-K9W8-M), Version 12.4(23c)JZ, RELEASE SOFTWARE (fc1) c1130-k9w8-mx.124-23c.JZ

Autonomous/IOS/Standalone image:

Cisco IOS Software, C1140 Software (C1140-K9W7-M), Version 12.4(21a)JY, RELEASE SOFTWARE (fc1)c1140-k9w7-mx.124-21a.JY

 

3) AP Part Numbers: LAP vs AP

Most Cisco Access Points are available with two part numbers.

LAPxxx = shipped new from manufacturing with lightweight image

APxxx = shipped new from manufacturing with autonomous image

Same physical hardware.

Example:

Same physical ap's, the first is shipped with a lightweight image, the second with an IOS image:

AIR-LAP1142N-A-K9

AIR-AP1142N-A-K9

Most AP's can be converted between both modes.

 

4) Wireless  LAN Controller DHCP Handling

Wireless Lan Controllers perform 'dhcp proxy' by default.  The ‘Dhcp Server’ IP Address configured on controller interfaces acts the same way as an 'ip helper' statement on a Cisco router. 

With this configuration in place, an IP Helper statement on the wireless clients’ default gateway router is not necessary.

DHCP Proxy can be configured via the WLC’s GUI in 6.x and 7.x code (Controller -> Advanced -> DHCP).

Earlier code requires CLI access for configuration:

(WLC) >show dhcp proxy

DHCP Proxy Behaviour: enabled

(WLC) >config dhcp proxy disable

(WLC) >show dhcp proxy

DHCP Proxy Behaviour: disabled

Bootp-Broadcast:disabled

 

5) Lightweight AP modes: Local vs H-Reap (FlexConnect)

Local mode Access Point: tunnels all traffic to controller, controller responsible for tagging packets and putting them on the wired network, AP's switchport configured in access mode/non trunk.

H-Reap mode Access Point: ap's function similarly to standalone ap's, tag their own traffic, AP's switchport configured as trunk.  Vlan tagging requires configuration on each H-Reap mode AP (Via the controller’s Gui).

*H-Reap was renamed to 'FlexConnect' in 7.2 code.

 

6) Legacy Access Points End of Support

1500 Series, LAP-1505, LAP-1510: Last supported in 4.2.M controller code.

1000 Series, AP1010, AP1020, AP1030:  Last supported in 4.2 controller code.

1120/1230 Series, 1121, 1230, etc.  Last supported in 7.0 code.

1130, 1240, 1520. Last supported in 8.0 code (no support in 8.1 and later).

Software Release Support for Access Points

http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp78157

These Access Points will not join a controller running code later than supported.

 

7) AP console settings

•9600 baud

•8 data bits

•1 stop bit

•No parity

*********No hardware flow control******

These are the same settings for other Cisco devices.  It is essential that AP's console session have flow control disabled.  Most other Cisco devices will tolerate this setting if not disabled, but AP's will not.  The result is typically no display and/or keyboard response.

 

8) WLC Dynamic Interfaces, Does it Route?

Those familiar with Cisco routing and switching may get the impression that Wireless Lan Controllers have routing capability.  This may seem apparent due to the fact that multiple dynamic interfaces with ip addresses may be configured.  WLC's do not route.

The ip addresses assigned to the dynamic interfaces are not used for client traffic passing through the controller.

Dynamic interfaces' IP addresses primary functions are:

+ Referenced as Giaddr for DHCP Proxy (relay)

+ Multicast.  For wireless multicast receivers connected to local mode ap's, if the controller has IGMP snooping enabled, it will proxy/spoof IGMP reports to the wired network using the client's corresponding dynamic interface IP address.  If IGMP snooping on the controller is disabled, client IGMP reports are forwarded unmodified to the wired network.

+The IP address is checked when you do an intercontroller roam, so that  the WLC knows if you did a L2 or L3 roam, and whether to anchor your  traffic or to pass the MSCB entry to the new WLC.

 

9) Multicast

By default, multicast traffic is not forwarded by Wireless Lan Controllers for local mode ap's. 

A common source of confusion is that Autonomous Mode AP's will forward multicast just as they would unicast, so no configuration is required.  In the instance of Autonomous AP's being converted to Controller Based/Lightweight, multicast will no longer work until configured on the controller.

Since Controller based H-Reap mode ap's forward their own traffic, multicast will behave as if the AP were a standalone AP, and no controller configuration is required.

 

10) Anchored Wlans.  Where does authentication occur?

For Layer 3 authentication, e.g. Web Auth, authentication handling occurs on the Anchor Controller.

For Layer 2 authentication, e.g. 802.1x, authentication handling occurs on the Foreign controller.

…More Discussion

A: Regarding point 8 about the dynamic interfaces configured on the WLC, it is perhaps worth adding that they can act as source addresses when clients try to obtain an ip address via DHCP. This document explains more: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00805e7a24.shtml

 

B: You may want to add what else the dynamic-interface IP comes to play for.  The IP address is checked when you do an intercontroller roam, so that the WLC knows if you did a L2 or L3 roam, and whether to anchor your traffic or to pass the MSCB entry to the new WLC.

C: A note on the AP support - I believe that some APs will join WLCs with code 8.1 but new features won't be supported such as AVC on local FlexConnect due to hardware limitations. 

http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp99531 

Note The Cisco 1040 Series, 1140 Series, and 1260 Series access points have feature parity with Cisco Wireless Release 8.0. Features introduced in Cisco Wireless Release 8.1 and later are not supported on these access points.

…to be continued here…https://supportforums.cisco.com/blog/151191/top-10-cisco-wireless-%E2%80%9Cgood-know%E2%80%9D

 

More Topics Related to Cisco Wireless you can read here: http://blog.router-switch.com/category/technology/wireless/

Read more

About Cisco IP Phone Registration & Boot Up

April 1 2016 , Written by Cisco & Cisco Router, Network Switch Published on #Networking, #Cisco IP Phones, #Cisco & Cisco Network

CISCO IP Phone Boot UP Process

CISCO IP Phone Boot UP Process

Do you know the Cisco IP Phone Registration, Boot UP Sequence and related issues? Someone shared the main issues of IP Phone, SCCP & SIP Phone Registration Process with CUCM before. In this article we will talk something about the IP PHONE REGISTRATION ISSUES.

Firstly, let’s understand what Cisco IP Phone Registration & Boot UP Sequence are.

Step 1: Phone Loads Software (Image) and Starts the Configuration Process

Step 2: a. Phone Sends DHCP Request

b. DHCP Server Sends DHCP Response

Step 3: a. Phone Sends TFTP Request for a Configuration File

b. TFTP Server Sends the Default Configuration File

Step 4: a. TFTP Server Sends the Specific Configuration File of the Phone

b. Phone Registration Finishes

FIRST UNDERSTAND THE BOOTUP PROCESS, START TROUBLESHOOTING ACCORDING:

General Troubleshooting Sequence:

  • Disable DHCP and DNS to Test a Phone
  • Check for the Incorrect MAC Address on the Phone Label
  • Cisco CallManager and TFTP Services Do Not Run
  • Delete and Recreate a Phone
  • Understand a Network Trace File
  • Use Performance Monitor to Analyze Phone Activity
  • Manually Configure the IP Parameters on a 12 SP+ or 30 VIP Phone
  • Add Phones to Cisco CallManager
  • Enable, Configure, and Disable Auto−Registration
  • Manual Registration (Add an IP Phone Manually) etc....

THESE ISSUES COULD BE THERE:

  1. IP Phone Registration Toggles between Primary and Secondary CallManagers.
  2. Registration Rejected
  3. Cisco IP Phones Not Registered But seems to be working fine.
  4. Cisco IP Phones Take Too Long to Register.
  5. Cisco IP Phone Always Get Registered to the Publisher Server.
  6. Get "version error" on the Cisco IP Phone screen When Try to Register.
  7. Cisco phones causing excessive DHCP requests.

See the Figure"CISCO IP Phone Boot UP Process" above

Step 1: Phone Loads Software (Image) and Starts the Configuration Process:

During this step, these issues could be there,

* Registration with a Cisco CallManager server is successful only when the server adds the phone or when the server has Auto−Registration enabled. (The default for Auto−Registration is disabled.)

* Note: If the phone LCD screen does not light up, you could have a faulty phone. The phone also could be faulty if the message the phone displays never changes after you plug in the phone. Contact Cisco Technical Support to request a replacement if your phone is under warranty.

* If your phones do not use DHCP, see the Step 3a: Phone Sends TFTP Request for a Configuration File section of this document.

Step 2:

a). Phone Sends DHCP Request:

During this step, these issues could be there,

For Cisco 7940 and 7960: (to manually enable the DHCP Parameter on the phone itself):

Complete these steps on the Cisco 7940 and 7960:

1. Choose Settings.

2. Choose 3 (Network).

Scroll down to the DHCP Enabled parameter.

The selection must be Yes.

__________

Complete these steps on the Cisco 7910:

1. Choose Settings.

2. Choose 6 (Network).

3. Scroll down to the DHCP Enabled parameter.

The selection must be Yes.

__________

Cisco 12 SP+ and 30 VIP

Complete these steps on the Cisco 12 SP+ and 30 VIP:

1. Enter **#.

2. Enter 1.

3. Set all parameters to zero (0).

Note: Cisco 7910G supports only 10 MB speed, but 7910G+SW supports 10/100. If you have a 7910G, be sure to set the switch port that connects to the phone to 10 MB or Auto.

Any IP parameters that you have hard coded on the phones override the parameters that the DHCP server provides. In particular, the Alternate TFTP Server option overrides the TFTP server IP address that the DHCP provides. For information on how to reset your phone configuration to the original factory defaults, refer to either of these documents:

¨ Resetting 7900 Series IP Phones to Factory Defaults

b). DHCP Server Sends DHCP Response:

The DHCP response contains the phone IP address and the IP address of the TFTP server (which is usually a Cisco CallManager server). The response can also contain any of or all these common options:

· IP address of the default router (gateway)

· IP address of the Domain Name System (DNS) server

· Domain name includes option 150 for the TFTP server.

Step 3:

a). Phone Sends TFTP Request for a Configuration File:

  • The phone requests a specific configuration file. The name for this file is SEPMAC−Address.cnf. For example, the file name for a phone with the MAC address 0030.94C2.D5CA is SEP003094C2D5CA.cnf. If the file exists on the Cisco CallManager server, see the Step 4a: TFTP Server Sends the Specific Configuration File of the Phone section of this document.
  • If the phone is not in the Cisco CallManager database, the request for the specific configuration file results in a TFTP File Not Found response from the TFTP server. The phone then requests the file with the name SEPDEFAULT.cnf. If you have configured the Cisco CallManager server for Auto−Registration, this file exists and the server sends it to the phone. See the Step 3b: TFTP Server Sends the Default Configuration File section of this document.

Otherwise, the TFTP server of the Cisco CallManager server sends another File Not Found TFTP response. At this point, the phone restarts the configuration process.

b). TFTP Server Sends the Default Configuration File:

Note: This step only occurs if you have enabled Auto−Registration and the phone has not already registered

with the Cisco CallManager server.

If you have configured the Cisco CallManager server for Auto−Registration, it sends the SEPDEFAULT.cnf

file in response to the phone request. After the Cisco CallManager server database adds a phone by Auto−Registration, the phone has a SEPMAC−Address.cnf file. It does not reference the SEPDEFAULT.cnf

again.

Step 4:

a). TFTP Server Sends the Specific Configuration File of the Phone:

Note: This step only takes place if the phone creation occurred on the Cisco CallManager server. The configuration file contains several parameters for the phone. These include the device pool, the Cisco CallManager servers to use, configured speed dials, and other parameters. In general, any time you make a change in Cisco CallManager that requires the phone (device) to be reset, you have made a change to the phone configuration file.

b). Phone Registration Finishes:

The Cisco CallManager server sends the phone additional configuration elements during the final phases of the registration process.

In general, the registration process must complete successfully if the process goes this far.

To learn what takes place at this point, you need to set up a network analyzer to capture the IP packets that the phone sends to and receives from the server.

FACTS:

7961G Phone does not Register until it is Configured as a 7961>

IP phones CP−7961 and CP−7961G are basically the same platform. The G stands for global use that supports all languages.

So when you add a 7961G phone, you should add it as a regular 7961 phone. CP−7961G−GE is another IP phone with two gigabit Ethernet ports (10/100/1000).

If IP phone 7961G is added as 7961G−GE, it does not register with Cisco CallManager.

TASKS TO PERFORM:

Disable DHCP and DNS to Test a Phone

Check for the Incorrect MAC Address on the Phone Label

Cisco CallManager and TFTP Services Do Not Run

Delete and Recreate a Phone

Understand a Network Trace File

Use Network Monitor to Analyze Phone Activity

By default, Cisco phones are DHCP−enabled. If you do not use DHCP, you need to disable DHCP on the phone and manually assign the phone an IP address. In order to disable DHCP on a phone, use the phone keypad to program the phone IP address and other network addresses.

Enable, Configure, and Disable Auto−Registration

Manual Registration (Add an IP Phone Manually)

Note: If you have your Cisco CallManager servers set up in a cluster, every server has the configuration files for every phone that is in the Publisher database. Therefore, any Cisco CallManager server can serve as a TFTP server for the phones. The device pools to which you have assigned the phones determine the server with which the phones register. A phone can obtain the configuration file from a different server than the server with which the phone registers.

Original reference and more discussions from

https://supportforums.cisco.com/document/113336/ip-phone-registration-issues

More Related…

Understanding IP Phone, SCCP & SIP Phone Registration Process with CUCM

Understanding the Cisco IP Phone Boot Process & Voice Vlan
How to Save Power on Cisco IP Phones?
How to Start up a Cisco IP Phone?
Updated: Cisco IP Phone 7800 Series

Read more

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
<< < 1 2 3 4 5 6 > >>