Posts with #networking tag
Subnets and VLANs are two concepts that go hand-in-hand.
Best networking practice is a one-to-one relationship between VLANs and subnets.
Here are the top 10 things you should know about these critical components of Converged Plantwide Ethernet (CPwE) Design and Implementation:
- A Layer-2 network also refers to a subnet, broadcast domain and a virtual LAN (VLAN). Best practice is a 1:1:1 relationship between subnets, broadcast domains and VLANs. The Layer-2 network infrastructure devices in the Cell/Area zone are predominantly access switches.
- Layer-3 switches or routers are used in manufacturing environments. Layer-3 switches or routers forward information between different VLANs or subnets. They use information in the IP header (Layer 3) to do so. Regardless of the specific layer being connected, switches provide Industrial Automation Control System (IACS) networks with many of the safeguards realized by the natural separation inherent in existing IACS-optimized networks. Some switches promoted as Layer 2 switches also support limited routing capabilities, like static routing.
- Devices and controllers configured for multicast delivery need to be located within the same Cell/Area IACS network because these packets cannot be routed, meaning that any router will drop the packet before forwarding it outside the subnet/VLAN. Devices and controllers configured for unicast delivery, Implicit I/O or explicit messaging do not need to be within the same Cell/Area zone because that communication is routable.
- Logical segmentation is the process of outlining which endpoints need to be in the same LAN. Segmentation is a key consideration for a Cell/Area IACS network. Segmentation is important to help manage the real-time communication properties of the network while supporting the requirements defined by the network traffic flows. Security is also an important consideration in making segmentation decisions. A security policy may call for limiting access of plant floor personnel (such as a vendor or contractor) to certain areas of the plant floor (such as a functional area). Segmenting these areas into distinct subnets and VLANs greatly assists in the application of these types of security considerations.
- Network developers should strive to design smaller LANs or VLANs, while recognizing that the traffic patterns of an IACS may make this difficult if routing is required.
- Use VLANs in addition to any physical segmentation, and connect all Cell/Area LANs to Layer-3 distribution switches to maintain connectivity.
- Trunks are also an important concept when deploying VLANs. The inter-switch connections in a Layer-2 network deploying VLANs are referred to and configured as trunks because they carry traffic for multiple VLANs. The relevant standard is IEEE 802.1Q, which specifies VLAN tagging to carry multiple VLANs on Ethernet links between switches. IEEE 802.1Q is the prevalent and most often used standard.
- Management VLANs are also an important consideration when establishing a VLAN concept. In the IT and enterprise network, management VLANs are commonly used to access the network and IT infrastructure, separate from the data VLANs. If IT is involved in managing the IACS network, they may want to establish management VLANs on which only the network infrastructure has IP addresses.
- Two important considerations in designing a VLAN network are the use of VLAN 1 and the native VLAN. The native VLAN is the VLAN to which a port returns when it is not trunking. VLAN 1 is the default native VLAN on trunk ports on Cisco-based switches and therefore may use by a number of network infrastructure protocols.
- Define IACS devices to use a specific VLAN other than the native VLAN and VLAN 1; do not use VLAN 1 for any purpose. Some security threats assume that VLAN 1 is the default VLAN for data and/or management traffic and may target VLAN 1 in their attacks.
Article Source from http://www.industrial-ip.org/en/industrial-ip/convergence/vlans-and-subnets-10-things-you-need-to-know
More Related VLAN and Subnet Topics:
Cisco is always focusing on making network devices smarter and providing more intelligent and safer networking solutions for customers.
One of typical examples is Cisco Adaptive Security Appliance (ASA). When it encounters a critical unrecoverable error condition, it reloads itself and then automatically sends in the error report. This report is analyzed by Cisco and compared against all known issues. If Cisco has seen this issue before, we will:
- Alert the customer via e-mail that their device encountered a problem
- Include the bug ID and Headline of the problem the device experienced
- Indicate what versions contain a fix to this issue
This provides you with everything you need to know about the problem.
How is that for Smart?
The Cisco ASA also detects other error conditions, these (i.e.: fan failures, interface failures, other environmental alerts, etc…) and securely reports those back to Cisco. For critical events, it will automatically open a TAC case and start working on the problem. That may be initiating an RMA and shipping the part on-site, or it could be that a TAC engineer will call you to alert you to the problem and what the next steps are. For non-critical events, you will receive an e-mail to alert you to the problem and include guidance on the next steps.
In addition to this, we are investing in big data initiatives to mine the data being sent in and obtain insights on how we can better improve our software quality, or to quickly be alerted to any critical issue affecting multiple customers-all in an automated fashion.
Reference From: https://supportforums.cisco.com/docs/DOC-35118
More networking topics you can visit: http://blog.router-switch.com/category/networking-2/
For any network administrator, it is a necessary to know how to properly use logging. The Cisco IOS offers a great many options for logging. To help you know them well, we will discuss how to configure logging, how to view the log and its status, and list three common errors when it comes to logging.
The logging command in Global Configuration Mode and the show logging command in Privileged Mode are two simple but powerful tools to configure and show all Cisco IOS logging options. Let's take a closer look.
Configure logging in the Cisco IOS
When configuring logging, the most important command to know is the logging command, used when in Global Configuration Mode. Here's an example of this command and its options.
In order to help you know these options in a good way, let’s look at the most common ones.
You can configure the router to send buffered logging of its events to the memory. (Rebooting the router will lose all events stored in the buffered log.) Here's an example:
Router(config)# logging buffered 16384
You can also send the router's events to a syslog server. This is an external server running on your network. Most likely, the syslog server is running on a Linux or Windows server. Because it's external to the router, there's an added benefit: It preserves events even if the router loses power. A syslog server also provides for centralized logging for all network devices.
To configure syslog logging, all you need to do is use the logging command and the hostname or IP address of the syslog server. So, to configure your Cisco device to use a syslog server, use the following command:
Router(config)# logging 10.1.1.1
The Cisco IOS enables logging to the console, monitor, and syslog by default. But there's a catch: There's no syslog host configured, so that output goes nowhere.
There are eight different logging levels.
The default level for console, monitor, and syslog is debugging. The logging on command is the default. To disable all logging, use the no logging on command.
By default, the router logs anything at the level of debugging and greater. That means that logging occurs from level 7 (debugging) up to level 0 (emergencies). If you want to par down what the system logs, use something like the logging console notifications command.
In addition, the router doesn't enable logging to the system buffer by default. That's why you must use the logging buffered command to enable it.
View the status of logging and the logging itself
To view the status of your logging as well as the local buffered log, use the show loggingcommand. Here's an example:
Note that this router has enabled syslog logging and is sending it to host 10.1.1.1. In addition, console logging is at the debugging level, and the setting for local buffered logging is 10,000,000 bytes.
Three common logging errors
Logging can be frustrating at times. To help prevent some of that frustration, let's look at three common errors.
Not setting the terminal to monitor logging
If you Telnet into a router and can't see some of the logging you're expecting, check to see if you've set your terminal to monitor the logging. You can enable this with the terminal monitor command. To disable it, use the terminal no monitor command.
To determine whether you've enabled monitoring, use the show terminal command, and look for the following:
Capabilities: Receives Logging Output
If you see this, you're monitoring logging output. If it returns none for capabilities, then the monitoring is off.
Using the incorrect logging level
If you can't see logging output, you should also check whether you've set the level correctly. For example, if you've set the console logging to emergencies but you're running debugging, you won't see any debugging output on the console.
To determine the set level, use the show logging command. Keep in mind that you need to set the level to a higher number to see all levels below it. For example, setting logging at debugging shows you every other level.
In addition, make sure you match the type of logging that you want to see with the level you're configuring. If you configure monitor logging to debug but you're on the console and you've set it to informational, you won't see the debug output on the console.
Displaying the incorrect time and date in logs
You may see log messages that don't exhibit the correct date and time. There are a variety of options to control the date and time that appear on logging output (either to the screen or to the buffer). To control this, use the following command:
Router(config)# service timestamps debug ?
datetime Timestamp with date and time
uptime Timestamp with system uptime
More Notes: Remember that many problems require some kind of historical log to help find a solution. That's why it's important to make sure you've properly configured logging so you can use your logs to see the past.
Reference from http://www.techrepublic.com/
Cisco Aironet 36021 AP and Ubiquiti's UniFi AP are part of the so-called “wave 1” phase of 802.11ac standard.
These access points (APs) are theoretically capable of reaching data rate of up to 1. 3 Gigabits per second but actual maximum throughput speeds achieved during a test conducted by technology publication Computerworld.com just reached the 360 to 380 Megabits per second range.
Here is how the two access points fared against each other in terms of speed, features and performance:
Cisco Aironet 36021 AP–This access point came with an 802.1ac module. A Cisco 2504 Wireless LAN controller was use for the test.
The Aironet 36021 comes with two integrated 2.Ghz/5GHz dual radios. The 802.1ac module adds ass a 5-GHz radio supporting three spatial streams.
The AP supports the standard Control and Provisioning of Wireless Access Points Protocol (CAPWAP) and broadcasting up to 16 SSIDs. The maximum transmit power for both integrated dual band radios is 23 dBm and 22dBm for the 802.11ac module.
The Aironet 36021 AP is worth $1,495. Its accompanying 802.11ac model is $500.
Ubiquiti UniFi AC-The $299 Ubiquiti AP came with UniFi Controller software to manage the AP.
This access point has a 2.4GHz radio and 5GHz radio with three spatial streams that support up to four BSSIDs per radio. The radios maximum transmit power is 28 dBm.
This AP has a similar physical dimension as the Cisco unit but weighs about a pound more. It is straightforward to setup and configure just like the Aironet. The Ubiquiti AP has a user-friendly interface.
While the unit does not allow user to configure many settings it allows application of general wireless, network and guest settings across multiple UniFi Aps. User can also place access points on an uploaded map and view stats information on AP and client usage.
Testers found the Cisco AP performed four per cent to 22 per cent better than the Ubiquiti AP in the throughput test. The Cisco AP is recommended for larger enterprise networks.
They concluded that the Ubiquiti AP lacked advanced enterprise settings but is easier to setup and more ideal for small to midsize networks
---News from http://www.itworldcanada.com
More Related to Cisco Wireless Aps:
As service providers continue their IP network convergence, they also need to establish a business strategy that can provide a solid return on their next-generation network investment. Creating a network transformation plan is an essential part of the process that will help service providers increase the efficiency and flexibility of their next-generation networks and services while reducing operations expense (opex).
This Telecom Insights guide looks at what service providers need to know about deploying a converged network architecture that focuses on offering differentiated services that capitalize on their infrastructure and unique customer knowledge and how providers should go about building a solid network transformation plan that will result in the necessary ROI to compete and thrive.
In this series:
- A new vision for telecom network transformation
- Five steps to a next-gen network transformation plan
- Three mega-trends revolutionize telecom
A new vision for telecom network transformation
Much bigger than problems created by an economic downturn, network operators worldwide are facing much more pressure from longer-term erosion in the value of their stock-in-trade: transport bits.
Because business planners need to focus first on profit and revenue growth, today's fundamental market shifts mean that shorter-term planning will have to encompass a different vision of transformation and a different model of monetizing network investment.
The telecom services market is increasingly like a supermarket, with supermarket-like principles. Some services, like certain grocery items, will always be in demand but don't have much feature differentiation. These will become commodities in terms of price but will sustain the foundation of revenues and create customer loyalty. Other services, such as premium items in a store, will produce less revenue but command strong margins and boost profits. The transformation of the network marketplace to this model is the most significant goal for the industry.
Turning transformation on its head
Supporting this kind of transformation is still a hazy notion that could be called the Next-Generation Networks Services Architecture, or NGNSA. This architecture harmonizes the key components of next-generation network transformation:
- Service feature orchestration and syndication through developer partners, over-the-top partners, and traditional service provider partners.
- Business and operations management tools that are "service-focused" to align them with new directions in service creation and support a much higher level of automation of service lifecycle processes.
- Network infrastructure that can be quickly adapted to the traffic patterns and service-level agreement (SLA) needs of the widest variety of services, and tight coupling to the service layer of the network so network operators can differentiate their services from over-the-top solutions. This includes service delivery platforms (SDPs) for computing/software service components and network equipment for connection and transport.
The primary reason NGNSA notions are still fuzzy is the fact that activities are spread across a number of standards processes. While there are active liaisons between the bodies, standards are not moving in synchrony or even particularly quickly. As a result, network operators are looking increasingly to vendors for leadership in these areas and expecting those vendors to support the standards as they develop rather than waiting for them.
Nearly all major network operators worldwide report that they expect to buy into some vendor vision for integrated NGN services in the next year. For those operators, the choice of what approach to take is likely to be set by the priority they place on the three major NGNSA elements.
Complete solutions will drive partnerships
Of the three areas, the second (service operations and management) is probably the most developed in a standards sense, and thus network operators probably understand the positions of their vendor partners and have a good sense of convergence on standards approaches. But not every major equipment vendor has a service management strategy, and pressure to provide a complete solution is likely to create partnerships between management and networking vendors.
Service feature orchestration and third-party partner access to service elements for composition of retail services are likely to be the major focus of network operators in the near term. This area has not been active in the standards-setting sense for as long because the requirements of the space are less understood.
A number of announcements or commitments by equipment vendors in 2008 support the componentization, syndication and composition of services. And the architectures are only starting to emerge. The best approach here may be the most important single factor in creating NGNSA partnerships in the next two years or more.
Service-layer technology must create ROI
For the longer term, the last issue cannot be neglected. Service-layer technology that simply sits on top of connection/transport infrastructure ("anything over the Internet") empowers not only network operators but also over-the-top players. What network operators need and want is a way of creating value from their networks in the form of something linked with, but stepping beyond, the movement of bits. Little has been done in an organized industry sense to create specific service-layer partnership with the network layer. This partnership would provide a special benefit to those who build and own the networks. Thus it would justify network infrastructure investment more effectively by sustaining a higher return on investment (ROI).
ROI has been important for network operators for years, but the importance of ROI is magnified by a combination of economic uncertainty and increased pressure to evolve off the older TDM voice platforms in favor of IP-based services, including voice. 4G technology is based on IP voice, and fixed mobile convergence (FMC) is facilitated if voice technology in both wireline and wireless is based on VoIP. Major tier 1 operators are already announcing serious VoIP offerings, and this will put additional pressure on service-layer deployment because the move is almost certain to lower revenue per call-minute over time.
The role of IMS in the next-generation network
The fact that voice may be a driver for near-term change makes the IP multimedia subsystem (IMS) decision particularly important for operators. IMS is the approved and standardized way to manage mobile VoIP, FMC and non-voice mobile services. IMS is at least a candidate for supporting other NGN services such as video. Here again, standards may not keep pace with market requirements, and network operators may have to work with vendors prepared to take leading-edge positions on harmonizing IMS with service models beyond those involving SIP calling.
The ITU has suggested, in its NGN material, that IMS is one of several elements in what we have called here an NGNSA. But the precise role of IMS in that mix is not defined, nor are the other elements that would coexist with IMS. The vision of IMS's role in NGNSA may be the most critical of all in the near term because of the pressure to evolve voice services.
Network operators plan over a very long cycle--typically about seven years. That means that economic disturbances in the field are less a factor than they would be to industries with shorter capital cycles. Long planning cycles also mean that network operators require a very high degree of confidence in every step of their solution to evolving service needs and opportunities. That requirement is likely to generate new relationships and new levels of cooperation with vendors in the coming years.
Five steps to a next-gen network transformation plan
If transformation has a business goal and convergence a technical goal, then surely one of the challenges that face service providers today is how to navigate a commitment to both at the same time.
The problem is only complicated by the fact that transformation, unlike convergence, has no established formula or timetable. It's hard to get management support for something that, except for the goal itself, seems rather hazy.
The goal of transformation is to define a business strategy that creates sustainable revenues and profits from next-generation network (NGN) investments. Meeting that goal may require different specific technologies and services, but it can be accomplished with a general program that has some defined elements and timing recommendations. It is also important to address a few considerations or recommendations of what not to do, because some steps that are often taken are rarely successful.
Five steps to creating an NGN transformation plan
1. Picking a specific NGN service target set: This is the most problematic of all transformation steps. The most significant difference between the service environment of the past and that of the present is the short-term nature of buyer commitments to service paradigms. Basic voice and connectivity services are long-lived, in large part because they are so basic. As operators attempt to monetize NGN services, they must contend with the fact that the most valuable services to an operator are also those most valuable to service consumers, and this value proposition will change over time.
If committing to an inflexible NGN service strategy is exactly the wrong move, the best move is to create a service-layer architecture with the greatest flexibility possible -- both in terms of the way it can compose and combine service features and in the delivery options (wireless, wireline, computer, TV, phone, etc.) available. In fact, the difference between an IP network and an NGN is in the service-layer flexibility. IP alone simply creates a connectivity base that will be exploited by others but may not be profitable. NGNs must ensure the profit by providing services in a flexible way, not just transporting their traffic.
2. Restructure network, operations and business management systems around services, not technologies. In the second transformation step, the NGN service set will differ from the old set in that it will be made up of shorter-contract-period services with much wider markets. This means that inefficiency in service operations cannot be tolerated, or the costs will mount to swamp the budget. There are standards processes under way to guide this resetting of operations priorities, and many vendors already have tools and plans to support the switch. Services are the product of service providers, and management systems must reflect that reality.
3. Classify service opportunities at the high level. There is a taxonomy of service opportunities, starting with the basic classification of the customer (residential, enterprise, small business) and the nature of the value proposition the service will have for the customer (communication, data exchange, collaboration, hosting, software and computer outsourcing, etc.). For each opportunity element in the structure, there will be a total addressable market and a likely market penetration curve, and these can be used to set service opportunity priorities -- but not yet.
4. Identify the infrastructure implications of each of the opportunities. The goal here is not to plan out every piece of equipment or technology direction but rather to group the opportunities according to the type of infrastructure investment required to support them so that co-dependencies can be identified. In terms of an NGN transformation plan, the right answer will probably come by picking the opportunity group that has the best relationship between cost of infrastructure and benefit in terms of opportunity value.
5. Implement and execute a project to create an effective NGN transformation plan.The final step is a project to execute in the direction that is identified by the last step listed above. At the same time, the incremental steps involved in addressing other related opportunity groups should be explored to develop a plan for later investment and service deployment.
Projected timeline for an NGN transformation project
Most service providers have the information needed to support this sequence. If that is the case, operator experience seems to suggest that a task to complete the first three steps would require approximately eight months, assuming that work already done could not be leveraged. Service-layer deployments generally require about that same time for initial deployments, and so it may be that the operations processes in step 2 will be the inhibiting factor in preparing a quick response. This suggests that it is highly advisable that operations restructuring be given a high priority.
Every NGN program will be different, and every operator will have completed some of the tasks associated with each of the steps outlined here. An inventory of activities is often very useful in ensuring that nothing that has already been done is wasted, and this will also produce a faster path to NGN success.
Three mega-trends revolutionize telecom
Upcoming telecom changes are nothing short of revolutionary, or at least evolutionary, as trends emerge to create a single business model ecosystem out of telecom and the Web, content players and service providers find a workable balance of power, and cloud computing and social networking features gain in importance. Here's a look at the three main trends that will change telecom for the long haul.
1. An emerging online ecosystem joins telecom and the Web into a single business model
In December 2008, Alcatel-Lucent announced a company strategy based on creating the tools for this new ecosystem. Cisco CEO John Chambers had similar comments about binding the tools of the Web into a single, cohesive development framework.
In addition, articles about how Google was looking for a "fast lane" from access providers to speed its content to users seemed to make it clear that the old face-off between the over-the-top players and the telecoms might be ending. We've had years of "over-the-top" versus the carriers, and now we're heading for a future where the distinction will become very fuzzy indeed -- not through mergers and acquisitions but through cooperation.
For three or four years, telecoms and Web companies alike have been working to gain support from application developers to enrich their services. The iPhone and Android models were compelling because they generated a cottage industry that has driven the core product and service set to much greater utility, as well as greater adoption rates and revenue generation. The problem is that while everybody seems to want to support developers, everyone supports them differently.
No one has solved the question of how all these cooperative players manage to combine their efforts to create something stable, easily supported and capable of generating revenue for all through cooperative settlement. Standards have been marking time in this area, and now it looks as if equipment vendors are stepping in to create the framework for the new ecosystem. Why? Because capex is usually pegged to revenue, so if you can't help your carrier customers raise their top line, their spending will languish and so will vendor profits.
Service providers tried to solve this problem of cooperative ecosystem-building with standards, but they moved too slowly. They then started to pressure their equipment vendors to come up with a solution, and the Alcatel-Lucent and Cisco announcements are the result. There will be others; and it will be all about "service mashups."
2. A CDN/cloud computing model emerges for settlement for online services
This is why the new ecosystem is suddenly developing. For decades, the Internet has suffered from a basic problem of lack of settlement among the providers. Everyone pays for access to their ISP, but nobody pays for transit. Where there's no revenue, there's no investment.
On the other hand, content providers are happy to pay for content delivery network (CDN)caching, and Software as a Service (SaaS) providers are eager to find good cloud computing resources. The access carriers are putting money there, and these new resources link not to the Internet core but to the access networks. Telecoms worldwide have seen the opportunity to create a link between investment and revenue, and that new link threatens the whole legacy model of the Internet. It's bringing the Web guys to the table.
If every piece of content and every application were cached or hosted in metro centers, there would be no core traffic on the Internet at all. That extreme isn't likely, but what's certain is that the valuable stuff is migrating to the metro area. That forces the big players like Google to transport their own content via fiber to each access provider, which further bypasses the old Internet peering model.
You can't create a new ecosystem without having the pressure of the old one breaking, and that's what's happening. In the new ecosystem, content and application players will join with search and portal companies and telecoms to fight out a new balance of power.
The most significant winners will be the content/application giants, because getting commercially valuable content via a network connection is the stock in trade of the future.
3. Integrating social network features and relationship knowledge into communications is a trend in the making.
Yahoo launched an advanced email system that illustrates the value of relationship-managed communications, and this new notion will be incorporated into an expanding notion of presence as the central framework for communications and collaboration.
Presence-centered personal communication is the most "tactical" of the major trends because it will have an immediate impact on a number of emerging technical and product trends. Collaboration and telepresence both work better, and justify more investment, if they're mediated through social-network-like frameworks. This is likely to be one of Cisco's major areas of focus in harmonizing all of the Web 2.0 APIs into a new ecosystem. It's also likely to be a focus for unified communications and even things like IMS, femtocells and fixed-mobile convergence (FMC).
What technologies will benefit?
The technologies that will benefit from these major trends are:
- Fiber access, including FTTH and FTTN, because access providers will continue to fight speed wars with one another as they look to leverage their role in the new ecosystem.
- Metro Ethernet and optics, since all of the recent bandwidth created will be within metro areas. Look for new interest in hybrid Ethernet/optics products as well.
- Femtocells and FMC, which will probably benefit IMS. Mobile service competition and the need to integrate mobile and wireline features will be a big boost to this area.
- Operations software, particularly service management, abstraction, componentization, composition and third-party access via APIs.
The broadest impact of the trend on vendors will be promoting a more integrated product strategy that offers telecoms a link from revenue to investment. For many, this will involve partnerships supplemented by selective development or acquisitions that are intended to make each vendor's offerings unique and thus more likely to be accepted by buyers.
There are different network infrastructures (wired LAN, Service Provider Networks) that allows mobility, but in a business environment, the most important is the wireless LAN (WLAN). Most modern business networks rely on switch-based LANs for day-to-day operation inside the office.
Productivity is no longer restricted to a fixed work location or a defined time period. People now expect to be connected at any time and place, (you are in when you are out...) from the office to the airport or even the home.
Traveling employees used to be restricted to pay phones for checking messages and returning a few phone calls between flights. Now employees can check e-mail, voice mail, and the status of products on personal digital assistants (PDAs) while at many temporary locations.
Wireless LAN and Wired (Ethernet) LAN
Wireless LANs share a similar origin with Ethernet LANs. The IEEE has adopted the 802 LAN/MAN portfolio of computer network architecture standards. The two dominant 802 working groups are 802.3 Ethernet and 802.11 wireless LAN. However, there are important differences between the two.
WLANs use radio frequencies (RF) instead of cables at the Physical layer and MAC sub-layer of the Data Link layer. In comparison to cable, RF has the following characteristics:
i. RF does not have boundaries, such as the limits of a wire in a sheath. The lack of such a boundary allows data frames traveling over the RF media to be available to anyone that can receive the RF signal.
ii. RF is unprotected from outside signals, whereas cable is in an insulating sheath. Radios operating independently in the same geographic area but using the same or a similar RF can interfere with each other.
iii. RF transmission is subject to the same challenges inherent in any wave-based technology, such as consumer radio. For example, as you get further away from the source, you may hear stations playing over each other or hear static in the transmission. Eventually you may lose the signal all together. Wired LANs have cables that are of an appropriate length to maintain signal strength.
iv. RF bands are regulated differently in various countries. The use of WLANs is subject to additional regulations and sets of standards that are not applied to wired LANs.
WLANs connect clients to the network through a wireless access point (AP) instead of an Ethernet switch.
WLANs connect mobile devices that are often battery powered, as opposed to plugged-in LAN devices. Wireless network interface cards (NICs) tend to reduce the battery life of a mobile device.
WLANs support hosts that contend for access on the RF media (frequency bands). 802.11 prescribe collision-avoidance instead of collision-detection for media access to proactively avoid collisions within the media.
WLANs use a different frame format than wired Ethernet LANs. WLANs require additional information in the Layer 2 header of the frame.
WLANs raise more privacy issues because radio frequencies can reach outside the facility.
802.11 wireless LANs extend the 802.3 Ethernet LAN infrastructures to provide additional connectivity options. However, additional components and protocols are used to complete wireless connections.
In an 802.3 Ethernet LAN, each client has a cable that connects the client NIC to a switch. The switch is the point where the client gains access to the network.
In a wireless LAN, each client uses a wireless adapter to gain access to the network through a wireless device such as a wireless router or access point.
Once you have a basic understanding of IPv6, the next logical step on Cisco equipment is to test out the different capabilities that exist within Cisco equipment and IOS. Here we take a look at the configuration of IPv6 addressing on a Cisco IOS device.
Cisco IPv6 Static Address Configuration
IPv6 is a little different from IPv4 in that multiple IPv6 addresses can exist on a single network interface; this can include an Aggregatable Unicast Address, Link-Local Unicast address, and/or anycast address. The next few sections review the configuration of these different address types.
Configuring Unicast Addresses
There are two common address types that are assigned to each IPv6 interface; this includes an Aggregatable Unicast address and a Link-Local address. An Aggregatable Unicast address is allowed to be globally routed and operates similarly to a public IPv4 address.
An Aggregatable Unicast address can be configured in a number of ways. This article goes over the ways to statically address an IPv6 interface, which includes either specifying the whole IPv6 address and prefix-length or by using a prefix and using EUI-64. Table 1 shows the steps that are required to configure an Aggregatable Unicast address, using both a completely manual configuration and by using EUI-64.
Table1-IPv6 Aggregatable Unicast Address Configuration
Enter global configuration mode
Enter interface configuration mode
Configure the interface with a manual Aggregatable Unicast address
router(config-if)#ipv6 address address/prefix-length
Configure the interface with an Aggregatable Unicast address using EUI-64. This method uses the prefix and the Interface ID to develop the complete IPv6 address to use.
router(config-if)#ipv6 address address-prefix eui-64
A Link-Local address is used to communicate between devices that share the same link; these addresses are only allowed to be used on the local link and are not routed. Link-Local addresses will automatically be configured using the interface identifier (typically the MAC address) when IPv6 is enabled on an interface or the Link-Local address can be manually configured. Table 2 shows the steps that are required to manually configure a Link-Local address.
Table2-IPv6 Link-Local Address Configuration
Enter global configuration mode
Enter interface configuration mode
Configure the interface with a Link-Local address
router(config-if)#ipv6 address address link-local
Configuring Anycast Addresses
The concept of an Anycast address did not exist within IPv4 and is intended to be (along with additional use of Multicast) a replacement for some of the capabilities of IPv4 broadcast addresses. An Anycast address is intended to be configured on the interface of multiple network devices that provide the same services (i.e. the subnet gateway, DNS server or other server). When a client uses the address, the network will direct it only to the closest device assigned the address to the client. Table3 shows the steps that are required to configure an Anycast address on an interface.
Table3-IPv6 Anycast Address Configuration
Enter global configuration mode
Enter interface configuration mode
Configure the interface with an Anycast address
router(config-if)#ipv6 address address/prefix-length anycast
While there are certainly a number of differences between IPv4 and IPv6 other than the obvious address length, what should be kept in mind is that the majority of the fundamentals are very similar and anyone familiar with IPv4 should be able to transition with a little research and practice. Hopefully the contents of this article make the static configuration of IPv6 address on a Cisco IOS device a little easier.
Reference from http://www.petri.co.il/ipv6-static-address-configuration.htm
More Info and Tips Related to IPv6:
Routing protocols are used to exchange reachability information between routers. Routing information learned from peers is used to determine the next hop towards the destination. To route traffic correctly, it is necessary to prevent malicious or incorrect routing information from getting introduced into the routing table. This can be done by authenticating the routing updates exchanged between routers. Open Shortest Path First (OSPF) supports plain text authentication and Message Digest 5 (MD5) authentications.
Only three key point need to be remembered while configuring authentication in OSPF
A) Types of Authentication:
There are three different types of authentication available for OSPF version 2:
1) Null authentication: Null authentication means that there is no authentication, which is the default on Cisco routers.
2) Clear text authentication: In this method of authentication, passwords are exchanged in clear text on the network
3) Cryptographic authentication: The cryptographic method uses the open standard MD5 (Message Digest type 5) encryption.
B) Enabling OSPF Authentication:
OSPF authentication can be enabling in two ways:
1) Per interface: Authentication is enabling per interface using the "ip ospf athentication" command.
2) Area authentication: Authentication for area can enable using "area authentication" command.
C) Configuring Authentication Key:
In either case password must be configure at interface using "ip ospf authentication-key" or "ip ospf message-digest-key" command
A) Area based authentication Example:
To enable OSPF MD5 authentication:
Enter configuration commands, one per line. End with CNTL/Z.
Router(config-if)#ip ospf message-digest-key 1 md5 cisco@123
Router(config)#router ospf 100
Router(config-router)#area 2 authentication message-digest
To enable clear text authentication
Enter configuration commands, one per line. End with CNTL/Z.
Router(config-if)#ip ospf authentication-key cisco@123
Router(config)#router ospf 100
Router(config-router)#area 2 authentication
Interface based authentication Example:
To enable OSPF MD5 authentication:
Router(config-if)#ip ospf authentication message-digest
Router(config-if)#ip ospf message-digest-key 1 md5 cisco
To enable clear text authentication
Router(config-if)#ip ospf authentication
Router(config-if)#ip ospf authentication-key cisco
OSPF commands for each authentication types:
ip ospf authentication null
area number authentication
ip ospf authentication
ip ospf authentication-key Key-value
area number authentication message-digest
ip ospf authentication message-digest
ip ospf message-digest-key key-num md5 Key-value
OSPF Virtual Link Authentication:
Virual link is an interface in area 0.This mean if you enable authentication on Area 0 it will automatically turn authentication on virtual link but as discussed above password(Key) must need to enable on interface.As we know Virtual link doesnt have any interface on which you can configure authentication,authentication on virtual link can be configure using"area virtual-link" command under OSPF process.
Authentication failures can occur for two reasons:
1) Authentication type mismatch between neighbors
2) Authentication Key mismatch between neighbors
The below “debug ip ospf adj" output indicate mismatch in authentication type.
Router#debug ip ospf adj
OSPF adjacency events debugging is on
*Mar 1 00:02:30.279: OSPF: Rcv pkt from 10.1.1.2, FastEthernet0/0 : Mismatch Authentication type. Input packet specified type 2, we use type 0
*Mar 1 00:02:39.603: OSPF: Rcv pkt from 10.1.1.2, FastEthernet0/0 : Mismatch Authentication type. Input packet specified type 2, we use type 0
Router#sh ip ospf int fa0/0
FastEthernet0/0 is up, line protocol is up
Internet Address 10.1.1.2/24, Area 0
Process ID 100, Router ID 10.1.1.2, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.1.1.2, Interface address 10.1.1.2
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/1, flood queue length 0
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
---Resources from https://supportforums.cisco.com/docs/DOC-4449
You're probably familiar with 802.11a/b/g/n, all of which are protocols for the 802.11 wireless networking standards. You can safely bet that any device with Wi-Fi connectivity, from your laptop to your smartphone, supports at least wireless B or G, and if it came out within the past few years, it should support wireless N. 802.11n (or the latest draft of it, 802.11n-2009) is the fastest of the ones that are currently widely available. 802.11ac is a new Wi-Fi protocol and is intended to be the natural successor to 802.11n. You may have heard it called "5G Wi-Fi" or "Gigabit Wi-Fi."
Compared with the current 802.11n, what the new 802.11ac will bring to us? What some things you should consider while investing the 802.11ac? There are some main differences you need to know.
The first thing to get out of the way is - like past Wi-Fi standards - 802.11ac is backwards compatible with 802.11b, g and n. This means you can buy an 802.11ac-equipped device and it will work just fine with your existing router. Similarly you can upgrade to an 802.11ac router and it will work happily with all your existing devices. That said you will need both an 802.11ac router and an 802.11ac device to enjoy the standard’s biggest benefits. And those begin with…
With any new wireless technology speed is always the headline-grabbing feature but, as with every wireless standard to date, the figures tossed around can be highly misleading.
1.3 gigabits per second (Gbps) is the speed most commonly cited as the 802.11ac standard. This translates to 166 megabytes per second (MBps) or 1331 megabits per second (Mbps). It is vastly quicker than the 450Mbit per second (0.45Gbps) headline speeds quoted on the highest performing 802.11n routers.
So wireless ac is roughly 3x as fast as wireless n? No.
These figures are ‘theoretical maximums’ that are never close to being realised in real world scenarios. In our experience wireless n performance tends to top off around 50-150Mbit and our reviews of draft 802.11ac routers have typically found performance to be closer to 250-300Mbit. So 2.5x faster when close to your router is a good rule of thumb (though far more at distance, which we'll come to shortly).
Happily this gain is likely to increase as 802.11ac devices advance. Wireless 802.11n supports a maximum of four antennas at roughly 100Mbit each, where 802.11ac can support up to eight antennas at over 400Mbit each.
Smaller devices like smartphones tend to fit only a single antenna, but it gets even bigger in tablets (typically two to four antennas) and laptops and televisions (four to eight). In addition no 802.11ac router released so far has packed more than six antennas.
A final point: beware routers claiming speeds of 1,750 Gigabits. It is a marketing ploy where the manufacturer has added the 1.3Gbit theoretical maximum speed of 802.11ac to the 450Mbit theoretical maximum speed of 802.11n. Sneaky.
While speed is what will likely sell 802.11ac routers, range is equally important. Here wireless ac excels.
The first point to make is the 802.11ac standard lives entirely in the 5GHz spectrum. While some more modern routers broadcast 802.11n in 5GHz as well as 2.4GHz they remain relatively rare.
Consequently, the 5GHz spectrum tends to be 'quiet', meaning much less interference from neighborhood Wi-Fi. This more than counters the fact that, in lab conditions, 5GHz signals do not actually broadcast as far as 2.4GHz signals. 5GHz is also necessary to support the faster speeds of wireless ac.
The second key factor is 802.11ac makes ‘beamforming’ a core part of its spec. Rather than throw out wireless signal equally in all directions, WiFi with beamforming detects where devices are and intensifies the signal in their direction(s).
This technology has been around in proprietary form (it made a huge impact in the D-Link DIR-645), but now it will be inside every 802.11ac router and every 802.11ac device.
The combination of these two technologies is profound. This was most clearly seen with the Linksys EA6500 which hit speeds of 30.2MBps (241.6Mbit) when connecting to a device just two metres away, but still performed at 22.7MBps (181.6Mbit) when 13 metres away with two solid walls in the way. By contrast Linksys’ own EA4500 (identical except being limited to 802.11n) managed 10.6MBps (84.8Mbit) dropping to 2.31MBps (18.48Mbit) under the same conditions.
The real world result is 802.11ac not only enables you to enjoy the fastest 100Mbit (and beyond) fibre optic broadband speeds all over the house, but to enjoy it along with multiple streams of Full HD content, super low latency gaming and blazing fast home networking all at the same time.
Here comes the first caveat. The announcement of the Wi-Fi Alliance’s 802.11ac certification programme means 802.11ac equipped products can now be certified, but that process will take time as thousands of chipsets need to be tested.
Of course some manufacturers have jumped the gun. The 802.11ac routers we have tested are sold as ‘Draft 802.11ac’ products and while many may become certified through a firmware update, it is not guaranteed. Draft 802.11ac products are also not guaranteed to perform optimally with other Draft 802.11ac products - especially between different manufacturers. Certified products are.
The good news is the first certified chipsets are already creeping out and they come from the likes of Intel, Qualcomm, Cisco, Realtek, Marvell, Broadcom and Samsung - manufacturers with extensive networking expertise and who licence their chipsets to others. For example Intel has only one chipset certified - the ‘Dual band Wireless 7260’-but it is expected to be at the heart of most Haswell-powered Ultrabooks. The highest profile of these to date is the new 2013 MacBook Air.
Furthermore, adoption should be fast. The first 802.11ac routers carried a hefty premium, but this has dropped quickly to the point where price shouldn’t be a barrier to anyone keen to hop onto the bandwagon. In addition 802.11ac is extremely efficient and it brings power savings compared to 802.11n, meaning it is ideal for mobile devices. The Samsung Galaxy S4 and Samsung Mega phones already pack wireless ac.
As such, while 802.11ac products are only trickling out at present, it will turn into a tidal wave by early 2014.
Wait for 802.11ac?
All of which begs the question: should I now buy any device that isn’t 802.11ac compatible? The short answer is no. If you live alone in a small flat where you have no signal problems 802.11n may serve all your needs, but in larger, multi-user homes and homes with network attached storage the benefits of 802.11ac are simply too good to miss out on. Especially when buying devices you expect to keep for a number of years.
The longer answer is 802.11ac is a revolution that will be hard to actively avoid. Wireless ac will be built into most laptops and phones within the next 12 months and routers will increasingly come with it (though ISPs are typically slow to adopt new standards in the routers they give out, so plug an ac router into theirs and switch off their wireless to get around it).
It will take time and money for your home to be fully 802.11ac compatible, but it will be worth it.
---Original Reference from http://www.trustedreviews.com/opinions/802-11ac-vs-802-11n-what-s-the-difference
More Related Networking Reviews:
Software-defined networks (SDN) aren’t for everybody. Through programmability and automation, they promise to make IT life easier. But depending on your IT shop, the benefit may not be worth the effort… or investment.
There are eight considerations for IT shops evaluating SDNs, according to IT management software company Solar Winds. The checklist was compiled from interactions with customers considering or inquiring about SDNs:
1) The industry in which the organization is operating
SDNs work for cloud providers or for any organization that experiences dramatically scaling workloads, says Sanjay Castelino, vice president and market leader of SolarWinds’ network management business. Financial services companies and retail fall into that category, where “the dynamic nature of the business drives IT to be flexible,” Castelino says.
Some that do not fit this mold are publishing and healthcare, he says, two industries that are relatively stable, and not launching or moving around application workloads every day. “Their environments are not as dynamic,” Castelino says.
2) The size of an organization’s network
While there is not a distinct bare metal server or virtual machine threshold for implementing an SDN or not, the rule of thumb is hundreds of IP addresses.
“For 50 IP addresses, it’s not worth the change,” he says. “For hundreds of IP addresses, you might need the automation.”
Castelino recommends doing capacity planning before considering SDNs.
3) The level of complexity of an organization’s network
If there are requirements for a lot of network slicing or segmentation for security and isolation, you might be a good candidate for an SDN. If there are lots of virtual LANs to configure and manage, or there are VLANs that require more automation than others, SDNs might be a good fit.
But change shouldn’t be made just for the sake of it, Castelino says.
“You don’t want to make changes that break things,” he says. “Policy is not a simple task to go implement. Have to have someone deeply steeped in network engineering.”
And you have to validate and test the environment multiple times, he adds.
4) The Dynamic nature of an organization’s applications and workloads
This goes back to consideration No. 1: Are you a cloud operator or a hardback book publisher? How often are you launching new applications and closing others? How often are you moving workloads around? Is your environment static and predictable, or always changing, always moving and unpredictable?
5) The number of virtual machines within an organization’s network
“If you’re not at a few hundred, you’re probably early,” Castelino says. He reiterates that if an organization is running hundreds of workloads, it might be worth taking a look at SDNs. Below that level, and with SDN’s immaturity, it might be “way too early” to look at.
6) The organization’s need for agility, flexibility and scalability within the network
See Nos. 4 and 1: If you have a business or IT environment that scales quickly and changes dynamically, you want SDN. But the eventual ease of operations will come with some initial work. The time it takes to get into SDN is not small today, Castelino notes – it’s still at the bleeding edge of the technology curve.
“Network engineering skills and capital resources are going to be key,” he says. “It could be an expensive proposition so you need to ensure value on the other side.”
7) The organization’s need to simplify security measures and control access to applications
The benefit of SDN is that things get done the same way all the time, through policy, even though the environment is dynamic and always changing. Security and network access control in a dynamic environment can be a nightmare. It’s important to get policy enforcement right in this regard not only to ease operation but to ensure information stays where it should.
8) The organization’s access to personnel and capital resources
If an IT shop doesn’t have network engineering expertise, or a personnel is stretched thin, SDN is not the project to undertake, Castelino says.
“There will be lots of bumps in the road,” he says. “It’s going to be a lot of work and take time.”
SDN deployments are done in parallel with the production environment, test, evaluated, validated and tested again before they are cut over to the production network. It takes time, people and money.
In summary, SDN holds a lot of promise. There are a lot of problems it can solve… but also a lot it can start if the environment is not conducive to the effort and undertaking to transition to an SDN-programmable and automated IT operation.
“The hype cycle can sometimes lead to an ugly bursting of the bubble,” Castelino says. “SDN has its purpose. But if it is marketed as a panacea for everything under the sun, you’ll see a lot of dramatic failures. It’s not ready for everyone but some can get a lot of value out of it. You just need to go in with eyes open.”
Review resources from http://www.networkworld.com/news/2013/070213-sdn-271479.html