Wednesday, 8 March 2017
Can You Run A Business via a Smartphone?
from Tom's IT Pro
via CERTIVIEW
Firefox 52 is the Last for Windows XP
from Tom's IT Pro
via CERTIVIEW
Justify Your Investment in Video Conferencing Software
from Tom's IT Pro
via CERTIVIEW
How to Create Your First Chocolatey NuGet Package
from Tom's IT Pro
via CERTIVIEW
Tuesday, 7 March 2017
ITIL Certification Guide: Overview And Career Paths
from Tom's IT Pro
via CERTIVIEW
Best Technologies That Enable Digital Handoffs
from Tom's IT Pro
via CERTIVIEW
Monday, 6 March 2017
Are Subscription-Based IT Training Plans Worth The Money?
from Tom's IT Pro
via CERTIVIEW
Report: PowerShell Trojan Uses DNS Queries
from Tom's IT Pro
via CERTIVIEW
Is Your Pay Keeping Pace with the Market?
from Tom's IT Pro
via CERTIVIEW
Business Guide to Cloud Backup
from Tom's IT Pro
via CERTIVIEW
Sunday, 5 March 2017
Docker Launches Enterprise Edition
from Tom's IT Pro
via CERTIVIEW
Friday, 3 March 2017
How ITIL Differentiates Problems and Incidents
Students in ITIL® Foundation classes often find it challenging to differentiate between incidents and problems. To address this issue and offer clarification, this blog will identify the differences between incidents and problems, how they are related, and why it matters.
What is an Incident?
According to ITIL, an incident is an unplanned interruption to a service or a degradation in the quality of a service. What often determines the classification of something as an incident is whether or not the service level agreement (SLA) was breached. However, ITIL allows for raising an incident even before an SLA has been breached in order to limit or prevent impact.
In layman’s terms, an incident is the representation of an outage.
What is a Problem?
According to ITIL, a problem is the root cause of one or more incidents. Problems can be raised in response to one or more incidents, or they can be raised without the existence of a corresponding incident.
In layman’s terms, a problem is the representation of the cause or potential cause or one or more outages.
What is the Relationship Between Incidents and Problems?
Generally speaking, the relationship between the two is that one problem is the cause of one or more incidents. However, it is possible to have an incident (or group of incidents) that is caused by more than one problem.
Why Does ITIL Distinguish Between Incidents and Problems?
The point of distinguishing between incidents and problems is the same as separating cause and effect. Problems are the cause, and incidents are the effect.
ITIL encourages organizations to distinguish between these things because the two are often treated and resolved differently. Addressing an incident simply means that whatever service was impacted has been temporarily restored. It does not mean that the incident will not recur at some time in the future. When I say “temporarily,” keep in mind that could mean one minute or 10 years. The point is that a resolution to an incident is not permanent.
Problems, however, are the cause of incidents. We might use different techniques to identify the root cause of a problem and ultimately resolve that problem. When a resolution occurs, change management is invoked because addressing root causes often entails some amount of risk.
Effective incident management ensures that as a service provider you are able to keep the promises you made in your SLAs by providing a mechanism to quickly restore service when it’s necessary. Problem management ensures that as a service provider you are able to reactively respond to incidents so that they don’t recur and proactively prevent incidents from happening.
These are separate processes because they often require different skill sets and activities. Incident management wants to quickly restore service in line with any SLAs that are in place whereas problem management wants to eliminate the root causes of incidents. Sometimes to properly address a problem, a service provider must cause or extend an existing outage.
Our Solution
Students apply problem management process and techniques based on their specific workplace experiences in our Mastering Problem Management course. This non-certification, exercise-driven learning approach gives learners the tools they need for real world ITIL application.
from
CERTIVIEW
Business Phone Services: Best Picks and Buying Guide 2017
from Tom's IT Pro
via CERTIVIEW
How To Create a Custom DSC Resource
from Tom's IT Pro
via CERTIVIEW
Thursday, 2 March 2017
How to Troubleshoot Cisco’s Dynamic Multipoint VPN (DMVPN)
Dynamic Multipoint Virtual Private Network (DMVPN) is a network solution for those that have many sites that need access to either a hub site or to each other. It was designed by Cisco to help reduce the complexities in configuring and supporting a full mesh of VPNs between sites. There are other vendors that now support DMVPN, but Cisco is where it started.
Benefits of using DMVPN
The dynamic component of DMVPN is that a portion of the VPNs may not have to be pre-configured on all end points of the VPNs. DMVPN allows for the possibility of dynamic spoke-to-spoke communication, once the spokes have made contact with the hub or hubs.
It was intended to be used in a hub-and-spoke configuration (with the possibility of redundant hubs). DMVPN is based on RFC-based solutions: Generic Routing Encapsulation (GRE RFC 1701), Next Hop Resolution Protocol (NHRP RFC 2332) and Internet Protocol Security (IPSec, there are multiple RFCs and standards).
The main idea is to reduce the configuration on the hub(s) router and push some of the burden onto the spoke routers. Using the NHRP to register the spokes to the hub, the spoke can then use the hub as a resolution server to be able to build dynamic tunnels to other spokes.
What if it doesn’t work?
There are several moving parts here to look at: base configuration of the tunnel interfaces (and the basic connectivity), the registration of the spokes to the hub(s), and IPSec.
First off, the tunnel interfaces have to be configured with a source interface or address to create the tunnel, known as the public address relative to DMVPN. The addressing can be either IPv4 or IPv6, but the addressing for the source of the tunnel interfaces must be reachable by the other routers. Whether it’s spoke to hub or hub to spoke, using a ping or traceroute is the best way to verify connectivity.
The configuration may require IPSec, but try the tunnels without it. Ping the tunnel interface address, known as the private address. If the tunnels work without IPSec but don’t work with it, jump to troubleshooting IPSec. If the tunnels aren’t able to pass traffic without IPSec, then start looking at the basic configuration of the tunnel and the next hop resolution protocol.
The configuration of the hub is minimal, typically, relative to NHRP; most is done on the spoke routers. Make sure that mapping states are correct—ip(v6) nhrp map “private-address” “public-address.” Also, make sure the next hop server command is pointing to the public address of the hub—ip(v6) nhrp hns “public-address.”
interface Tunnel123 ip address 192.168.123.1 255.255.255.0 ip nhrp map 192.168.123.2 10.1.1.2 ip nhrp map multicast 10.1.1.2 ip nhrp network-id 1 ip nhrp nhs 192.168.123.2 tunnel source FastEthernet0/0 tunnel mode gre multipoint In this example, the 192.168.123.0/24 address space is the private addressing and 10.1.1.x is the public.
The router will let you misconfigure these commands with the incorrect addresses with no errors. You can use the show ip nhrp nhs detail to check if the spoke-to-server request is successful.
R1#show ip nhrp nhs detail Legend: E=Expecting replies, R=Responding, W=Waiting Tunnel123: 192.168.123.2 RE priority = 0 cluster = 0 req-sent 2 req-failed 0 repl-recv 2 (00:03:13 ago)
On the next hop server, you can verify that the registration was successful with the show ip nhrp command.
R2#show ip nhrp 192.168.123.1/32 via 192.168.123.1 Tunnel123 created 00:04:30, expire 01:55:29 Type: dynamic, Flags: unique registered NBMA address: 10.1.1.1 192.168.123.3/32 via 192.168.123.3 Tunnel123 created 00:04:30, expire 01:55:29 Type: dynamic, Flags: unique registered NBMA address: 10.1.1.3
If the intent is to allow the spoke to dynamically form tunnels, but they aren’t formed, check to ensure the shortcut forwarding is enabled on the spokes in question. The interface command ip nhrp shortcut is needed to enable this shortcut forwarding. Try doing a traceroute from one spoke to another and see if the hub shows up as an intermediate hop. If so, then shortcut forwarding is not enabled.
Another consideration with DMVPN is the registration process. This process is initiated by the spokes, not the hub. If the hub router reloads or if the tunnel interface goes down and comes back up, you may have to shut down or “no shutdown” the spoke routers interfaces. This issue has been resolved in 15.2 code and anything more recent.
If communication works without IPSec, but doesn’t with IPSec configured, it’s time to troubleshoot the IPSec configuration. The policies for phase 1 (key exchange) and phase 2 (transformation of the data) have to be the same between the hub router(s) and spokes. There can be different policies for specific spokes, but that would require different tunnel interfaces. Check the key exchange by using the show crypto isakmp policy command on the routers in question.
R1#sh crypto isakmp policy Global IKE policy Protection suite of priority 10 encryption algorithm: Three key triple DES hash algorithm: Secure Hash Standard 2 (256 bit) authentication method: Pre-Shared Key Diffie-Hellman group: #2 (1024 bit) lifetime: 86400 seconds, no volume limit
To verify that phase 1 is successful, use the show crypto isakmp sa command.
R1#sh crypto isakmp sa detail Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal T - cTCP encapsulation, X - IKE Extended Authentication psk - Preshared key, rsig - RSA signature renc - RSA encryption IPv4 Crypto ISAKMP SA C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. 1002 10.1.1.1 10.1.1.3 ACTIVE 3des sha256 psk 2 23:58:43 Engine-id:Conn-id = SW:2 1001 10.1.1.1 10.1.1.2 ACTIVE 3des sha256 psk 2 23:58:42 Engine-id:Conn-id = SW:1 IPv6 Crypto ISAKMP SA
If it looks like phase 1, check that the transform sets are consistent by comparing the output of the show crypto ipsec transform-set command on the hub and spoke routers.
R1#show crypto ipsec transform-set Transform set default: { esp-aes esp-sha-hmac } will negotiate = { Transport, }, Transform set MyTS: { ah-sha256-hmac } will negotiate = { Tunnel, }, { esp-3des } will negotiate = { Tunnel, },
To verify that the IPSec negotiation was successful, use the show crypto ipsec sa command. This can show you the packets that are being sent and whether they’re encrypted or not.
R1#sh crypto ipsec sa interface: Tunnel123 Crypto map tag: Tunnel123-head-0, local addr 10.1.1.1 protected vrf: (none) local ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0) current_peer 10.1.1.2 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 55, #pkts encrypt: 55, #pkts digest: 55 #pkts decaps: 54, #pkts decrypt: 54, #pkts verify: 54 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.2 path mtu 1500, ip mtu 1500, ip mtu idb (none) current outbound spi: 0x51F10868(1374750824) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x59A9D043(1504301123) — - output omitted -
For troubleshooting DMVPN issues, the best thing is to break it down to its components—basic connectivity, basic tunnel function and then security.
For more DMVPN troubleshooting options, visit http://ift.tt/2lxo1gR.
Related Courses
CIERS1 – Cisco Expert-Level Training for CCIE Routing and Switching v5.0
CIERS2 – Cisco Expert-Level Training for CCIE Routing and Switching Advanced Workshop 2 v5.0
from
CERTIVIEW
Cloud Office Suites Compared: Microsoft vs. Free
from Tom's IT Pro
via CERTIVIEW
CompTIA Launches New Intermediate-Level Cybersecurity Certification
from Tom's IT Pro
via CERTIVIEW
Wednesday, 1 March 2017
Greatest Risk to Remote Access Software Is Credential Theft
from Tom's IT Pro
via CERTIVIEW
Dropbox Paper: What Is It
from Tom's IT Pro
via CERTIVIEW
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