Tuesday, 28 February 2017
Amazon's AWS S3 Outage: What We Know
from Tom's IT Pro
via CERTIVIEW
Panasonic Toughbook CF-33: The Chuck Norris of Tablets
from Tom's IT Pro
via CERTIVIEW
Samsung Galaxy Book Communicates with Your Phone
from Tom's IT Pro
via CERTIVIEW
BlackBerry KEYone Adds a Fingerprint Sensor in the Spacebar
from Tom's IT Pro
via CERTIVIEW
HP Pro X2 Challenges Microsoft Surface Pro
from Tom's IT Pro
via CERTIVIEW
Monday, 27 February 2017
7 Best Dell Laptops for Business 2017
from Tom's IT Pro
via CERTIVIEW
VMware Certification Guide: Overview And Career Paths
from Tom's IT Pro
via CERTIVIEW
Confessions of an IT Pro: Small Changes Can Make Big Impacts
from Tom's IT Pro
via CERTIVIEW
Friday, 24 February 2017
Best Single Sign-On Solution for Enterprise Businesses
from Tom's IT Pro
via CERTIVIEW
Microsoft Seeks to Address Cloud Skills Gap
from Tom's IT Pro
via CERTIVIEW
How (and Why) to Contribute to PowerShell Gallery
from Tom's IT Pro
via CERTIVIEW
Thursday, 23 February 2017
Too Many Small Businesses Aren't Prepared for a DDoS Attack
from Tom's IT Pro
via CERTIVIEW
Digital Copiers for Business Buying Guide
from Tom's IT Pro
via CERTIVIEW
Wednesday, 22 February 2017
DDoS Attacks: What You Need to Know
from Tom's IT Pro
via CERTIVIEW
Best Business Uses for Amazon's Alexa
from Tom's IT Pro
via CERTIVIEW
Microsoft Customer Support Plans: What You Need to Know
from Tom's IT Pro
via CERTIVIEW
Tuesday, 21 February 2017
Kaspersky Rolls Out a New Secure Operating System
from Tom's IT Pro
via CERTIVIEW
Oracle Certification Guide: Overview And Career Paths
from Tom's IT Pro
via CERTIVIEW
Setting up Visual Studio Code Tasks
from Tom's IT Pro
via CERTIVIEW
Monday, 20 February 2017
Exploring the Abstract Syntax Tree in PowerShell
from Tom's IT Pro
via CERTIVIEW
Sunday, 19 February 2017
How to Reach Devices in Other Domains with IGP Route Redistribution
One size does not always fit all.
At times there’s a need to run more than one routing protocol and have more than one routing domain: multivendor shops, migration from one protocol to another, scalability issues of a single protocol, political or personal preference, production versus test networks, mergers, and acquisitions.
Redistribution is the process of passing routing information from one routing protocol to another to have reachability for devices that live in different routing domains. Each routing protocol will contribute unique information into the routing tables within its domain, but there can be a desire or need to reach devices in another domain. Redistribution is done on one or more boundary routers between a source routing domain or protocol into a target domain or protocol.
There are three options to get full reachability between domains:
- Default routes from a boundary router. You can pass a default route from a router that touches all routing domains (boundary router) to those routers that only participate within one domain (internal router). That would cover unknown routes from any domain that the internal routers are unaware of and have the internal routers forward to the boundary router, which would have a complete routing table since it would be participating in all the routing domains. This process works best if there is only one point of contact between the routing domains.
- One-way redistribution, with a default. One or more boundary routers pass a default route into one domain, but redistribute into another domain. Typically, you would pick a core protocol to redistribute into and the other protocols that get the default route would be looked at as edge protocols. One-way redistribution is used to scale up to larger numbers of routes, such as in a large multinational company. The core protocol could be BGP (Border Gateway Protocol) and the edge protocol(s) could be any IGP (Interior Gateway Protocol), such as OSPF, EIGRP, RIP or IS-IS, or even multiple instances of the same IGP. It works well with acquisitions and mergers, since the “new” part of the company doesn’t have to be running the same routing protocol as the rest, or have to change in the short term. It just adds a connection to the core.
- Two-way or mutual redistribution passes some or all of the routing information of one protocol into another. This is the most complex option, especially if there is more than one point of contact between the routing domains. It should be used when there are destinations that need to be reachable from one domain to another. But specific policy has to be applied to show how the traffic reaches those destinations or how the traffic has to be treated based on security policies. The common concerns with two-way distribution are routing loops, asymmetric routing and suboptimal routing.
a. Asymmetric routing is where the forwarding path is different than the return path. Issues can arise if there’s a security policy in place for how traffic is forwarded or if there are a set of firewalls in place. Load balancers can also be disrupted by asymmetric routing. Load balancers, which distribute load to specific devices based on a shared address, expect the forwarding and return paths to be predictable.
b. Suboptimal routing is where the most preferred path in a forwarding table is not really the most direct route. This happens when the boundary router “hears” about routes from the originating protocol and also through another routing protocol as an external route. If the administrative distance for the external route protocol is more trustworthy than the originating protocol, the router will prefer the external route over the native route. The fix is to manipulate the administrative distance of the routes in question. This is not the most straight-forward process and varies from platform to platform, even within a single vendor’s product line.
c. Routing loops, or a feedback loop, can occur when the routing information is redistributed into one protocol at one point of contact and then redistributed back into the originating protocol at another point of contact. In order to fix a routing loop, you have to create a feedback filter. The filter would deny the routes originating in the target protocol from being advertised back into that same protocol. You have to build the filter for direction. For example, if you have OSPF and EIGRP domains connected at two or more points, you would build one filter for all the OSPF routes and filter them on the redistribution from EIGRP into OSPF. Another filter would be built for all the EIGRP routes, filtering them on the redistribution from OSPF into EIGRP. This filtering has to be done on all boundary routers between the two protocols to be effective. You can match on the prefixes or you can use tags, which is my preference. The tags can be assigned as part of the process of redistributing the routes into the target protocol, then you can look for the tags to filter on. You have to create a policy that first looks for the tags and denies them and if they’re not there, then tags the routes to identify the source protocol. This is done for direction, so two polices would have to be created. All routing protocols, including RIPv2, can support tags.
Let’s look at IGP route redistribution on Cisco devices. When redistributing from one protocol into another, there are a few things to remember:
- The redistribution process pulls from the routing table, not the protocols database. If you are going to redistribute RIP into OSPF, then the process looks for those routes labeled as RIP in the routing table. There is one exception: the connected routes that the protocol is running on.
- On the Cisco routers for IPv4, the connected routes will automatically redistribute as well. This is true as long as you don’t redistribute when connected into that same target protocol, which would cause the feature to stop.
- On the Cisco routers for IPv6, the redistribution process does not redistribute those connected routes that the protocol is running on, unless you add the include-connected option on the redistribution line.
Some Cisco OS requires a policy applied to the redistribution command for routes to be passed from one protocol to another. When redistributing into a protocol, you have to supply metrics for the routes so they’re in the correct format relative to the target protocol. The metric for one protocol doesn’t necessarily look correct for another. There is a seed metric that has to be tied to the external routes going into the target protocol. The table in Figure 1 displays each protocol with some slight variations.
Source | into RIP | into EIGRP | into OSPF | into IS-IS | into BGP (MED) |
Connected | 1 | Interface metric | 20 (E2) | 0 | 0 |
Static | 1 | Interface metric | 20 (E2) | 0 | 0 |
RIP | Infinite | 20 (E2) | 0 | IGP metric | |
EIGRP | Infinite | Other process metric | 20 (E2) | 0 | IGP metric |
OSPF | Infinite | Infinite | 0 | IGP metric | |
IS-IS | Infinite | Infinite | 20 (E2) | IGP metric | |
BGP | Infinite | Infinite | 1 (E2) | 0 |
Figure 1: Protocol Variations
If the seed metric is infinite, the route is not useable. You have to supply the seed metric when redistributing the source protocol into the target either on the redistribution line or through the default metric command under the target routing protocol. The seed metric is in the format for that target protocol: hops for RIP, cost for OSPF and IS-IS, and the composite metric for EIGRP (bandwidth, delay, reliability, load and MTU).
One last consideration—if the source is BGP, then only the external BGP routes will be redistributed into the IGP. This is a loop prevention mechanism. If you need to redistribute the internal BGP routes, then configure under the BGP process (not the target protocol) bgp redistribute-internal command.
So, if you’re running more than one routing protocol and you need full or partial reachability, you’ll have to redistribute between those protocols. There are a few things to consider and plan for before you start configuring. Redistribution can be very simple (one pair of protocols, one point of contact) and can be very complex.
Related Courses
ROUTE – Implementing Cisco IP Routing v2.0
CIERS1 – Cisco Expert-Level Training for CCIE Routing and Switching v5.0
SPROUTE – Deploying Cisco Service Provider Network Routing
from
CERTIVIEW
Friday, 17 February 2017
Facebook Challenges LinkedIn With Jobs Page
from Tom's IT Pro
via CERTIVIEW
Thursday, 16 February 2017
How To Become A White Hat Hacker
from Tom's IT Pro
via CERTIVIEW
How to Use a Security Key to Lock Down Facebook
from Tom's IT Pro
via CERTIVIEW
Networking Reimagined with SDN and NFV
from Tom's IT Pro
via CERTIVIEW
Wednesday, 15 February 2017
Windows 8.1 for IT Pros
from Tom's IT Pro
via CERTIVIEW
Best Business Continuity And Disaster Recovery Certifications For 2017
from Tom's IT Pro
via CERTIVIEW
Red Hat Certification Guide: Overview and Career Paths
from Tom's IT Pro
via CERTIVIEW
Use PowerShell to Make WSUS Suck Less
from Tom's IT Pro
via CERTIVIEW
Tuesday, 14 February 2017
Outlook Premium Comes Out of Preview
from Tom's IT Pro
via CERTIVIEW
Amazon Chime Challenges Skype for Business
from Tom's IT Pro
via CERTIVIEW
Edge vs. Chrome vs. Firefox: Windows 10 Browser Battle
from Tom's IT Pro
via CERTIVIEW
Monday, 13 February 2017
That Old PC with a DVD Drive Might Earn You $10
from Tom's IT Pro
via CERTIVIEW
CompTIA and PrepareU Team Up on Soft Skills Training
from Tom's IT Pro
via CERTIVIEW
Best Podcasts for IT Pros
from Tom's IT Pro
via CERTIVIEW
Sunday, 12 February 2017
A Simple Formula to Keep Projects on Time
For many years, science has proven that we can only do one thing at a time. More specifically, we can attend to only one cognitive task and process only one mental activity at a time: we can either talk or read but not do both at the same time. We can only have one thought at a time, and the more we force ourselves to switch from one thing to another, the more we tax our mental faculties.
In 2001, Joshua Rubinstein, Ph.D., Jeffrey Evans, Ph.D., and David Meyer, Ph.D., conducted and published four experiments in which young adults switched between different tasks, such as solving math problems or classifying geometric objects. The findings for all tasks revealed:
- The participants lost time when they had to switch from one task to another.
- As tasks became more complex, the participants performing them lost more time.
- As a result, people took significantly longer to switch between increasingly complex tasks.
- Time costs were greater when the participants switched to tasks that were relatively unfamiliar.
It is important to pull ourselves away from work now and then; in fact, I teach my students a rhythm of 25 minutes to task, followed by a five-minute break, followed by another 25 minutes (repeat until the task is complete). Breaks are one thing, but distractions are another. Breaks are short, focused and deliberate. Distractions catch us off guard and derail our task entirely.
Meyer has said that even brief mental blocks created by shifting between tasks can cost as much as 40 percent of someone’s productive time. It seems unlikely that we will be able to refocus company culture to accept the virtues of scheduling and completing one task before starting another.
If this behavior is inevitable and unpredictable, what can we do to keep our projects on time? Perhaps the answer is a single point estimate using the resources’ availability and productivity.
Single Point Resource Availability and Productivity Technique
Estimating time in projects is typically done using a single point estimate derived from experience and best guess. At best, a single point estimate gives us a 50 percent probability of success. We can increase those odds a few percentages by accounting for both the availability of a resource and their average productivity, which we have learned through studies is between 72 to 74 percent. I will use a constant of 70 percent for simplicity.
In Equation 1 that follows, d represents duration, e represents the amount of effort needed to complete the task, a represents the resource’s availability and p represents the average productivity of a typical knowledge worker. Equation 2 solves for d.
Equation 1. Single Point Estimate Using Availability and Productivity
Example
Equation 2. Single Point Estimate Using Availability and Productivity Example
Strengths of this technique
This technique is helpful when the hours given come with high confidence and the work is fairly routine and easy to calculate.
Weaknesses of this technique
We all know how difficult it is for most people to articulate, with any predictability, the accuracy of their timelines. Multitasking, or task-switching, is rampant in our fast-paced culture. Since this work ethic is not likely to change, we must use probabilistic math.
There are many ways to estimate time and some are more accurate than others. All come with uncertainty. We have a tendency to base our project estimates on the best guess, which makes it difficult to plan for the inherent randomness in these estimates. At best, a single point quote would only give us a 50 percent likelihood of success. We may increase those odds by looking at a best and worst estimate, plus the resource’s general availability and productivity.
You can learn about other project time estimation techniques in my white paper, A Toolkit for Project Time Estimation.
from
CERTIVIEW
Friday, 10 February 2017
Best Online Fax Services 2017
from Tom's IT Pro
via CERTIVIEW
Best Tablets for Business 2017
from Tom's IT Pro
via CERTIVIEW
RF Alert: Mesh Networking FAQ
from Tom's IT Pro
via CERTIVIEW
Thursday, 9 February 2017
Best Windows 10 Apps for IT Pros 2017
from Tom's IT Pro
via CERTIVIEW
Make the Business Case for Remote Access Software
from Tom's IT Pro
via CERTIVIEW
Wednesday, 8 February 2017
Best Chromebooks for Business 2017
from Tom's IT Pro
via CERTIVIEW
FIDO Authentication: Why You Should Care
from Tom's IT Pro
via CERTIVIEW
Tuesday, 7 February 2017
Lenovo's ThinkPad P71 Built for VR Content Development
from Tom's IT Pro
via CERTIVIEW
Know Your Options Before Selecting a Routing Protocol
Routers and switches make up the bulk of the network infrastructure and are vulnerable to attack. In a previous article, I talked about some of the different ways of hardening your network devices. In this blog, I’d like to specifically examine the routing protocols used on the major Cisco network operating systems.
All the routing protocols have the option to authenticate the neighbors (other routers) and the routing updates that are being received. Except for Open Shortest Path First version 3 (OSPFv3), all routing protocols have built-in methods to authenticate their peers to confirm the updates are coming from a trusted source. OSPFv3 uses IPv6 native IPsec support to authenticate and/or encrypt the OSPFv3 packets and, therefore, has the strongest security options of any of the routing protocols.
Depending on the version of code and protocol, there are various options for authentication of the routing protocols.
With Routing Information Protocol version 2 (RIPv2), OSPFv2 and Intermediate System to Intermediate System (IS-IS), clear text passwords are still an option even though they should never be used since they can be easily seen using a protocol analyzer capturing the traffic between devices. Message Digest 5 (MD5) hashing algorithm is available for all the routing protocols, but is considered to be broken. Still, it remains a better option than clear text passwords and uses 128 bits for authentication.
For Enhanced Interior Gateway Protocol (EIGRP) and Border Gateway Protocol (BGP), MD5 had been the only option for authentication until recently. Secure Hashing Algorithm (SHA) is better if available in your release of code. SHA is a family of different hashing algorithms: SHA-0 with a 160-bit hash algorithm is better than MD5, but is considered to be broken. SHA-1, also a 160-bit hash algorithm, fixes some of the issues of SHA-0, but has some of its own issues. SHA-2, which includes SHA224, SHA256, SHA512, SHA512/224 and SHA512/256, is currently considered secure. There are SHA-3 specifications, which use the same hash lengths as SHA-2, but with different internal operations. A version of SHA is available for BGP, EIGRP and OSPFv2, depending on code and licensing.
Let’s take a closer look at these protocols:
Routing Information Protocol (RIP)
Cisco implementation of RIPv2 supports two modes of authentication: clear text authentication and Message Digest 5 (MD5) authentication. Clear text authentication is the default when authentication is enabled. Note: RIP version 1 (RIPv1) does not support authentication.
RIPv2 uses a key chain, defined in the global configuration, to set the key string. Key chains are a generic set of keys that can be used with multiple processes on the Cisco router, including RIP, EIGRP, ISIS, OSPFv2, HSRP and others.
With the introduction of the cryptography algorithm as an option in the key chain’s configuration, you need to make sure the key chain is compatible with the protocol or feature that it’s referencing. RIPv2 doesn’t support this option within the key chain that it’s referencing. The configuration for MD5 requires the mode to be set at the interface level for IOS and IOS-XE.
With IOS-XR, the reference to the key chain and the mode of authentication are done on the same configuration line. With NX-OS (Nexus switches), the mode and reference to the key chain are on separate interface configuration lines.
ISO/IOS-XE
Key chain MyKey Key 1 Key-string C1sc0 ! Interface fastethernet0/1 ip rip authentication mode md5 ip rip authentication key-chain MyKey
IOS-XR
key chain MyKey accept-tolerance infinite key 1 key-string C1sc0 send-lifetime 1:00:00 january 1 2017 infinite accept-lifetime 1:00:00 january 1 2017 infinite ! router rip interface Gi0/0/0/1 authentication keychain MyKey mode md5 ! ! ! Note that IOS-XR requires a lifetime configured for the key to be valid
NX-OS
Key chain MyKey Key 1 Key-string C1sc0 ! Interface ethernet1/1 ip rip authentication mode md5 ip rip authentication key-chain MyKey
Open Shortest Path First version 2 (OSPFv2)
OSPFv2 has supported clear text and MD5 authentication for a long time, but HMAC-SHA is an option with the introduction of RFC 5709. Starting with IOS 15.4T, Cisco now supports SHA for authenticating OSPFv2. Prior to 15.4T, the key had to be configured on the interface. Now it can be configured within a key chain. As of the writing of this blog, IOS-XR and NX-OS don’t support SHA for authentication for OSPFv2.
IOS/IOS-XE
interface fastethernet0/1 ip ospf message-digest-key 1 md5 cisco ! router ospf 1 area 0 authentication message-digest ! or interface fastethernet0/1 ip ospf message-digest-key 1 md5 cisco ip ospf authentication message-digest
SHA:
key chain MyKey key 1 key-string C1sc0 cryptographic-algorithm hmac-sha-256 ! interface fastethernet0/1 ip ospf authentication key-chain MyKey
IOS-XR
key chain MyKey accept-tolerance infinite key 1 key-string C1sc0 send-lifetime 1:00:00 january 1 2017 infinite accept-lifetime 1:00:00 january 1 2017 infinite ! router ospf 1 area 0 interface Gi0/0/0/1 authentication keychain MyKey mode md5 !
NX-OS
interface ethernet1/1 ip ospf message-digest-key 1 md5 C1sc0 ip ospf authentication message-digest or key chain MyKey key 1 key-string C1sc0 ! interface ethernet1/1 ip ospf authentication key-chain MyKey ip ospf authentication message-digest
Open Shortest Path First version 3 (OSPFv3)
Unlike the other routing protocols, OSPFv3 takes advantage of IPv6 that it’s riding upon. Security is considered to be native to IPv6’s protocol, so rather than reinventing the wheel, OSPFv3 can use it. You can define authentication and/or encryption for the OSPFv3 packets. NX-OS doesn’t presently support authentication for OSPFv3.
IOS/IOS-XE
interface fastethernet1/0 ipv6 enable ipv6 ospf 1 area 0 ipv6 ospf authentication ipsec spi 500 sha1 C1sc0123456789 or ipv6 router ospf 1 area 0 authentication ipsec spi 1000 sha1 C1sc0123456789
IOX-XR
router ospfv3 1 area 0 interface gigabitethernet0/0/0/1 authentication ipsec spi 1000 sha1 C1sc012345678
Intermediate System Intermediate System (IS-IS)
IS-IS can authenticate at the interface, area or domain level. Prior to RFC 3567, IS-IS only supported clear text authentication. RFC 3567 added the support for MD5 authentication. RFC 5310, “IS-IS Generic Crypto Authentication,” introduces SHA as an authentication algorithm for IS-IS. No version of Cisco network operating systems supports SHA for IS-IS authentication.
On ISO-XR platforms, there are two types of authentication: link state packets and hellos. IS-IS supports using a key chain to define the key string or the string can be applied directly to the authentication command. With Nexus, the key string must be defined within a key chain—you cannot define it directly on the authentication command.
IOS/IOS-XE
interface fastethernet1/0 ip router isis isis password C1sc0 or key chain MyKey key 1 key-string C1sc0 ! interface fastethernet0/1 ip router isis isis authentication mode md5 isis authentication key-chain MyKey or router isis authentication mode md5 authentication key-chain MyKey
IOS-XR
router isis 1 lsp-password hmac-md5 clear C1sc0 interface giabitethernet0/0/0/1 hello-password hmac-md5 clear C1sc0 or key chain MyKey accept-tolerance infinite key 1 key-string C1sc0 cryptographic-algorithm hmac-md5 send-lifetime 1:00:00 january 1 2017 infinite accept-lifetime 1:00:00 january 1 2017 infinite ! router isis 1 lsp-password keychain MyKey interface giabitethernet0/0/0/1 hello-password keychain MyKey !
NX-OS
key chain MyKey key 1 key-string C1sc0 ! interface ethernet1/1 isis authentication-type md5 level-2 isis authentication key-chain MyKey level-2 or router isis authentication-type md5 level-2 authentication key-chain MyKey level-2
Enhanced Interior Gateway Protocol (EIGRP)
EIGRP has been a Cisco protocol since 1993, replacing Cisco’s previous protocol IGRP. In 2013, Cisco released a draft request for comment (RFC) for EIGRP, which has since been published in 2016 (RFC 7868). Per the RFC, EIGRP supports authentication types MD5 and SHA. Currently, IOS-XR and NX-OS only support MD5 authentication for EIGRP.
IOS/IOS-XE
key chain MyKey key 1 key-string C1sc0 ! interface fastethernet0/1 ip authentication mode eigrp 35 md5 ip authentication key-chain eigrp 35 MyKey
SHA:
router eigrp Fred address-family ipv4 autonomous-system 35 af-interface fastethernet 0/1 authentication mode hmac-sha-256 0 C1sc0
key chain MyKey key 1 key-string C1sc0 ! interface fastethernet0/1 ipv6 authentication mode eigrp 35 md5 ipv6 authentication key-chain eigrp 35 MyKey
SHA:
router eigrp Fred address-family ipv4 autonomous-system 35 af-interface fastethernet 0/1 authentication mode hmac-sha-256 0 C1sc0
IOS-XR
key chain MyKey accept-tolerance infinite key 1 key-string C1sc0 send-lifetime 1:00:00 january 1 2017 infinite accept-lifetime 1:00:00 january 1 2017 infinite ! router eigrp 35 address-family ipv4 interface gigabitethernet0/0/0/1 authentication keychain MyKey address-family ipv6 interface gigabitethernet0/0/0/1 authentication keychain MyKey
NX-OS
key chain MyKey key 1 key-string C1sc0 ! interface ethernet1/1 ip authentication mode eigrp 35 md5 ip authentication key-chain eigrp 35 MyKey
key chain MyKey key 1 key-string C1sc0 ! interface ethernet1/1 ipv6 authentication mode eigrp 35 md5 ipv6 authentication key-chain eigrp 35 MyKey
Border Gateway Protocol (BGP)
BGP is a complicated protocol—it has to be. BGP is the only routing protocol able to scale to advertising the hundreds of thousands of routes found on the internet today. BGP is also used to support other applications and protocols such as layer 2 and layer 3 VPNs within an MPLS network. In the public internet, there are individuals that want to be disruptive, hold others hostage or redirect traffic for the purpose of theft. BGP offers authentication, as well as other security options. IOS-XR is the only Cisco network operating system capable of SHA authentication. All the others only use MD5.
If security of your BGP relationships and updates are a significant concern, you can always use an IPsec tunnel to peer the neighbors through. Depending on the crypto capability of your release of code, you could see a significant increase in security even though you’re not using the protocol’s built-in authentication. Let’s look at what’s available in the protocol itself:
IOS/IOS-XE
router bgp 65001 neighbor 192.168.5.1 password C1sc0
IOS-XR
router bgp 65001 neighbor 192.168.5.1 password clear C1sc0
SHA:
key chain MyKey accept-tolerance infinite key 1 key-string C1sc0 cryptographic-algorithm hmac-md5 send-lifetime 1:00:00 january 1 2017 infinite accept-lifetime 1:00:00 january 1 2017 infinite ! router bgp 65001 neighbor 192.168.5.1 keychain MyKey !
NX-OS
router bgp 65001 neighbor 192.168.5.1 remote-as 65002 password 0 C1sc0
It’s clear there are varying degrees of consistency between the Cisco network operating systems when it comes down to authenticating the routing protocols. I’ve examined the options of one router vendor. Consider the additional complexities of a multi-vendor shop with multiple router manufacturers, each with their own way of doing things.
The bottom line is we have to protect our network infrastructure. No matter which routing protocol you use, there are options for how to authenticate the neighbor to ensure the updates are coming from a trusted source. Use the strongest common authentication hashing algorithm you can find. Network technologies evolve, vendors evolve and options evolve, so reexamine periodically what is available and upgrade whenever you have the opportunity.
Related Courses
ICND1 v3.0 – Interconnecting Cisco Networking Devices, Part 1
CCNAX v3.0 – CCNA Routing and Switching Boot Camp
ROUTE – Implementing Cisco IP Routing v2.0
TSHOOT – Troubleshooting and Maintaining Cisco IP Networks v2.0
BGP – Configuring BGP on Cisco Routers v4.0
ARCH – Designing Cisco Network Service Architectures v3.0
MPLS – Implementing Cisco MPLS v3.0
from
CERTIVIEW
Why You Should Care About IEEE 802.11ax
from Tom's IT Pro
via CERTIVIEW
Monday, 6 February 2017
Best Hacking Games for Android and iOS
from Tom's IT Pro
via CERTIVIEW