[New] 200-301 CCNA: Cisco 200-301 Free Exam Questions & Answers

 

Cisco CCNA Exam Description:

This exam tests a candidate's knowledge and skills related to network fundamentals, network access, IP connectivity, IP services, security fundamentals, and automation and programmability. The course, Implementing and Administering Cisco Solutions (CCNA), helps candidates prepare for this exam.

Cisco 200-301 Exam Overview:

• Exam Name- Implementing and Administering Cisco Solutions
• Exam Number- 200-301 CCNA
• Exam Price- $300 USD
• Duration- 120 minutes
• Number of Questions- 90-110
• Passing Score- Variable (750-850 / 1000 Approx.)
• Recommended Training- Implementing and Administering Cisco Solutions (CCNA)
• Exam Registration- PEARSON VUE
• Sample Questions- Cisco 200-301 Sample Questions
• Practice Exam- Cisco Certified Network Associate Practice Test

Cisco 200-301 Exam Topics:

• Network Fundamentals- 20%
• Network Access- 20%
• IP Connectivity- 25%
• IP Services- 10%
• Security Fundamentals- 15%
• Automation and Programmability- 10%
  

Related Articles:-

1. CCNA Practice Test: Your Best Assistants to Tackle CCNA 200-301 Exam
2. CCNA 200-301 Exam: Details, Preparation Options and Career Scope
3. Why Is CCNA Practice Test Important for Cisco 200-301 Exam Preparation?
4. Why Now Is the Time to Pass CCNA 200-301 Exam?
5. Will CCNA Practice Test Have an Impact on Cisco 200-301 Exam Score?
6. Some Useful Tips to Pass Cisco 200-301 Exam Using CCNA 200-301 Practice Test
7. Prepare for CCNA 200–301 Exam With CCNA Practice Test
8. Appearing For CCNA 200-301 Exam? CLICK HERE.

Continue reading

Monitoring for Your “Pets.” Observability for Your “Cattle.”

What’s the difference between monitoring and observability

Today, the second most active project in CNCF is the Open Telemetry project that provides a solution to the Observability problem of modern cloud native applications.

A question often asked is – I have monitoring for my legacy applications that I can extend to include any new apps, so why do I need observability? And what’s the difference between monitoring and observability anyways? There is much debate in the industry about this and if you ask ten people about their take on this, you will probably get ten different answers. Let us see some common interpretations of the two.

How legacy monitoring systems worked

Remember those times when we deployed our applications on a bunch of servers? We even knew those servers by name – just like our pets! To assess the health and performance of our applications, we collected events from every application and every network entity. We deployed centralized monitoring systems that collected standard (remember SNMP?) and vendor proprietary notifications. Correlation engines, which were basically vendor specific, executed on this vast number of events and identified failure objects with custom rules.

Here’s a very simplistic view of a legacy monitoring system:

Simplistic view of a legacy monitoring system

Trend analysis with custom dashboards came to our aid when we had to trouble shoot a production problem. Traditional monitoring worked off a known set of anticipated problems. Monitoring systems were built around that, reacting to issues as and when they occurred with a prebuilt set of actions. Failure domains were known ahead of time and identified with customized correlation rules. Telemetry data such as logs, metrics, and traces were siloed. Operators did a manual correlation of the three sets of data. Alerting was after the fact (or reactive) when thresholds exceeded a preset minor, major or critical threshold.

Servers hosting our critical applications were our “pets”

The entire application landscape, including infrastructure, was operationalized with proprietary monitoring systems. It seemed quite adequate. Operators had a deep understanding of the architecture of applications and the systems hosting them. Operating guides laid out alerting and details on resolutions. Everything seemed to function like a well-oiled machine aligned with the goal of those times – to help I&O teams keep the lights on.

And then the applications split and spread their wings, migrating to the clouds!

Enter microservices

We now deal with “cattle.” That is, short lived containers that come and go – everything seems dispensable, replaceable, and scalable. Considering the magnitude of containers, traditional monitoring systems prove totally insufficient to manage this new breed of applications with their unimaginable number of events. This scenario is only made more complex considering that there are no standards for cloud monitoring with each public cloud provider inserting their own little stickiness into the mix.

Microservices make it hard to update monitoring systems

Microservices no longer deal with long release cycles. With monolithic apps, there used to be a sync up among various teams on architecture changes to the services being updated. However,  it’s hard on I&O teams to update monitoring systems as microservices change. The bottom line is that I&O teams will possibly be operating apps that they don’t totally understand architecturally.

Enter “observability”

Observability promises to address the complexities of tracking cloud native application health and performance.

Observability is for systems that can be pretty much of a black box. It helps I&O teams who are trying to identify the internal state of the black box from telemetry data collected. It involves finding an answer to the unknown unknowns – meaning we cannot predict what’s going to happen but need the ability to ask questions and get answers so we can best formulate an action to the issue. Observability is about deriving signals from raw telemetry data as an integrated platform for logs, metrics, and traces.

In today’s dynamic, polyglot ecosystem where services are individually scaling to meet demands, simple monitoring built around a known set of events and alerts will fail. An Observability platform will ingest an insightful set of data generated by instrumentation of apps. Then, transform and collate trace/metrics/log data and funnel it into data stores that can then be queried to gauge the system health and performance. The key here is the context that can be attached to any aggregated data that can help decipher the internal state of the system and failures.

Extracting valuable signals from correlated data

In conclusion, the nirvana that we are striving for seems to be a scenario where we have literally all the data we need from instrumented apps as a correlated set of metrics, logs, and traces. Following this, the right set of tools will extract valuable signals from this correlated data revealing not only the service model but also failure objects to address health and performance issues.

Watch out for future blogs where we will explore OpenTelemetry as a solution to observability and explore MELT (metrics, events, logs, traces) with open source and commercial tools.

Source: cisco.com

Continue reading

Cisco MDS 9000 FSPF Link Cost Multiplier: Enhancing Path Selection on High-Speed Storage Networks

The need for optimal path selection

When embarking on a journey from one location to another one, we always try to determine the best route to follow. This happens according to some preference criteria. Having a single route is the simplest situation but that would lead to long delays in case of any problem occurring along the way. Availability of multiple paths to destination is good in terms of reliability. Of course, we would need an optimal path selection tool and clear street signs, or a navigation system with GPS, to avoid loops or getting lost.

In a similar way, data networks are designed with multiple paths to destination for higher availability. Specific protocols enable optimal path selection and loop avoidance. Ethernet networks have used the Spanning Tree Protocol or more recent standards like TRILL. IP networks rely on routing protocols like BGP, OSPF and RIP to determine the best end-to-end path. Fibre Channel fabrics have their own standard routing protocol, called Fabric Shortest Path First (FSPF), defined by INCITS T11 FC-SW-8.

FSPF on Cisco MDS switches

The FSPF protocol is enabled by default on all Cisco Fibre Channel switches. Normally you do not need to configure any FSPF parameters. FSPF automatically calculates the best path between any two switches in a fabric. It can also select an alternative path in the event of the failure of a given link. FSPF regulates traffic routing no matter how complex the fabric might be, including dual datacenter core-edge designs.

FSPF supports multipath routing and bases path status on a link state protocol called Shortest Path First. It runs on E ports or TE ports, providing a loop free topology. Routing happens hop by hop, based only on the destination domain ID. FSPF uses a topology database to keep track of the state of the links on all switches in the fabric and associates a cost with each link. It makes use of Dijkstra algorithm and guarantees a fast reconvergence time in case of a topology change. Every VSAN runs its own FSPF instance. By combining VSAN and FSPF technologies, traffic engineering can be achieved on a fabric. One use case would be to force traffic for a VSAN on a specific ISL. Also, the use of PortChannels instead of individual ISLs makes the implementation very efficient as fewer FSPF calculations are required.

FSPF link cost calculation

FSPF protocol uses link costs to determine the shortest path in a fabric between a source switch and a destination switch. The protocol tracks the state of links on all switches in the fabric and associates a cost with each link in its database. Also, FSPF determines path cost by adding the costs of all the ISLs in each path. Finally, FSPF compares the cost of various paths and chooses the path with minimum cost. If multiple paths exist with the same minimum cost, FSPF distributes the load among them.

You can administratively set the cost associated with an ISL link as an integer value from 1 to 30000. However, this operation is not necessary and typically FSPF will use its own default mechanism for associating a cost to all links. This is specified within INCITS T11 FC-SW-8 standard. Essentially, the link cost is calculated based on the speed of the link times an administrative multiplier factor. By default, the value of this multiplier is S=1. Practically the link cost is inversely proportional to its bandwidth. Hence the default cost for 1 Gbps links is 1000, for 2 Gbps is 500, for 4 Gbps is 250, for 32 Gbps is 31 and so on.

FSPF link cost calculation challenges

It is easy to realize that  high-speed links introduce some challenges because the link cost computes smaller and smaller. This becomes a significant issue when the total link bandwidth is over 128 Gbps. For these high-speed links, the default link costs become too similar to one another and so leading to inefficiencies.

The situation gets even worse for logical links. FSPF treats PortChannels as a single logical link between two switches. On Cisco MDS 9000 series, a PortChannel can have a maximum of 16 member links. With multiple physical links combined into a PortChannel, the aggregate bandwidth scales upward and the logical link cost reduces accordingly. Consequently, different paths may appear to have the same cost although they have a different member count and different bandwidths. Path inefficiencies may occur when PortChannels with as low as 9 x 16 Gbps members are present. This leads to poor path selection by FSPF. For example, imagine two alternative paths to same destination, one traversing a 9x16G PortChannel and one traversing a 10x16G PortChannel. Despite the two PortChannels have a different aggregate bandwidth, their link cost would compute to the same value.

FSPF link cost multiplier feature

To address the challenge, for now and the future, Cisco MDS NX-OS 9.3(1) release introduced the FSPF link cost multiplier feature. This new feature should be configured when parallel paths above the 128 Gbps threshold exist in a fabric. By doing so, FSPF can properly distinguish higher bandwidth links from one another and is able to select the best path.

All switches in a fabric must use the same FSPF link cost multiplier value. This way they all use the same basis for path cost calculations. This feature automatically distributes the configured FSPF link cost multiplier to all Cisco MDS switches in the fabric with Cisco NX-OS versions that support the feature. If any switches are present in the fabric that do not support the feature, then the configuration fails and is not applied to any switches. After all switches accept the new FSPF link cost multiplier value, a delay of 20 seconds occurs before being applied. This ensures that all switches apply the update simultaneously.

The new FSPF link cost multiplier value is S=20, as opposed to 1 in the traditional implementation. With a simple change to one parameter, Cisco implementation keeps using the same standard based formula as before. With the new value for this parameter, the FSPF link cost computation will stay optimal even for PortChannels with 16 members of up to 128 Gbps speed.

Source: cisco.com

Continue reading

Cisco User Defined Network: Better Serviceability, Better Insights

With our higher educational universities welcoming their students back to campus post-Covid, network admins are having a tough time handling the cumbersome and tedious task of onboarding student devices onto the network. With students bringing in their own devices all of which come alive only with network connectivity, it’s quite a tough task to ensure only the right devices are onboarded onto the network.

Cisco’s user-defined network solution helps in seamless onboarding. It also helps in providing a home-like environment to students. There are elaborate blogs that already cover the various benefits UDN 1.0 brings.

Bring your personal devices to the enterprise network with Cisco User Defined Network

With 1000s of students depending on the solution for their daily routines, it is crucial for admins to be equipped with the right set of tools to have visibility into their network. With the adoption of Cisco UDN solutions increasing, the network admin would love to have tools that can provide improved insights into their network and triage issues with lesser downtime. Cisco UDN 1.5 brings in a new dashboard and workflows to help admins have greater visibility of their network & identify any downtimes in their network sooner.

Improved Visibility into Cisco User Defined Network

With more and more students getting onboarded to the solution it is essential that IT admins have greater visibility & control over how their network is being used. This helps in effectively managing the network and deciding on how they need to channel their future investments.

UDN 1.5 brings in a detailed dashboard on Cisco User Defined Network cloud. This dashboard provides insights to the admin on how the Solution is deployed and how well it’s adopted by their students. These dashboards integrate data from Cisco DNAC Assurance, Automation & UDN Cloud and provide a single pane of glass to understand how their network is behaving.  The IT admin can easily understand how well the solution is adopted including details of the denser sites in their network with respect to UDN usage.

The dashboard shows up data on which Sites/SSIDs/RLANs UDN is enabled & the list of sites where it could be enabled to improve UDN adoption.

Figure 1. Summary & Sites View of your university

Customers have a view on how well the solution is being adopted on their campus and how many more clients could potentially be part of their UDN network. They also have a view of how many users are actively registering to the UDN network and the number of devices they are bringing to the rooms. It has several other insights like Top Failure/Top UDN User /Top SSIDs and Top Endpoint Type which enables the administrators to decide how they want to optimize their network.

Figures 2 and 3: Dashboards on Cisco UDN Cloud

Endpoint Management

In UDN 1.4, the ability to create rooms was limited to users with Cisco UDN apps. A user with the mobile app only had the ability to create UDN rooms. They could perform various actions on the endpoints like add/delete/move/reclaim the endpoints using the mobile app. This gave a lot of flexibility to the end user to decide which devices are part of his room, however, the IT admin of the university had no view/control over how the UDN rooms were designed. To solve this endpoint management and shared devices support are added in Cisco UDN 1.5 on the admin interface.

Endpoint Management screens on Cisco User Defined Network cloud do exactly what the student can do from a mobile app, however, the tenant admin has a view across various users in his network. The admin can add & remove endpoints from the student’s room, perform actions of bulk move and reclaim endpoints across the UDN room.

Figures 4 and 5: Dashboards for adding new device/ Sharing a device

In university networks, there are different use cases where users would want to share some common resources like printers across different endpoints. Such devices are not part of any rooms but are visible to all endpoints which are connected to UDN SSID. UDN 1.5 brings in the functionality to let tenant admin designate devices owned by the admin as ” Shared”. Admin user can provide the list of devices he intends to share with the students through the endpoint management screens on Cisco User-Defined Network Cloud.

UDN Network Health

Since the UDN solution had multiple touch points triaging any failures in the customer network was not always easy. Cisco UDN Health dashboard envisions identifying the issues which may happen in customers’ networks while trying to register/de-register the endpoints to UDN rooms. UDN dashboards expose an option to run test traffic on UDN network to identify any issues on their network. Any issues on adding/moving devices across UDN rooms can be triaged using UDN Health.

UDN Health requires the IT administrator to provide a mac address which the UDN health will try to add & remove from the tenant admin’s room. While doing this action, it traces through all the touch points in the system and queries other systemic data to identify the potential cause of device onboarding failure. The UDN health identifies the potential cause of onboarding failure and the possible corrective actions the IT administrator can take.

In cases when the onboarding failure is a result of misconfiguration in the customer network, UDN health will point out the potential next steps which the IT admin can take to fix his network. UDN health framework also allows customers to download the trace logs of the failed run which can be forwarded to Cisco TAC teams to triage issues further if needed.

UDN Health also supports scheduling of the trace runs every 6hr & 24hrs where a custom mac address will be added/removed from the tenant admin’s UDN room. This scheduled run helps ascertain the health of the network at different points of time during the day.

Figures 6 and 7: UDN Health

Issues Dashboard on UDN Cloud Service

The issues dashboard provides comprehensive visibility of the UDN network. The dashboard is integrated with Cisco DNA C Assurance and lists all issues seen on their wireless network. The IT administrator can isolate  UDN issues seen in their network and resolve the same using Cisco DNAC Assurance.

Figure 8: Issues Dashboard on UDN

Support for UDN extended globally

UDN Cloud solution is now available in US/European regions. Customers can benefit from multi-region support in UDN that ensures all customer data is stored in their respective regions. This helps in adhering to local regulations.

Source: cisco.com

Continue reading

New Networking Capabilities on Cisco Intersight

Bringing simplicity to complex hybrid cloud operations is the fundamental goal of Cisco Intersight. With a SaaS form factor, which alleviates the burden of installation and ongoing maintenance, Intersight provides comprehensive visibility, consistent day-to-day operations, and automated orchestration to ensure infrastructure is secure and compliant across all hybrid assets. In addition to the cloud SaaS option, we also provide a Connected Virtual Appliance (CVA) or a fully air-gapped Private Virtual Appliance (PVA) options to run on-premises.

To start, Cisco Intersight focused on the management and operations of compute, storage, and virtualization domains from a single cohesive user interface. The compute domain includes Cisco UCS servers and 3rd party servers, the storage domain includes Cisco HyperFlex, NetApp, Pure Storage, and Hitachi, and the virtualization domain spans VMware ESXi, and Amazon Web Services. We are very happy to extend Intersight’s management capabilities to the network domain. Cisco Nexus 9000 series data center switch support is now made generally available in Intersight platform.

What’s new?

Here are few things you can start doing at the get-go with these newly introduced capabilities:

1. Network visibility and operations: Like servers and storage arrays you can view and monitor your ethernet switches from the Intersight unified user interface and benefit from up-to-date network inventory knowledge. L2 neighbors view extends this infrastructure view beyond the switch itself to the identities of devices connected to the respective switch.

2. Cross-domain orchestration: You can construct end-to-end workflows for routine cross-domain orchestration functions such as provisioning a server in a particular VLAN and enabling respective switch ports, or consistently deploy private cloud infrastructure configuration to servers, switches, and storage arrays. Think NTP/DNS/Syslog/SNMP servers and MTUs across the network.

3. Management of Converged Infrastructure (CI) systems: Network domain capabilities facilitate creation comprehensive inventory for CI systems, such as FlexPod and elevate them as first-class citizens in the Intersight platform. Programmatic management of routine operations for these systems can be supported.

Cisco Intersight ethernet switch grid view

Cisco Intersight switch summary view

How it works?

Now you can onboard Cisco Nexus 9000 datacenter switches in NX-OS mode on Intersight. After claiming any Nexus 9K switches, Intersight presents rich inventory views including a summary, variety of switch hardware sub-systems, and switch configuration for that device.

Automate your network with the rest of the datacenter

Intersight Cloud Orchestrator (ICO) provides end-to-end orchestration and automated operations across the many infrastructure domains managed by Intersight. With Intersight workflow designer, you can construct cross-domain workflows in a no/low code environment using a curated Task Library of turnkey platform-integrated tasks and actions.

Intersight Task Library is inducted with a rich set of everyday switch management tasks for the Nexus 9000 datacenter switching family in NX-OS mode. These native tasks are backed by comprehensive inventory views, which deliver no-code experience for constructing and executing the cross-domain orchestration workflows. The task categories include basic system management tasks, comprehensive switch port management, and VLAN management. The granularity of these automation tasks is extended all the way to Create/Read/Update/Delete (CRUD) operations levels for the supported switch management objects. This allows you to construct automation workflows very closely aligned with your deployment.

Cisco Intersight switch port inventory view

Cisco Interisght switch L2 neighbor inventory view

Stay in control

You can effectively define and enforce your organization’s Role Based Access Control (RBAC) policies using Intersight Roles and Privilege Sets. Intersight has introduced two new Privilege Sets for Network Domain: Network Administrator and Network Operator. These Privilege Sets can be used to define appropriate Roles in the organization for governing the access to management functions of the network assets in Intersight. For example, a user with Network Administrator Privilege Set can only define and execute workflows using Network Task.

Getting Connected with Intersight

If you want to try it for yourself, you can create a free account on www.intersight.com and request a free trial of any Intersight capability, including orchestration. Feel free to onboard your Nexus 9000 switches and monitor those along with the compute and storage resources from a unified UI. End-to-end orchestration workflows supported by Nexus native task library, such as provisioning a server in a VLAN and turn-up respective switch ports, will help you reduce your Hybrid Cloud OpEx, deliver time-to-service acceleration, and reduce operational risks for everyday datacenter management operations.

Source: cisco.com

Continue reading

Why Isn’t your 5G RAN Transport Flexible and Efficient?

5G services can’t succeed without flexible, efficient, and programmable transport. To support and capitalize on 5G services, 5G RAN transport architectures have evolved to support virtualization and slicing, strict latency, jitter, stringent synchronization, and multi-cloud interconnect architectures. Recent Cisco innovations have focused on segment routing and IPv6 to improve network reliability with traffic engineering and to simplify network complexity with programmable transport, providing 5G transport operators with more control and the ability to build performance-based service level agreements (SLAs).

SRv6 microSID for converged public and private 5G

A virtualized radio access network (RAN) architecture allows operators to rapidly and flexibly allocate resources across public and private 5G deployments. To accelerate time to market and bridge the skills gap, communication service providers (CSPs) are choosing to deploy their services in partnership with hyperscale cloud providers (HCPs). Additionally, as data centers move from centralized to distributed to increase coverage and reduce potential performance issues with cloud-based services, an agile and scalable transport network is critical as part of a hybrid or multi-cloud strategy.

Figure 1. CSP architecture transition to hybrid or public cloud

Flexible service placement requires traffic engineering and end-to-end service quality assurance from the transport network. As well, transport slicing is critical to maintain guaranteed service quality and offer RAN service differentiation.

Figure 2. Transport slicing awareness for service experience

Slice awareness between the radio and the 5G core network is addressed by 3GPP specifications. To select the most optimal user plane function (UPF) demands, the underlying transport network must also be slice aware. Specific slice characteristics are dependent on the underlay 5G transport and how it allocates resources. The network can inspect slice information like the VLAN or ethernet header, classify the radio traffic to different slices, and allocate transport resources to meet varying levels of service from latency sensitive to best effort.

Figure 3. Enabling multi-service support starting from the edge of the network

SRv6 excels when the network has many interconnected end points and complex traffic engineering requirements. It brings programmability to the 5G transport architecture. The packet processing program is expressed as a list of instructions which are represented as 128-bit segments called segment identifier (SID). In complex traffic engineering, there are scenarios that may require carrying several segments in the IPv6 packet headers. Reducing this overhead is useful to minimize the packet maximum transfer unit (MTU) and enable SRv6 on legacy hardware devices with limited processing capabilities.

The microSID (uSID) introduces extensions to the SRv6 programming model with each 16-byte SID able to carry micro-instructions called uSID. uSID are represented with two bytes, and up to six uSIDs can be carried in a SID.

SRv6 uSID benefits

With SRv6 uSID, the network can be programmed to handle complex scenarios with simplicity. This additional programmability comes with several advantages:

◉ No change to SRv6 control plane, data plane, or segment routing header (SRH)

◉ Any SID in the SID list can carry a uSID

◉ An SID can carry up to six program instructions

◉ No routing extension required to support

The result is an ultra-scalable network able to support multi-domain deployments with minimal MTU overhead.

SRv6 microSID and O-RAN ALLIANCE Plugfest

Cisco partnered with Keysight Technologies to successfully validate O-RAN ALLIANCE-specified 5G RAN traffic on an SRv6 microSID-based programmable 5G xHaul transport network. Traffic characteristics like latency, jitter, synchronization, and network convergence were measured for each service slice over a multihop ring topology architecture.

Figure 4. O-RAN ALLIANCE Plugfest Validation Environment

In the validation test, latency sensitive fronthaul control plane traffic was carried with an SRv6-uSID-based L2 transport slice over EVPN. Non-latency sensitive management traffic was carried with an SRv6 uSID-based L3 transport slice over L3VPN. Synchronization was provided by an aggregation router to all nodes including radio units and distributed units. The Keysight Novus tester was used to simulate multiple radio units and distributed units, while the Keysight Metronome Timing System (MTS) was used to measure synchronization accuracy and relative timing.

SRv6 microSID instructions programmed the network to ensure service assurance for each slice and traffic type with the following results:

◉ Latency sensitive slice: 11us and average jitter of ~600ns

◉ Non-latency sensitive slice: 28us

◉ Relative timing accuracy between radio nodes: <30ns relative |TE|

◉ Service convergence during transport link failure: <22ms

These results confirm that the 5G xHaul architecture with SRv6 microSID meets all characteristics defined by eCPRI, O-RAN, ITU-T, and 3GPP standards for fronthaul, midhaul, and backhaul traffic over converged multihop transport architecture.

Source: cisco.com

Continue reading

Cisco 500-210 CSPOFE Certification- Questions & Answers with Syllabus

Cisco CSPOFE Exam Description:

This exam tests a candidate's knowledge and skills needed to configure, provision, and troubleshoot Cisco NCS 2000 product solutions.

Cisco 500-210 Exam Overview:

Exam Name- Cisco SP Optical Technology Field Engineer Representative

Exam Number - 500-210 CSPOFE

Exam Price- $300 USD

Duration- 75 minutes

Number of Questions- 45-55

Passing Score- Variable (750-850 / 1000 Approx.)

Recommended Training- SP Optical Technology Field Engineer Representative

Exam Registration- PEARSON VUE

Sample Questions- Cisco 500-210 Sample Questions

Practice Exam- Cisco Service Provider Optical Technology Specialization Practice Test

Related Article:-

 Follow Success with Cisco 500-210 CSPOFE Practice Test for your Career!

Continue reading

Deploy and manage networks globally with Cisco SD-WAN Multi-Region Fabric

How often do we prefer to avoid a detour to reach our home, office, restaurant, or subway station? The answer is – every time! We do not have the time for detours and delays in life as it affects our productivity and schedule. Similarly, business networks also need non-stop connectivity for greater performance and scalability.

As enterprises continue to grow and expand, they need a network that scales at the speed of their business. New business models drive the need for a network design that ensures seamless connectivity and greater application performance.

Multicloud infrastructure necessitates the need for networks with global connectivity

The accelerated adoption of a cloud-first strategy has changed how IT teams should design and deploy networks to manage global connectivity. With applications and workloads moving to multicloud architectures, businesses need to ensure that their SD-WAN design & architecture can scale easily without impacting connectivity and performance end-users expect across the globe. To achieve network scalability, organizations are pivoting to designs that involve splitting up the network into multiple regions, with geo-specific points-of-presence (PoPs) or Service Exchanges leading to a hierarchical architecture. This hierarchical architecture enables customers to use different traffic transport service providers for each region and for the central core-region network to optimize costs and deliver greater traffic and application performance. To make the best use of these different transports, enforce common- routing and business policy intent across regions, and leverage several rich features within SD-WAN, enterprises are leaning towards deploying end-to-end SD-WAN fabric across such networks.

Figure 1. The challenges of a tiered or hierarchical network design

Adopting a multi-region network design demands resolving a few network and operational challenges. To benefit from a multi-region type of network architecture, the use of a middle-mile WAN or global backbone WAN network is becoming increasingly prevalent. Enterprises are looking for ways to easily integrate middle-mile WANs with the rest of their network without the added complexity of operating, configuring, monitoring, and troubleshooting these networks as separate entities. As these deployments grow in complexity and scope, enterprises need a more effective way to scale connectivity across different regions to deliver greater application performance. An easy approach to accomplish this is to extend the SD-WAN fabric over the middle-mile WAN as well, thus enabling them to use SD-WAN to manage both intra- and inter-region site-to-cloud, site-to-site traffic via a single pane of glass.

Cisco SD-WAN Multi-Region Fabric – Your pathway to global network connectivity

Cisco SD-WAN Multi-Region Fabric is a new suite of capabilities that divides a single Cisco SD-WAN overlay network into multiple regions with a central core-region network for managing inter-regional traffic. You can scale the network architecturally and operationally by introducing the concept of regions and device roles natively into your SD-WAN solution. It enables you to extend the Cisco SD-WAN fabric across multiple regions within your network as well as the middle-mile, to provide:

◉ End-to-end SD-WAN capabilities and control​

◉ End-to-end encryption of inter-region traffic

◉ Transport independence​

◉ Performance measurements

◉ Greater control over traffic paths between domains

Figure 2. Multi-Region Fabric reducing operational complexity by introducing ‘regions’ and device ‘roles’ natively into Cisco SD-WAN

Multi-Region Fabric offers advanced capabilities such as region-aware routing, simplified site scalability for higher throughput, and reduces the complexity of network architecture and policy configuration. It provides the ability to enforce a common traffic steering policy across the entire WAN or on a per-region(s) basis and end-to-end WAN segmentation – all via a single dashboard (vManage) to configure, monitor, and troubleshoot the network. This new capability within the SD-WAN fabric allows the creation of a globally distributed network in minutes with just a couple of clicks.

Multi-Region Fabric means reduced complexity, increased scalability & greater performance

This new architecture can provide significant benefits for customers, partners, and Managed Service Providers (MSPs) who are considering the adoption of a hierarchical network design (with a middle-mile) for use cases such as:

◉ Regionalization of network services such as Security, Identity Management, Netflow, Logging, WAN optimization, etc.

◉ Improving multicloud and SaaS user experience by providing high-quality onramps into Software as a Service (SaaS) and any cloud infrastructure providers like Amazon Web Services, Microsoft Azure, Google Cloud Platform) via regional PoPs.

◉ Reducing time spent on the last mile for user traffic.

◉ Adapting network scale, compliance, or resiliency in a geo/segment/region-specific manner.

The Multi-Region Fabric Advantage  

◉ Scalable architecture to address dynamic network needs & business intent across regions

◉ Simplified policy design brings operational simplicity by eliminating the need for complex business/routing policies

◉ Flexibility to select the best transport for each region provides better performance for traffic across geographical regions

◉ Operationally easier to deploy and manage

Your growing business needs a network that can keep up with it, and Cisco SD-WAN Multi-Region Fabric can help you build and manage that network for you!

We understand deciding how to deploy SD-WAN for the best network scalability can bring uncertainty. How you reduce costs and complexity, simplify policy management, provide secure, seamless connectivity, and ultimately deliver superior user experience may also be difficult to fully understand. Join us for a live webinar and demo to learn more. Our speakers Hamzah Kardame, Leader, Product Management for Cisco SD-WAN, and Tahir Ali, Technical Marketing Engineering Technical Leader for Cisco SD-WAN will discuss:

◉ Why do networks need more scalability and flexibility in today’s hybrid and multicloud environments?

◉ How are WAN architectures evolving today and rise of middle-mile WAN-based network designs?

◉ The challenges that come with adopting such next-gen WAN architectures

◉ Multi-Region Fabric capabilities are available within Cisco SD-WAN to help support this transition.

◉ How Cisco SD-WAN Multi-Region Fabric works and what is ahead

Source: cisco.com

Continue reading

Managing the environmental impacts of European roadways and intersections

When I was growing up in Scotland, my grandmother would pass knowledge on to me in the form of proverbs. When I’m waiting at a red traffic signal I remember one of her many sayings “If it’s fur ye, it’ll nae gae past ye”, roughly translated as “if it’s for you, it won’t go past you.” No need to worry, you’re green time will come. At traffic signals everybody loves a green light because it means “go”. I believe that for the entire smart roadways movement, green should mean go, too. There is an important focus on being green. From a transport point of view, this means careful management of the unwanted side effects of the transport process, while maximizing the good things that we desire – safety, efficiency, and great customer experience. It is a challenge to go for green while also attaining the other goals. It’s not easy, but it is absolutely possible with the right approach.

“Road transport constitutes the highest proportion of overall transport emissions (in 2019 it emitted 72% of all domestic and international transport GhG).”

What it means to be green

First, let’s define what it means to be green from a roadway point of view. The figure below captures the process that we need to follow. We can be greener by understanding challenges, developing appropriate responses, and implementing solutions that support responses.

Green has particular relevance for urban traffic signal control as every driver likes green traffic lights to keep going. More important is the ability to manage journeys through the road network in a way that optimizes traffic flow as it varies over the course of the day. Ideally, advanced traffic management will exactly align the green signal time with the traffic flow on each approach.

Greenness for roadways

Let’s discuss an ideal, one-way journey as depicted in the figure below.

The pink line represents the planned or ideal journey, the red represents the actual journey. The nodes represent stage points in the journey. They could be timing points for a transit service, or modal interchanges for a traveler. They might also be major intersections along a limited access highway. For example, at point 2, the traveler might switch from local bus to commuter rail. You can see that at point 1, the journey is taking longer than planned. Time is made up between points 1 and 2, but lost again between points 3, 4 and 5.

There are two points that I would like to make here:

1. First, the planned or ideal journey must be optimized for greenness: minimum carbon footprint, fuel consumption, and other factors that affect greenness. These include choosing the best mode of transport for the prevailing condition, matching the journey’s purpose. It also includes managing those modes as effectively as possible, adapting to changes in the demand for transport and prevailing operating conditions. It is also essential to inform travelers about the choices they have for any journey, for any purpose, and at any time. These might be pre-planned, scheduled journeys, or spontaneous travel decisions. Mobility as a Service techniques can be used to inform the traveler, help them make a single reservation across the entire journey from origin to destination and support a single, convenient electronic payment for the travel services to be used.

2. The second point is that any deviation from the ideal or planned journey can be viewed as a “loss of greenness.” In this case, the cumulative journey time increase (the red areas) could be caused by congestion or delay, reducing the journey greenness. This comparison of an ideal to actual journey is a technique used in aviation but typically not in surface transportation. In order to attain green, it will be necessary to have sufficient data collection and analytics capability to plan the optimum journey and monitor deviation from ideal during the actual journey. It will also be necessary to have the degree of situational awareness and management capability to improve the actual journey in formative, near real time ways. It is interesting to note that taking this approach to defining and measuring greenness also enables other factors to be optimized including safety, efficiency, user experience, and equity. Equity is improved by operating cost reductions making transport more accessible to all by reducing travel costs. We must go green and use management tools to stay green, for every stage of every journey.

Achieving greenness

This is complicated and yes, as I said at the start, it is not easy, but it is entirely doable. It can be done by applying information and operational technologies such as those depicted in the figure below.

The operational technology is the part of the iceberg under water, unseen but irreplaceable. Information technology consists of various elements above the water, which deliver visible impacts but rely on the unseen operational technology. Together they support the range of customer facing applications that deliver greenness. Like the iceberg, I am focusing on just the tip of the greenness issue.

Technology can enable us to determine carbon impacts for different stages in the journey and all modes of transport. We can even look at the supply chains that deliver transport infrastructure and vehicles, ensuring that we optimize the bigger picture supporting circular economic approaches. Smart roadways and intersections are crucial elements in this due to the proportional impact that effective operations have on greenness. We can not only make our roadways greener, but also the entire transport system. From better intersection management to world-class high-speed highway operations, we have the tools available now to go green.

Green is for now

So why is it important for roadways to be greener now? We want to save the planet and reduce greenhouse gases (GhG)—bold political goals have been set. Transport contributes a significant amount of GhG, especially road transport, so even a relatively small improvement would be significant. If we are to achieve these bold goals within the required time, then it’s time to start planning and implementing. There are proven technology solutions that can be implemented off the shelf including advanced traffic management, electric cars and trucks, AI based decision support and advanced sensors. Robust, trusted OT networks can underpin the attainment of bold goals.

Grandma’s guide to greenness

In addition to her many sayings, my Grandmother would also give me sage advice. One piece of her advice was that to get what you want, there are two fundamental steps required. Step one is to decide what it is you want. Step two is to ask for it. We have obviously decided that we want greener roadways and transport. So now we have to ask for it by designing, specifying, and procuring it. It’s still not easy being green, but it is now easier than ever due to bold political action and capable technologies. Let’s go for green.

Source: cisco.com

Continue reading

Migrating to 6GHz

With more than 18 billion devices in use and 4.2 billion more to be shipping in 2022, the sheer size of existing Wi-Fi deployments worldwide is just mind-boggling. In view of the new Wi-Fi 6E and 6GHz adoption push, it is critical to evaluate what are the best ways to do a migration from existing Cisco on-prem legacy networks into the new world of 6GHz deployments.

For Cisco Enterprise customers, there are several aspects that need to be evaluated for any successful migration planning:

• Existing controller type:
• is it AireOS?
• Model? (Basically, can it  run 8.5 or 8.10?)
• is it IRCM capable (2504/wism2 can’t do mobility to 9800)
• Access point Inventory:
• Are there any 802.11n models still in use? (per example, 2600, 3600, 1520, 1600, etc)
• Are there any Wave1 APs? (last generation of IOS, per example 1700, 2700, 3700)
• Mesh deployments?
• PoE support:
• What is the maximum supported power standard? (802.3bt, 802.3at, etc)
• Any power budged constraints per port?
• Or APs are powered by power injectors?
• Current 5GHz TX power
• Is my network running on average at power level 3-4?
• or it is around 1-2?

6GHz adoption is only supported in the Catalyst 9800 IOS-XE controllers, running 17.7 or higher. This imposes some additional considerations either on controller type migration, or about legacy access points that may need to either be migrated, or supported through Inter Release Controller Mobility (IRCM) solutions

Legacy Access Points

Figure 1. Legacy APs

Over the years, it has always been possible to do co-existence of previous generations of access points with the newly introduced models, ensuring both smooth network upgrades and capacity expansion. Adding new APs is normally not an issue until we hit the scenario of inter-generation gaps.

If a network that for any reason is still running devices 2 generations away (for example, a 2602 AP), and now needs to include new 802.11ax models (for example 9130) or jump to the  9136/9166/9164  for 6GHz support, this will need more complex migration paths.

When there are multiple generation gaps, if the legacy controllers can support IRCM to the IOS-XE 9800,  it is perfectly possible to design a migration plan, without the need to do a “forklift” installation.  This will ensure very little pain to users, and keep the network running until everything is migrated to the new hardware and standards

In the following table, we can see a summary of software support ranges and migration options for most access points models from 11n generation models:

Model/Series	Last AireOS Support	IOS-XE support	IOS-XE AP equivalent	Migration Notes
700/700W Series	8.10	Not supported	9105	Migration through IRCM
1040	8.3	Not supported	9115	AP needs to be replaced
1260	8.3	Not supported	9115	AP needs to be replaced
1600	8.3	Not supported	9115	Either 8.5 IRCM, or Hardware replaced
1700	8.10	17.3	9115	Migration through IRCM
2700	8.10	17.3	9120	Migration through IRCM
3700	8.10	17.3	9130	Migration through IRCM
1810/1810W	8.10	Up to 17.3	9105	Hardware replaced or IRCM between IOS-XE versions
1830/1840/1850	8.10	Supported	9105	Directly supported
AP802/AP802H	8.5	Not Supported	ISR10xx	Migration through IRCM
2600	8.5	Not Supported	1920	Migration through IRCM
2800/3800/4800	8.10	Supported		Directly supported
1540	8.10	Supported		Directly supported
1550	8.5	Not supported		Migration through IRCM
1560	8.10	Supported		Directly supported
1570	8.10	Up to 17.3		Migration through IRCM

For a complete list, you can check the Cisco Wireless Solutions Software Compatibility Matrix, alternatively, you can run the Wireless Config Analyzer Express, to check your migration readiness

Figure 2. AP Migration Decision Flow

Legacy Controllers

Figure 3. Legacy Controller

Depending on the existing controller type, the migration may take different paths. Some scenarios will be simple, allowing a smooth transition. Others may need additional steps to successfully migrate into a Wi-Fi 6E network

What to expect:

◉ “Generation 1” controllers: 5508, 8510. They can support up to 8.5 AireOS version, which will allow mobility scenarios between them and new IOS-XE 9800 controllers (Inter-release Controller Mobility, IRCM support).  Also, they will support  both IOS and AP-COS access points, from 1700 to 3800 models (Wave1, Wave2 802.11ac )

◉ “Generation 2” controllers: 5520, 8540, 3504 . All of these can support up to 8.10 AireOS, also allowing IRCM scenarios with 9800. AP support will additionally include 802.11ax models, like the new Catalyst 9105, 9120, and 9130. etc.

◉ “Generation 1” controllers without IRCM: 2504, WiSM2, vWLC, 7510. No mobility is possible between them and IOS-XE, so additional steps with different migration scenarios are needed

Figure 4. Controller Migration Decision Flow

Migration Scenarios

In general, we should try to migrate “per RF blocks”, defining it as a roaming area or domain where clients can move normally between access points, before hitting idle timeout. Basically, move these RF blocks completely, into the new APs, and IOS-XE controllers. For example, either move a building or a complete floor into the new hardware and software.  We should avoid “salt & pepper” deployments, mixing APs on different controllers at the same time. Not because it is not supported, but because mobility will be more complex, and it may lead to issues sooner or later (just a problem prevention action)

For scenarios where it is impossible to break the RF environment into differentiated blocks (for example a very large building like an airport, or a fully open space office), we will have to either set up artificial boundaries based on roaming frequency and usage or do a forklift upgrade

Figure 5. Example of RF area/building migration

What happens if the AP model is not supported in any IRCM version?

This could be the scenario of a legacy controller, still working in 8.3, with some AP models that are not supported beyond that version. For example, the scenario of 20 APs of 2700 Series, and 10 APs of 1042 Series.

The 1040s are not supported in 8.5. In this case, the preferred option is to prioritize the replacement of those APs first, moving the impacted area into 9800 as the first step. Sometimes, customers have mixed models across a given building. For example, the mix of 2700 and 2600. In those scenarios, the best option is to consolidate models per supported version, moving all APs of a given type together, so they are contained in a specific RF space  in order to facilitate migration in blocks

Scenario 1: Legacy Controller supports IRCM

This will be the most common scenario, where we have either 8.5  (5508/8510) or 8.10 (5520/3504/8540) AireOS controller.  The migration picture will start with the creation of  IRCM setup between AireOS and 9800 controllers, then either replace APs in RF areas connecting them to the new controller, allowing mobility to act when a client needs to roam between legacy and new RF areas.

This method allows the smooth coexistence of both controllers, with RF areas migrated as needed, without any overnight switchover.

Things to keep in mind:

◉ If the controller is limited to 8.5 (5508, 8510), we will need a special IRCM version (8.5.182.104), to connect them to IOS-XE

◉ In general, it is best to split the RF network into different areas, configuring different RF group names between the legacy and IOS-XE controllers. This way each group can do the best calculations that their respective version allows. We should make sure that “Avoid Foreign AP Interference” is enabled on RRM/DCA configuration (it is by default)

◉ Always configure the primary/secondary controller name in access points. The new controllers will reject unsupported APs, but if any AP could work in both controller types, this will avoid APs joining the wrong one, or flip-flopping between them, until the migration is ready to proceed

Scenario 2: Legacy Controller not supporting IRCM

If the legacy network is running on a controller model WiSM2, 2504, 7510, vWLC, it is not possible to establish an IRCM connection between the old controller to the new 9800 handling the 6E APs. This limits significantly the options that are available, and it forces a more aggressive migration process

Migration alternatives:

◉ Keep the two networks separated, and migrate physical RF areas as new APs are added, replacing the old ones. No roaming is possible, and it is very important to keep client VLANs different between controllers, to avoid ARP proxy issues between both controllers. During this process, we must take care on preventing roaming events as client identity, address, etc, will be lost on the change between controller types.  For example, the ideal scenario is to move a complete building from one controller to the new one, doing a forklift AP replacement overnight.

◉ Avoid migrations “per floor”, as in most building types, it is normal to see clients roaming between APs on different floors

◉ Temporarily, replace the legacy controller with one that supports IRCM

Scenario 3: AP is supported up to 17.3 but not in later versions

This will happen when “Wave1” APs are still present, for example, 1700/2700/3700 AP models. For this type of migration, it is possible to move all APs into IOS-XE, with the 17.3 release, then add a secondary wlc to host the new Wi-Fi 6E APs, using 17.9, and establish an IRCM link between both controllers.

On this option, it is possible to do a graceful AP replacement from Wave1, into Wi-Fi 6E models, always trying to do the technology migration, per physical roaming RF area as described (per building, floor, etc). Once all APs are migrated, the 17.3 controllers can be decommissioned

In some instances, the customer may deploy a 9800-CL in 17.3 as a temporary controller to host the legacy APs

6GHz RF Coverage vs 5GHz. AP replacement scenarios

One common discussion point is: How different is going to be the cell coverage, in 6GHz, when compared to a 5GHz AP?

People will want to take a 5GHz AP and do a 1:1 replacement with a 6GHz supported AP, this may seem reasonable, but there are some aspects to consider:

◉ As WiFi-6E uses a higher frequency, the propagation characteristics are different, the signal drops slightly faster in 6 than in 5GHz. The difference should be around 2 dBm on measurements over the same distance. Material absorption will be different as well.

◉ 6GHz has different regulatory power constraints than 5GHz. Currently, most deployments will be using Low Power APs (for simplicity sake’s, let’s say 24dBm in FCC, 23 dBm in ETSI). This means that depending on the current network AP radio’s power levels,  using 6GHz may result in a slightly lower power output

Rule of thumb:

◉ If your power level average is around 3-4, it is possible to do a 1:1 AP replacement, and have a similar coverage level in 5 and 6 GHz

◉ If the power level is in 1-2, then you may need around 10 to 20% additional access points

The easiest way to know the average power level per site is to use WCAE tool and check the “Channel Stats 5GHz” tab. This will present a summary per channel, either at controller, or site tag level, of the average power levels (among other information).  For example, this is a network where migration to 6GHz may need additional access points:

Figure 6. Example of site with low 5GHz coverage

Versus this other one, where the deployment is running on low power, so fitting without issues into 6GHz requirements:

Figure 7. Example of site with good 5GHz coverage

If you use the latest version (0.9.11) of WCAE, you can also get a “6GHz predictive” view of how the power distribution, Nearby relationships, and RSSI for clients would look, if you replaced your current APs with 6GHz capable hardware. The tool will match ETSI or FCC regulatory requirements, adapting powers and differences as needed. This is useful to get a taste of how the network would look, doing a direct migration, without adding any APs.

Figure 8. 6GHz Predictive RRM modeling

For complex or demanding deployment scenarios, the recommendation will always be: do a site survey

Source: cisco.com

Continue reading