Troubleshooting network issues,

in this section,

we're going to discuss how to troubleshoot general

networking issues.

As we go through this section of the course,

we're going to again focus on Domain 5 network troubleshooting

and our final objective,

objective 5.5.

Objective 5.5 states,

that given a scenario,

you must troubleshoot general networking issues.

Now, as we go through this section of the course,

we're going to talk about collisions, and broadcast storms,

and duplicate addresses,

and flooding and switching, and routing loops,

DHCP issues, IP misconfigurations,

VLM misconfigurations, firewall issues, DNS issues,

NTP issues, network performance issues,

low optical link budgets,

certificate issues,

licensed feature issues, BYOD challenges,

and some hardware failures.

But before we cover all those different issues

in this section of the course,

I want to use the rest of this lesson

to discuss a few things you need to consider

during your general network troubleshooting efforts,

including device configuration reviews,

routing tables, interface status,

VLAN assignments,

and your network performance baselines.

First, we have device configuration reviews.

Now previously

we've gone through a standard device configuration

and we reviewed it section by section.

But here, I just wanted to remind you

that whenever you're experiencing a networking issue,

it's always a good idea

to look at your configuration files once more.

Most network devices have two configurations,

a startup configuration and a running configuration.

The startup configuration file is stored in NVRAM,

and it contains the commands needed

to initially configure a router

when it's being booted up.

It also creates the running configuration file

that's going to to be stored in RAM

and used during normal operations.

The running configuration

is the configurations that are actively

being used by the router

at any given time.

Any changes made to the configuration

by a network technician

in the command line interface

is applied first to the running configuration.

But,

if it doesn't saved back to the startup configuration,

those changes will be lost

the next time you reboot the router.

So if everything was working and you rebooted the router

and things stop working,

it may be that you're missing a configuration.

Now if you want to see the startup configuration,

you can enter the command, Show startup-config

at the command line interface.

If you want to see the running configuration,

you're going to enter show running-config

at the command line interface.

Now if you need to save any changes

that you've made to the running config,

to the startup config,

you can do this by entering the command;

copy running-config, startup-config

into the command line interface.

Remember

these three commands work on Cisco devices,

but other network devices use similar commands

to conduct these same types of actions.

Now, next, you need to look at your routing tables.

Anytime data isn't flowing properly in your networks,

it could be a routing issue

to verify your routing tables.

You need to check your routers,

your layer three switches

and any workstations or servers you may have

to view the routes on a network device

like a router or a layer three switch.

You can enter the command Show IP route

from the command line interface.

Now, if you need a view, the routing table

on a Windows, workstation or server,

you can use the command Route print at the command prompt.

If you need to display the routing table on a Linux

Unix or OSX workstation or server,

you can enter the command Route-N at the shell.

Next, you should look at the interface status itself

when there's networking issues going on

to do this, you're going to enter the show interface

or show interfaces command

at the prompt within the command line environment

of your router or switch

again, this is a Cisco specific command,

but similar commands exist for other brands

of network devices.

From this interface status,

we're going to be able to determine all sorts of issues,

such as duplexing issues, DHCP issues, collisions,

and broadcast storms.

Next, we can check the VLAN assignments being used

for our network and our devices,

the VLAN assignments or VLAN tagging

is the practice of segmenting an organizational network

and separating users into respective networks Sections

based on their roles and responsibilities.

Most commonly

VLAN assignments are done using static assignments

based on the ports and the interfaces being used.

Conversely,

you can also set up dynamic VLAN assignments

based on a Mac address of a given client.

And that way, when that client connects,

it will be put into the right VLAN,

regardless of which physical port it's being connected to,

to use dynamic VLAN configurations though,

you need to use a VLAN Membership Policy Server or VMPS.

As well as a client server and database.

Now, remember,

If you're using VLANs,

these will be things that will break up

your broadcast domains

and reduce the chance of a broadcast on from occurring.

But because these VLANs break up broadcast domains,

you need to route traffic from one VLAN to another,

using a router or layer three switch.

If you forget to include a router in your network

architecture

and you're using VLANs,

your traffic is not going to be able to flow

between those VLANs.

So make sure you keep this in mind.

Finally,

you need to ensure that you have

a good network performance baseline

created for your network after you initially configure it

in the simplest terms,

a network performance baseline,

it's just a set of metrics used

in network performance monitoring

to define what the normal working conditions

of this enterprise network infrastructure

are going to look like.

Engineers are going to use network performance baselines

for comparison

to catch changes in traffic that could indicate

there's a problem with your network.

It also lets networks operations personnel

like network technicians,

understand the before and after effects.

Whenever a change is made,

this makes it easier to measure the benefit

and calculate a return on investment

when you're making network changes.

Basically,

if you think there's a problem

and something looks abnormal,

you should consult your network baseline

to see if there really is something that's wrong

or something that's been changed.

And how large of a change has caused

on your performance.

Because if you change one thing by adding a route

and your network performance went down by 50%,

you probably don't want to add that route anymore.

And so you need to look into that closer

again there's lots of places and lots of things

that can go wrong in our networks.

So with all these considerations in mind,

let's jump into this section

on troubleshooting network issues.

Collisions and broadcast storms.

In this video, we're going to discuss collisions

and broadcast storms, how to identify them

and how to overcome them.

First, collisions.

A collision occurs on your network

when something happens to the data

as it's sent through the physical network medium

and it's prevented from reaching its final destination.

Now, most of the time, a collision occurs

when two hosts on the network

are transmitting at the same time

and therefore, their signals get combined

on the network medium and become unreadable.

Now, a collision can occur in both wired

and wireless networks.

If you think back to earlier lessons on ethernet,

you learn how CSMA CD worked

or on wireless networks how we use CSMA CA.

You remember that collisions are possible

on both of these types of networks

and we have to figure out a way to get through them.

Now, to prevent collisions,

you need to architect your networks

with smaller collision domains

because this decreases the chance

of a collision happening.

A collision domain is a network segment

connected by a shared medium or through repeaters

where simultaneous data transmissions can collide

with one another.

Now, if we connect all of our devices to a hub,

all of those devices are going to share

a single collision domain.

Similarly, if we're all connected

to the same wireless access point,

we're all going to be treated as being a part

of the same collision domain.

To break apart those collision domains

into smaller collision domains,

we need to use any layer 2 device,

like a switch or a bridge.

Now, when we replace a hub with a switch,

each switch port becomes its own collision domain

and this completely prevents all the collisions

from occurring on that switch port

between the switch and that client device

if you're connecting it directly to it.

So, how can you detect collisions and why are they so bad?

Well, the first indication

that you might have excessive collisions

is when your network performance starts to go bad.

After all, anytime you have collisions

on an ethernet-based network,

the devices are going to pick a random backoff timer

and then they're going to retransmit.

So, if you have a collision,

it never requires two additional transmissions

to get that data sent back out from the sources

to those destinations.

If you have a lot of collisions,

this causes an exponential decline

in the performance of your networks throughput.

Another way you can more accurately determine

if collisions are occurring on your network,

is to run the show interface command on your network device

and then look at the statistics

for the different switch ports.

Let's take a look at a few examples here.

First, let's look at this example

where we can see the collision counter is increasing.

We expect to see zero collisions,

but as the collisions begin to occur,

the interface statistics are going to start climbing upwards.

If you're using hubs in your network,

you're going to have some collisions occur and that's fine.

This only becomes a problem

when you start to have too many collisions

and your network performance starts to deteriorate.

That said, if you're running a switch base network

and you really should be,

then you shouldn't have collisions occurring

and this would be an indication

that something is not working the way you designed it.

Next, we could also see the deferred counter increasing.

Now, the deferred counter is going to count the number of times

the interface has tried to send a frame,

but, they found the carrier busy at the first attempt.

This is called carrier sensing.

Again, if you're running a switch,

you should not see a deferred counter rising

because nobody should be waiting to transmit.

Now, if you're using a hub based network,

this is going to be a normal part of your network operations

and it shouldn't be a concern.

Next, we have late collisions.

Now, this occurs when a collision is detected

after 5.12 microseconds,

which is the amount of time it takes

for the 512 bit of a frame to be sent.

This is displayed under the late collision counter

in the interface statistics.

A late collision by itself indicates a problem,

but not the root cause.

Instead, the cause is usually an incorrect cable being used,

a bad network interface card

or the use of too many hubs on the network.

Finally, we have excess collisions.

Basically, there is a limit to the number of times

the device can back off from transmitting

and wait when it experiences a collision

to retransmit again.

When the collision occurs,

it's going to choose a backoff timer

and then it tries retransmitting again.

If it detects another collision,

it picks a new backoff timer and tries again.

It'll keep doing this for up to 16 times

but on the 16th time,

it's going to give up and simply just drop that frame.

In this case, it's marked by the interface statistic

as an excessive collision.

Now, if you want to display

the exact number of excessive collisions,

you can enter the command show controller ethernet

on your network platform

and the excessive collision counters will be displayed.

If you're experiencing excessive collisions,

this is going to indicate a problem in the network.

Usually, this is caused by devices

using full duplex communication

over a shared ethernet segment, like a hub

or you have a broken network interface card

or you simply have too many clients

connected to the same collision domain.

To overcome an excessive collision issue,

you should turn off auto negotiation

for the speed and duplex of an interface,

hardcode the speed to a lower setting and change the duplex

to half-duplex instead of full-duplex.

These speed and duplex settings can be configured

on the networking device or on the client itself

within the windows, Linux, Unix,

and OS X operating systems

under the network adapter settings.

Next, we need to talk about broadcast storms.

Now a broadcast storm occurs

when the network system is overwhelmed

by continuous multicast or broadcast traffic.

Broadcast storms are dangerous to your network

because they can quickly overwhelm switches

and other devices as they struggle to keep up

with the flood of packets that's trying to get processed.

When a broadcast storm occurs,

your network performance is going to decrease rapidly

and the worst cases

it can cause a complete denial of service in your network.

Remember, a broadcast packet is addressed at both layer 2

and layer 3.

On layer 2 devices,

the address is FF FF FF FF FF FF.

Now, if it's at layer 3,

you're going to see the IP address used of 255.255.255.255.

Now, a broadcast domain is a logical division

of a computer network in which all of your nodes

can reach each other using the broadcast

at the data link layer, which is layer 2.

Now, a broadcast domain

can be within the same locally or network segment

or it can be bridged

to other local area network segments as well.

Remember, a switch and a layer 2 device

will not break up broadcast domains

because they bridge these things together.

Now instead, you have to reach a router

or a layer 3 switch,

to break up the broadcast domain

into smaller broadcast domains.

In general, there's just a couple of main causes

for broadcast storms occurring in your network.

First, you have a singular broadcast domain

that's just way too large.

In this case, the number of clients will simply create

a broadcast storm

when they're conducting their normal operations.

For example, if you have a large enterprise network

that has numerous switches,

that are interconnecting the network,

this is going to create a really large broadcast domain

because again, switches don't break apart broadcast domains

like a router does.

So, if you have a large broadcast domain setup

using class B private address ranges like 172.16.0.0/16,

you could have up to 65,534 usable IP addresses and hosts

on that one broadcast domain

and that's a really large broadcast domain.

Instead, you should break up that broadcast domain

by subnetting out the class B network into smaller networks

to reduce the number of broadcast being generated

by those clients on the network.

Between each subnet, you're then going to use a router

or a layer 3 switch, to break up those subnets

into separate broadcast domains.

Now our second cause of broadcast storms occur,

we have a large volume of DHCP requests

on a given broadcast domain.

Whenever a new host connects to a broadcast domain,

they attempt to get an IP address assignment

using the DORA process

of discover, offer, request and acknowledge

using the DHCP protocol.

Now, the D or discover part of this process

happens as a broadcast packet because the new network client

doesn't know the location of the DHCP server yet.

So, this can create a storm of broadcast packets

if the network has a lot of clients trying to negotiate

for an IP address all at the same time.

For example, let's say your network device reboots

and all the clients attempt to renegotiate

their DHCP leases.

That can cause a broadcast storm.

If you see a broadcast storm

is being caused by your DHCP configurations,

you need to check if you're using DHCP relays

between your different VLANs.

If you are, you're essentially allowing these VLANs

to be treated as a single broadcast domain

for the purposes of DHCP discovery

and this can lead to broadcast storms

if you have a very large network with a lot of clients.

The third cause of broadcast storms occurring on a network

is going to occur when loops are created

inside of a switching environment.

If you happen to have unmanaged switches

and somebody accidentally cables them together,

this can create an unintentional loop

and this can lead to broadcast storms.

To prevent these, make sure you're enabling BPDUs

or Bridge Protocol Data Units on your managed switches.

Also, you should enforce

a maximum number of MAC addresses per port,

because this will also shut down a port

if a broadcast storm starts to go on through that port.

So, how can you identify if you're having a broadcast storm?

Well, one of the easiest methods

is to look at your packet counters.

If you know your normal baseline for your network

and now you see it rapidly increasing way faster

than you normally do,

this could be an indication of a broadcast storm.

For example, let's say you're running a network

that you're used to seeing about 10,000 packets per second

and now, you're seeing

a hundred thousand packets per second.

This could be indicative of a potential broadcast storm.

In this example, you can see our average broadcast

is around 8,700 packets per second

and we rarely go above 20,000 broadcast packets per second.

So, if I see a spike upwards to a hundred thousand packets

or more per second,

I would know I have a potential broadcast storm on my hands.

Now, another way is to look at your network monitoring tools

and determine the packet loss on your network.

If a broadcast storm starts to occur,

your network devices are going to have a hard time

keeping up with the processing

of all the packets on the network.

And so, packet loss will rise exponentially.

Now, the most definitive way

to identify a broadcast storm though,

is to set up a packet analyzer like Wireshark or TCP dump

and then you start collecting the traffic on the network.

As you look at that traffic,

you're going to look for packets

and see if there's a lot of broadcast packets

that are growing rapidly.

If so, you're suffering from a broadcast storm.

In this example, you see a layer 2 broadcast storm occurring

due to an enormous amount of art broadcast

being conducted in this network.

Now, in this example,

I'm using TCP dump to see all the broadcast traffic

on the network.

To do this, you're going to run the command TCP dump-I

and then your interface,

ether, broadcast and ether multicast.

This'll run TCP dump and only display broadcast

and multicast packets to the screen.

In this example,

you can see there are a lot of AARP requests

that are going on because there's a broadcast storm

that's starting to happen.

Remember, the best way to prevent a broadcast storm

is either set up loop preventions like using BPDUs,

limiting the number of Mac addresses

that can access a given switch port

and breaking up large broadcast domains

into smaller broadcast domains

using routers and multi-layer switches.

Duplicate addresses.

In this video, we're going to discuss duplicate addresses

in our network, specifically duplicate MAC addresses

at layer two and duplicate IP addresses at layer three.

First let's focus on layer two with duplicate MAC addresses.

If you remember a MAC address is a 12 digit number

that's written in hexadecimal format,

and it's used to uniquely identify a network interface card

on a given network.

A MAC address has 48 bits in total length for its address.

The first 24 bits, or six hexadecimal digits,

is going to be assigned based on the hardware manufacturer.

And the second 24 bits, or six hexadecimal digits,

are going to be used to uniquely identify

this particular network interface card on the network.

The MAC address is assigned on the device

when it's manufactured initially,

and this is a hardware or burnt in physical address.

For this reason,

you should not have duplicate MAC addresses on your network,

unless there's an incorrect assignment

made during the production by the manufacturer,

or if somebody in your network

begins to use a self assigned address

known as a locally administered address.

Now, when a self assigned address is being used,

this can often be an indication that MAC spoofing

is being used by a client on your network.

So what's wrong with having duplicate MAC addresses

on the network?

Well, when I think of this problem,

I think back to elementary school in the late eighties

and early nineties.

You see when I was born,

the name Jason was pretty darn common.

This made it a little bit difficult for many of my teachers

because they often had two or three kids

in the class named Jason.

So when the teacher would call out Jason,

there was two or three kids who would respond.

Or if the teacher got a note from Jason's mom,

the teacher then had to figure out which Jason

should get the response

because she didn't know which mom it was.

Now, the same thing happens in our networks.

If you have two or more devices

that respond to data requests

directly from a given MAC address,

this causes a lot of network issues.

Now for example, if you have two devices

using the same Mac address,

your switch might mistake them for each other.

And they might think they're the same device,

and so the switch will keep updating its CAM table

for the location of a single device.

So it goes from port one to port three,

to port one to port three

and repeatedly starts going from one port to the other,

when in reality, there's really two devices there.

Now duplicate MAC addresses

can also cause network conductivity issues

because the switch doesn't know where to send the traffic

destined for that particular MAC address.

Because again, it's switching between two

or three different ports.

Now, luckily MAC addresses are only used

in layer two networks.

So once you reach a router in your network,

the address is going to be converted to an IP address

at layer three,

so the extent of your connectivity issues

is really going to be limited in scope.

Now a more modern challenge that we have

is with virtual machines

and their virtual network interface cards,

because these devices are only a series of ones and zeros,

the virtual network interface cards

have to be assigned a MAC address

by a virtual machines hypervisor.

To ensure you don't end up with duplicate MAC addresses

caused by these virtual machines,

you need to make sure you're using a Logical Domain Manager.

Now, a Logical Domain Manager

is used to listen to multicast messages on the network

and keep track of all the MAC addresses that are being used.

As it does this, it identifies if there's any duplicates

and if it is,

then it will go ahead and reassign MAC addresses

for its virtual machines to prevent duplications.

So how can you determine if there's a duplicate MAC address

operating on your network?

First, you're going to see network conductivity issues

for two machines,

and those machines will have duplicate MAC addresses.

This is caused by the switch

that continually has to go back and forth between two ports

and updating its CAM table

because it sees the same MAC address reporting itself

on two different ports.

This will cause intermittent connectivity

for the two devices

or one of the devices will have great connectivity

and the other one will be completely non-responsive.

Second, you could set up a protocol analyzer like Wireshark

on your network.

Then you can look at the network traffic,

specifically the ARP traffic and see what IP addresses

are being mapped and reported for each MAC address.

If you see the same AMC address being used

by two different machines or two different IP addresses,

this could indicate a duplicate MAC address

is on your network.

To prevent issues on your network

caused by duplicate MAC addresses,

you can enable port security on your devices.

This can be configured to allow a single MAC address

to be configured to one single switch port,

and then it's going to prevent any duplicate MAC addresses

from accessing the network at the same time.

Now, to identify switch boards that are used

for particular MAC address,

you can editor the show ARP command on your switch.

Here's an example of running the show ARP command

on a Cisco switch.

Notice there are two matching MAC addresses in use here,

both with different IP addresses

and different physical interface ports.

One is on fast ethernet 0/3/3/4

and the other is on fast ethernet 0/3/3/5.

This can cause conflicts or frames

that simply aren't going to be delivered to the right devices

on this switch.

Now, once you identify the devices

that are using the duplicate MAC addresses,

you can check those devices locally

to see if there's a hardware manufacturing issue

that assigned the same MAC address to both devices,

or, if this is the case in MAC spoofing,

you want to make sure that you reset the MAC address

back to the burned in physical address

or remove that device from the network completely.

If it's a hardware manufacturing issue,

you're going to need to replace the network interface card

to permanently solve this problem.

Next, let's talk about duplicate IP addresses.

A duplicate IP address is also known

as an IP Address Conflict.

This occurs when another computer on the same network

has an identical IP to another workstation or server

on that same network.

Most often this occurs when you're using static IP address

assignments for your network clients

and you didn't properly account for which IPs

were already used by other devices, or you had a typo.

If you're using DHCP in this happens,

this could be a DHCP server issue

where it didn't properly account

for the IPs it already issued out,

or it could be the case of somebody statically assigning

an IP to their client,

even though the DHCP server has that IP address assigned

as part of its scope.

Now, a third reason this can occur

is if you have a rogue DHCP server on your network,

because that rogue DHCP server could be handing out

the same IP addresses as your official DHCP server,

and this can be happening

from a private class C address IP scope.

Now, if you have duplicate IP addresses

being used by two devices on your network,

this'll cause intermittent connectivity

for both of those clients,

because both of those clients

are requesting network services,

but the routers may not know where to send the traffic

back to 'cause both clients are using the same IP address.

To solve this, you should first check if the client

is dynamically or statically assigned an IP address.

As I said, most commonly, devices can be statically assigned

an IP, and you're going to have a duplicate IP address issue

because somebody typed in the wrong thing.

To check this, go to your network adapter properties

for TCP/IP version four in Windows

and you're going to see,

use the following IP address radio buttons there,

and if that's selected,

that means you're statically assigned.

If your network is supposed to use DHCP,

simply click, obtain an IP address automatically instead

and then save your changes,

and the network interface card will go out

to the DHCP server and get the dynamic assignment

for an IP address that it should use moving forward.

If you want to identify the duplicate IP addresses

on your network though,

you can start by logging into the command line interface

on your router.

In my example, I'm going to use a Cisco router

and I'm going to enter the command show ARP,

just like we did when searching for duplicate MAC addresses.

This time though,

we're focused on IP addresses in that first column.

Here, I see two IP addresses displayed with 10.1.4.2.

The first one is located on interface,

fast ethernet 0/3/3/4

and the second one is on the interface

fast ethernet 0/3/3/5.

Now that we know which interfaces and switch ports

are being used,

we can check the configurations on those individual clients

and we can ensure they're properly assigned statically

or they're configured to receive a dynamic IP address

from our network's DHCP server.

Routing Issues.

In this video, we're going to discuss routing issues

that you may come across in your networks,

including multicast flooding,

asymmetrical routing and missing routes.

Now, first we're going to talk about multicast flooding.

If you remember, multicast networks operate

by sending out group communications

that are addressed to a group

of destination computers simultaneously.

For this to work, the multicast message is sent

to a single multicast address

and then the message can be distributed to the entire group.

This is great most of the time,

but sometimes things can malfunction

and a multicast flood can occur.

Now, multicast flooding happens when no specific host

is associated with the multicast MAC address

inside the CAM table of the switch.

When this occurs, multitask traffic is going to be flooded

throughout the entire local area network or VLAN,

creating unnecessary traffic and wasting network resources.

To prevent this issue, you need to configure your switch

to block unknown multicast packets.

Now, for the exam,

you don't need to know the specific commands

on how to block multicast traffic on a switchboard,

but you do need to know that blocking it

will solve this type of multicast flood issue.

Next, we have asymmetrical routing.

Asymmetrical routing occurs

when network packets leave via one path

and then return via a different path.

This can occur when traffic is flowing

across two different layer two bridge pair interfaces

on a router or a firewall

or when there's flows across different routers

or firewalls in a high availability cluster.

Now, if you're using Load Balancing

and using a protocol like HSRP,

asymmetric routing can occur

and it's something you need to think about.

This is a problem if you're using security devices

and network appliances to perform deep packet inspection

or you're using a stateful firewall,

because these devices need to see

all the packets associated with a given packet flow,

otherwise issues happen.

Now, while modern routers will attempt to forward packets

in a consistent next hop for each packet in the flow,

this only applies in one direction

when they do their forwarding.

Our routers will make no attempt in directing return traffic

to the originating router, because they only want to ensure

the fastest and most efficient delivery of those packets.

Now, this behavior presents problems for our firewalls

and our security appliance clusters,

because they don't support asymmetric routing,

because of the set of cluster nodes

all provide a path to the same networks.

So routers forwarding packets to networks

through the cluster can choose any of the cluster nodes

as their next hop.

And this causes asymmetric routing to occur

and the flow of packets in one direction

goes out a different node than what comes back

in the return path.

Because of this difference in packet flow,

network traffic can be dropped by one

or both of the firewalls in the cluster,

because they aren't seeing all the traffic

from the packet flow.

So how do we solve this problem?

Well, the solution to this is to adjust the placement

of your firewalls and internal routing

so that the traffic will flow in both directions

to the same firewall, even if the incoming traffic

is entering the network through a different router

than the router that handled the matching outgoing traffic.

Essentially, we need to put all our firewalls

closer to the systems they are protecting

instead of at the edge of the network

and this will avoid asymmetric routing problems.

Remember, asymmetric routing

doesn't cause any routing issues necessarily,

but they do cause issues with dropped packet flows,

because our security devices like firewalls

and unified threat management systems

need to be able to see the entire flow.

So you need to consider the design

of your network architecture

to prevent this issue from occurring.

If you don't, then packet flow drops are going to occur

and your clients can experience

network intermittent connectivity.

Finally, we need to talk about missing routes.

Now, missing routes occur

when a router cannot reach a destination

because there's a missing route inside the routing table.

These missing routes can occur

for lots of different reasons,

depending on what routing protocol is being used

to share that routing information.

Now, missing routes are commonly found as an issue

when network administrators are using static routes

and manually adding them to the routing tables.

If the administrator mistypes a route or the command,

the proper route will not get added to the routing table

and this causes problems.

So if you suspect you're missing a route,

you should enter the show IP route command

from the command line interface of your switch

and that'll display the routes available to it.

Now, if you're working on a Windows client or server,

you can enter the route print command

to see the routing table for your system.

If you're using dynamic routing protocols like OSPF or BGP,

there may also be issues where the routers

are not properly establishing their neighbor states

and this can cause the routers to not reach convergence

across their routing tables.

To troubleshoot this kind of issue,

you need to verify the dynamic routing protocols enabled

and if the two routers can communicate with each other.

To verify this, you should run the ping command

from one router to the destination router

and validate that connectivity exists.

If you identify that a route is missing,

you can statically add that route from the command line

or you can work with a network administrator

or network engineer

to troubleshoot the underlying dynamic routing protocols

that are being used by these routers.

Loops

in this lesson, we're going to discuss loops,

specifically switching loops and routing loops.

First we have switching loops.

Switching loops, or bridging loops,

are going to occur whenever there's more than one path

between a source and destination device.

As broadcast packets are set for switching

through every single switch port,

flooding can really occur quickly

when broadcast messages are sent

and then repeated back through another switch port

in this looped architecture.

This will create a broadcast storm for you.

Since our modern networks are built

with additional load balancing and fault tolerance,

there's usually going to be multiple physical connections

between each part of the network.

And so naturally, we would have loops

and switching loops would become inevitable

if we didn't put some protections in place to prevent them.

So, how are you going to prevent them?

Well, to prevent a switching loop,

you have to enable STP, the spanning tree protocol.

To check if STP is enabled and configured on your switch,

you need to use the command, show span tree,

and then hit enter.

For the network plus exam, you do not need to know

how to configure a spanning tree protocol on a switch,

but I'm showing you what it looks like

just for demonstration purposes here.

Now you can see here, the information for this switch

in VLAN0001, which is our default VLAN.

In this example, the route ID

is set with a priority of one at a cost of two.

The bridge ID is set with a priority of 61,441.

As we look at the different interfaces on this switch,

you can see there are two ports

that are designated as the root port

that will forward traffic.

And all the other ports are set as designated ports.

Eth1/11, 1/12, 1/15, and 1/16 are all in a blocking state.

And this is what prevents a loop from occurring

with this switch.

Now the bottom line here, when it comes to switching loops,

is that if you suspect a switching loop,

it's likely an issue with how you configure your STP

and you need to escalate this work

to a network administrator or network engineer

to troubleshoot it, reconfigure it and repair it.

Next, let's talk about routing loops.

A routing loop is formed when an error occurs

in the operation of your routing algorithm.

And this creates a circular route

amongst a group of network devices.

Routing loops are caused by incorrect configurations

of your routing protocols,

where data packets get sent

between different hosts of different networks.

And they get caught in this endless loop,

traveling in a circle between the different network routers

with incorrect route entries.

Routing loops, unlike switching loops

are not caused by physical circular connections,

but instead by the logical layer 3 circular connections

that can exist within your routing tables.

Remember, we want multiple physical connections

between our routers,

because this gives us higher redundancy and fault tolerance.

So our routing protocols have methods in place to protect us

from physical loops causing issues.

Things like weighted connections based on hops

or the speed of those connections.

For example, distance vector routing protocols,

use a Time to Live, or TTL, in the data gram header

of the IP packets.

And this will help us avoid routing loops.

So, if a packet reaches the Time to Live of zero,

it's going to be dropped by the router

and it's not going to be forwarded.

And that effectively ends your routing loop.

Now, another method to prevent routing loops

is known as split-horizon.

If you can figure split-horizon, you're going to ensure

that you have this router configuration

that stops a route from being advertised back

in the direction that it came from.

This split-horizon mechanism ensures that a router

can not send back alert route to the same router

that it learned it from.

To setup split-horizon on a Cisco router, for example,

you're simply going to enter the command ip split-horizon

and hit enter at the command line interface.

If you believe split-horizon has been disabled by accident,

you can look to see if the no ip split-horizon command

was previously issued.

Now, route poisoning is another method we can use

to avoid routing loops inside of our networks.

If a router detects that one of its connected routes

has failed, the router is going to poison

that route by increasing its metric

to an infinitely high number.

This happens automatically inside your routers.

So there really isn't something you have to do or configure,

it'll just happen for you.

Finally, we have hold-down timers.

Hold-down timers are used to prevent bad routes

from being restored and passed

to other routers by accident.

Now hold-down timers are used

with distant vector routing protocols like RIP.

The router is going to be configured,

so that will not advertise or accept any routes

that are in a hold-down state.

This occurs for a set period known as the hold-down period.

By default, the hold-down timer is set at 180 seconds

or three minutes when you're using RIP

as your routing protocol.

It should be configured that way,

automatically, by your router.

As I said, most of the routing loop issues

can be solved by simply using the right routing protocols,

ensuring they're configured properly.

If you're adding a bunch of static routes into your router,

be really careful because this is how most routing loops

are going to be created.

Remember, statically-created routes are given a metric

of 1 by default, making it extremely, highly trusted

by the router.

The only type of route that the router will trust more

than your statically assigned route

is a directly connected route.

Any routes that it learns through OSPF or RIP or BGP

or EIGRP or any other routing protocol

will not overwrite that static route that you created.

So you have to be careful with static routes

in order to prevent a potential routing loop.

DHCP Issues.

In this video, we're going to discuss DHCP issues,

such as rogue DHCP servers and DHCP scope exhaustion.

Now, DHCP, or the Dynamic Host Configuration Protocol,

is a network management protocol

that's used on IP networks for automatically assigning

IP addresses and other communication parameters

to devices that are connected to the network

using a client server architecture.

Basically, DHCP is used to automatically assign

an IP address, a subnet mask, a default gateway,

and a DNS server's IP address

to a client whenever it joins the network.

This works great most of the time,

but if someone adds a rogue DHCP server to your network,

this can cause a ton of issues for you.

Now, a rogue DHCP server is a DHCP server on the network

that is not under your administrative control,

since you are the network administrator.

Remember, rogue DHCP servers can be installed on a network

either as part of a malicious attack

or simply accidentally by your own employees.

In the case of a malicious attack,

the rogue DHCP server could be used

to automatically configure network clients

as they join the network to use a different DHCP server,

one that's controlled by your attacker.

That way, anytime somebody enters google.com

or citibank.com, they're going to be redirected to another site

that's controlled by the attacker

and looks like those sites,

and then, they can conduct an on-path

or man in the middle attack against them.

Now, in the case of an accidental install by an employee,

this normally occurs when somebody connects

a wireless router or wireless gateway to your network

for their own convenience

and they really didn't realize that the device

had a built-in DHCP server contained within it.

In either case, the rogue DHCP server

will begin to hand out IP addresses from its own scope.

Now, this scope may or may not be the same

as your official DHCP servers.

If it isn't, you're not going to see

a lot of network connectivity issues for those clients

that are getting IPS from the rogue DHCP server

if the default gateway is still being handed out correctly.

Now, if the rogue DHCP server is using

the same scope as your DHCP server,

this is where you can have a lot of problems.

For example, let's pretend you're both using

192.168.1.0/24 as your network scope.

This is a traditional one used by small office

and home office networks.

You both then can start to suffer connectivity issues

because two devices can both be assigned

the exact same IP address,

leading to a duplicate IP address.

Now, to prevent a rogue DHCP server

from connecting to your network,

you should configure DHCP snooping on your network.

DHCP snooping is a series of techniques

that are applied to improve the security

of DHCP's infrastructure

by excluding rogue DHCP server traffic

and removing their malicious or malformed DHCP traffic

from the network.

Now, rogue DHCP servers can also be countered

by using port security on your switch ports,

because that rogue DHCP's MAC address

isn't going to be on your authorized list of devices

when they connect to a switch port.

Finally, rogue DHCP servers can also be detected

by properly configuring an intrusion detection system

and once identified, it can be manually removed

from the network by your network administrators.

Next, we have have DHCP scope exhaustion.

Now, DHCP scope exhaustion occurs

when the DHCP server simply runs out of valid IPs

to assign to somebody when they join the network.

For example, let's say again you're using the scope

of 191.168.1.0/24

and that's your private Class C network.

You've reserved 192.168.1.1 for the gateway

and 192.168.1.255 for your broadcast.

Now you have 254 IPs left in your DHCP scope.

Now, as long as you have less than 254 devices

that want to connect you at the same time,

you're not going to suffer DHCP scope exhaustion.

But if you have 500 people that want to connect,

you're going to run out of IP addresses

before everybody gets their own.

Now, many DHCP servers use a default lease time

of 86,400 seconds, which is one day,

but I've seen some organizations set their DHCP leases

to seven days or even 30 days.

Now, this is helpful from a security analyst perspective,

because those clients aren't changing

their IP addresses as often,

and so it's easier to correlate log data,

but these longer lease times can lead

to DHCP scope exhaustion

if you have a lot of transient users.

For example, let's say you're running

the wireless network at a local college.

You have hundreds or thousands of different people

that connect to your network on a daily basis.

One student might have a class

on Monday, Wednesday, and Friday,

and another student might have classes

on Tuesday and Thursday.

If you're using seven-day leases,

the first student would still have their lease

for the entire week, and so would the second student.

Now, we're going to need two leases for these two students.

But if we instead lowered our lease time to 24 hours,

these two students could, in theory,

receive the exact same IP, but not at the same time,

because the lease would expire on the first one

before the second one showed up to class.

Now, another thing you can do

to overcome DHCP scope exhaustion

is to increase the scope size.

For example, instead of providing the 254 IP addresses

by using the network of 192.168.1.0/24,

I can instead change my scope to 172.16.1.0/22.

This gives me 1,022 available IPs

for me to assign to my clients,

which is going to serve all 500 of my students with no problem.

The final thing you can do

is decrease the number of devices

that are using the DHCP server and in turn,

the IP addresses from its scope.

In this case, you're going to want to enable port security

or network access control, NAC,

to enable you to prevent clients from accessing your network

and getting assigned an IP address from your DHCP scope.

IP and VLAN settings.

In this video, we're going to discuss IP and VLAN settings.

First, let's talk about IP settings.

This can occur when you have the incorrect IP address,

subnet mask, gateway or DNS server IP address

assigned to a client

and it will cause issues for you with your IP settings.

Remember from your lessons on DHCP,

we talked about the fact that every network client

needs four key pieces of information

in order to communicate properly on the network.

This is their IP address, their subnet mask,

the IP of their default gateway

and the IP of their DNS server.

Now let's take a look at a static assignment

on this OSX client.

Notice here, we have three key pieces of information shown.

The IP address, the subnet mask

and the router or default gateway.

The DNS server IP is on a different tab,

and it really doesn't matter for this example,

as long as we don't need to conduct name resolutions.

So, you were called to troubleshoot this client

because they can't access the internet.

Let's assume you already tried to ping the server

at 8.8.8.8 and it failed.

So, you know you have some kind of a routing issue here.

What could the problem be?

Now, I want you to go ahead and pause the video here

and look at it and see if you can figure out the issue.

All right, I'm going to count to five.

One, two, three, four, five.

All right, you're back?

Did you figure out the issue?

In this case,

the issue is that we have the wrong default gateway.

Notice the IP address is 192.168.1.200,

and it has a subnet mask of 255.255.255.0.

With this subnet mask,

the default gateway would have to be an IP

of 192.168.1 dot something

because it's in this 192.168.1.0/24 network

for us to be able to reach it.

Now, if the default gateway

is set 10.0.1.1 and this is truly the IP of my router,

then I have an incorrect IP address.

Because again, my subnet mask of 255.255.255.0,

if applied to the router's IP address of 10.0.1.1

would tell me I need to have something

in the network of 10.0.1.0/24.

So to get this client to connect to the internet

and have its traffic properly routed,

I need to change either the default gateway to 192.168.1.1

or change the IP address to 10.0.1.200

or something like that.

All right, let's take a look at another example.

This one comes from a Windows client.

Just like our last example,

this client cannot ping 8.8.8.8 successfully.

So you see the client has a statically assigned IP address

of 192.168.1.200.

Its subnet mask is 255.255.255.128

and the default gateway here is 192.168.1.1.

All right, go ahead and pause the video.

I want to see if you can identify the issue

and think about how you're going to fix

this client's network connectivity issues.

Pause the video and come back

in one, two, three, four, five.

All right, you're back?

Did you figure this one out?

Let's take a closer look at that subnet mask.

Notice it wasn't a class full class C of 255.255.255.0

So this isn't the 192.168.1.0/24 network

and it doesn't have 254 usable IP addresses.

Instead we have a subnet mask of 255.255.255.128.

This gives us a /25 network using CIDR notation.

That means we only have 126 usable IP addresses.

So if our gateway is 192.168.1.1,

and we have a subnet mask of 255.255.255.128,

then our network ID is 192.168.1.0

And our broadcast is going to be 192.168.1.127.

Everything between those two ranges

is going to be usable IPs.

But our client was assigned 192.168.1.200.

And that means it's assigned into a range

that's in another network.

So that IP address and gateway aren't on the same sub-net.

This would explain why we can't route our traffic

to the network because we can't reach our default gateway.

This is going to be a problem for us.

So our solution would be to change our IP address

to something on the same sub-net as that default gateway,

like 192.168.1.100

or we could see if there's a gateway

on the same sub-net as our client.

This means we need a gateway

with an IP address of 192.168.1.129

or something between there and 192.168.1.254,

because our network ID will be 192.168.1.128.

and the broadcast will be 192.168.1.255

if we're using the subnet mask for a /25 network

of 255.255.255.128.

All right, now, if you're going to connect to a website

by its domain name and that isn't working,

we need to look at the DNS IP server configuration.

In this case, you'd want to ensure

you have a working DNS server

and the IP has been properly entered on the client.

If you don't have your own DNS server,

you can always set your DNS server's IP to 8.8.8.8

which is the public DNS server hosted by Google.

So here you could see the DNS server

is set to 192.168.1.1 as the primary

and 192.168.1.2 as the secondary.

This is fine as long as the DNS servers there

are running on those IP addresses.

Now, if you don't have DNS servers,

then you want to reconfigure those to the public DNS servers

at 8.8.8.8 and 8.8.4.4,

both of those are Google's DNS servers.

Next let's talk about VLAN settings.

Remember when it comes to VLANs

you need to route the traffic between the VLANs

otherwise your devices aren't going to be able to communicate.

So let's pretend I have two VLANs,

one called IT and one called HR,

even though both IT and HR

are connected to switch one and switch two physically,

they can't communicate with each other

until I route traffic between them using a router.

Also, if you're going to have devices in the same VLAN

they need to be in the same logical sub-net.

So in this example,

all of my clients are part of the IT VLAN,

and they should be using the same sub-net of 192.168.1.0/24.

And all of my HR VLAN clients should use their own sub-net

something like 192.168.2.0/ 24.

So let's take a look at this

using a basic network logical diagram.

Here, we see one IT client and one HR client.

Each one is assigned an IP address in a /24 network.

The IT client is assigned to the IT sub-net

of 192.168.1.0/24 in VLAN 100.

And the HR client is going to be assigned

to 192.168.2.0/24 as it's network in VLAN 200.

To simplify this topology,

I left out all the other IT and HR clients,

but there could be 50 or 60 of these

connected there as well, either to switch one or two.

It really doesn't matter for our purposes,

as long as they're configured into the proper VLAN.

Now, as this is a logical diagram

and how we see it set up here,

the IT client cannot communicate to the HR client

and neither of those clients

can communicate with the internet.

Why is that?

All right, I want you to pause the video here

and I'm going to count to five

and I want you to come back and give me the answer.

One, two, three, four, five.

All right, you're back?

Did you figure out the issue?

Well, this issue is all going to come down to the fact

that there are no gateways

for the IT or HR clients to communicate with.

Notice in this logical topology, we only have one router

and that router has an interface IP of 10.0.0.1

in the 10.0.0.0/24 network.

This means it's the default VLAN, VLAN 1

and its network isn't on the same logical network

as either the IT or HR VLANs.

So for us to allow the IT and HR clients to communicate,

they're going to need a place to route traffic

between switch one and switch two.

Then to allow both of them to communicate with the internet,

we need to connect them to a new router

that's connected to the internet as well.

Now our easiest and cheapest solution in this case

would be to remove the connection

between switch one and switch two.

Then we can connect switch one to router one

and assign it a new interface

on an IP address in the IT VLAN.

We could also connect switch two directly to router one

and assign it an interface with the HR VLAN.

Now we can use router one to route traffic between VLAN 100,

the IT VLAN and VLAN 200, the HR VLAN.

And we can route both of those VLANs out to the internet,

going through router one as well.

So remember, if you start having devices

that can't communicate with each other,

like one of the IT clients can't communicate

with one of the HR clients,

it could be an improper VLAN configuration.

Make sure you check your configuration

and that there's a proper routing setup

between the different VLANs

because the number one cause of issues

when you're dealing with VLANs that won't communicate

is people aren't routing the traffic right.

Another common mistake people make when dealing with VLANs

is simply that they don't use them.

Now, if you don't use VLANs

all of your traffic will end up in the default VLAN, VLAN 1.

When this occurs,

you're going to have a really large single broadcast domain.

For example,

if you have a server that's operating in VLAN 1 ,

the default VLAN,

it can experience slow load times

because there's too many devices located inside VLAN 1

and the number of broadcasts

are going to slow down the entire VLAN.

Instead, this server, which currently has an untagged port,

and therefore it's assigned to VLAN 1 by default,

should be added to the server VLAN with the other servers.

This will segregate them from all the other client villains

and increase their speed dramatically.

Firewall issues, in this video,

we're going to discuss firewall issues

and how to troubleshoot network issues

involving incorrect firewall settings

and block services, ports or addresses.

First, let's talk about the purpose of a firewall.

Remember firewalls or network security devices

that moderate and filter

incoming and outgoing network traffic

based upon established rule sets.

Essentially firewalls act as an inspection point and barrier

between a private internal network and the public internet

or other private internal networks,

if you're using screen subnets,

Now, firewalls can exist as either host-based firewalls

or network-based firewalls.

A host-based firewall is a piece of software

that runs on an individual computer or device

that's connected to your network

and performs the functions of a firewall

to protect that one single device.

For example, if you're running a windows, client or server,

you can utilize the built-in windows defender firewall

to go dock to host based,

two-way network traffic filtering and inspection,

as well as blocking unauthorized network traffic

from flowing into or out of your device.

A network-based firewall is a network security device

that's deployed inline with the network traffic flow,

just before the border or gateway router

in order to monitor and filter incoming

and outgoing network traffic

based upon your established rule sets.

In general, regardless of whether the issue resides on a

host-based firewall or a network-based firewall,

the network connectivity issues experience

will be caused by one of three different situations.

First, access to protected resources

from unprotected networks, isn't working.

Second, access to unprotected resources

from protected networks, isn't working.

Or third, access to the firewall

and its configurations, isn't working.

Basically the problems can be broken down

into either traffic is not going through the firewall

or traffic is not going to the firewall,

and in either case it's not working properly.

So to troubleshoot these issues,

you should use your seven-step troubleshooting method

and understand the OSI model to troubleshoot each layer

from layer one physical all the way up

until you identify the issues.

Now, for example, is the firewall properly cabled

into the network at the right position?

If so, does the link lights on the network interface card

show up that the link is established

between the router and the firewall?

If it does layer, one is probably not your issue.

Next, we go to layer two,

and we determine if the router and firewall

are communicating using AARP and their Mac addresses.

If they are, we're going to move up to layer three

and determine if the firewall has a valid IP address,

subnet mask and default gateway.

And that way it can communicate properly on the network.

Once we've done all that we can now inspect the firewall

itself for issues.

Usually when traffic isn't flowing to

or through the firewall,

the issue is going to be related to a misconfigured rule set

as part of your access control list or ACL.

Now the access control list

is simply a collection of permit and deny conditions,

which we call rules.

And they're going to provide security

by blocking unauthorized users

and allowing authorized users to access specific resources.

To inspect the firewall rules on a network based firewall,

you're going to use the command show access dash lists

to display the contents of the current access control list

on a Cisco device, as an example.

Each device is going to have a different command,

but for Cisco it's show access lists.

Now, let's say for example, you're trying to figure out

why the network clients and the internet filter group

are not able to access Google, Facebook

or Dion training's websites.

You might log into your firewall or router

and check the current ACL restrictions.

In this example,

you can see there's a deny statement in line 20

for the internet filter group.

And it states that all TCP network traffic

from any IP to any IP over any port

should be blocked by this rule.

Basically, any clients have been added

to the internet filter group

will be unable to connect to any websites

because they're using TCP to connect a report 80

or port 443, when they're trying to go to a website.

Similarly, if we have a client in the one-on-one group

and it's having timing issues,

we could look at our ACL and see what the root causes

looking at line 10 within the one-to-one access control list

states to deny any UDP traffic

from any IP to any IP that uses NTP,

which is port 123 and use for the network time protocol.

The problem here is that NTP operates using UDP traffic.

So the single line in the ACL

will break all MTP functionality

for any devices assigned to group 101.

So when you're writing or editing an ACL rule,

always be careful to think through

what you're intending to do with that rule.

First, you need to ensure there's no typos in your rules

because this will cause a lot of issues,

they'll result in traffic being blocked.

When it really shouldn't be.

Second, verify the protocol important numbers

that you're referencing in your rule

and ensure they're correct.

Do you really want to block TCP or UDP?

Make that decision?

You want to block a specific port or all ports?

All of this is important to consider.

Third, verify the source and destination addresses

are referenced by the rule.

Did you include the correct IP address or network IP

and the correct subnet mask?

A simple typo like 0.0.255.255 instead of 0.0.0.255

is going to cost 65,636 IPs to be blocked.

Instead of the 256 IPS, you were intending to block.

Fourth, verify the order of the rules

is being applied correctly.

Remember ACL's are always processing order

from the top of the list to the bottom of the list.

Your most specific rules need to be first

and your motion rules need to be at the end.

Let's consider this example and see if we can determine

why a network client can't connect to Google servers

at 8.8.8.8 from within the Dion training group of clients.

Now, first, we're going to pull up the access control list

and look for the Dion training group rules.

Under these rules,

we look under the rules pertaining to this issue.

In this case,

we can't reach the server located at 8.8.8.8.

So if we look at rule 20,

we're going to see there's a permit rule for all TCP traffic

going from any IP, going to the server at 8.8.8.8,

if it's over port 80, which is used for web traffic.

So based on this rule loan,

the traffic should be able to reach the server.

Now, let's see what other rules we have

for servers at 8.8.8.8.

Now we have one rule at line 40,

and it again says to permit traffic over TCP

from any IP to the server at 8.8.8.8 using port 25.

So we're going to allow email traffic over SMTP

to be sent from any of our clients

to the server at 8.8.8.8

Again, this seems fine, and we shouldn't have an issue.

Now, remember, ACL rules are implied in order,

and once it finds a matching rule,

it's going to stop as it goes down the access list.

So look at it from the beginning.

The first rule is line 10.

It says to deny any TCP traffic

from any IP address to any IP address.

And this applies to all ports because none were specified.

So if I'm trying to visit the server at 8.8.8.8,

will rule 10 match this packet?

Is it going to go from any IP to any IP using TCP?

Yes, yes it is.

Therefore the traffic is going to be blocked

and it will never get to rule 20 or rule 40

that specifically allow traffic to this server

at 8.8.8.8 over port 80 or port 25.

So instead we can change the order of this ACL

and we're going to put the more specific lines

like 20 and 40 at the top.

So we're going to make them 10 and 20 respectfully.

Then we're going to take the current line 10

and move it to the bottom of our list.

So to make this easier to see I'm creating a new group here

called Dion training new at the bottom of this ACL.

Here, you can see the difference in the order

from Dion training group to the Dion training new group.

So notice I now have our most specific ACL

listed at 10 and 20 and a more generic one at line 30,

which is for the any IP to any IP, but for a specific port.

Then I have my most generic rules at the bottom,

lines, 40 and 50.

This is going to block all traffic for UDP

and all traffic for TCP.

Remember when you're troubleshooting issues with firewalls,

always check your ACL's

to ensure they're in the right sequence

and that you haven't missed typed anything in them

because this can lead to a lot of connectivity issues

and the wrong traffic being blocked

or being allowed through your firewall.

Similarly, when you're dealing with software firewalls,

like the windows defender firewall,

it's important to look not just at the IP addresses

and ports that are being blocked,

but also you need to look at the

applications and services themselves.

Under your windows defender firewall,

you're going to see inbound rules and outbound rules listed.

Under each type,

you're going to see the name of the application or service

and whether it's allowed or denied.

Then you're going to see if any specific IP addresses reports

are being allowed or blocked

with those applications and services.

Just like in the earlier examples with network firewalls,

a simple typo here can cause a lot of connectivity problems

for your clients and your servers.

So always double check your ACL's

to ensure they're blocking and allowing

exactly what you want them to do and in the right order.

DNS and NTP Issues.

In this video, we're going to discuss how to troubleshoot DNS

and NTP issues.

First let's focus on DNS.

Remember, DNS is used to match the domain names

with the corresponding IP addresses

that are used by a server.

This allows us to use memorable domain names

while our computers can access the information

using those IP addresses.

If your network clients

are unable to resolve their domain names to IP addresses

such as figuring out that diontraining.com

is supposed to point to 45.79.184.180, for example,

then you most likely have a DNS issue.

So first you needed to determine

if the issue is occurring on a single network client,

or is it a larger wide-scale DNS issue

on your network?

If it's only affecting one client,

then it's most likely going to be an issue

with that client's TCP/IP settings.

By running the IP, ifconfig or ip commands,

you can determine the IP address of the assigned DNS server.

Once you have that IP,

you should verify connectivity between your client

and that DNS server.

If there's no connectivity between them,

then you need to troubleshoot the connection at layer one

layer two, or layer three of the OSI model

to fix this DNS issue,

because your client simply can't reach the DNS server.

If your client can reach the DNS server,

but there's still a DNS issue,

then you need to either flush the DNS cache on the client

or change the configuration to allow the client

to use a different DNS server.

Something like Google's DNS servers

located at 8.8.8.8 and 8.8.4.4.

On the other hand,

if a client doesn't seem to be having an issue

with their configuration,

it may be your DNS server itself

is not properly responding.

In this case, you're going to troubleshoot your DNS server.

Now, this is usually going to be an issue

specifically for people who run their own websites

and control their own DNS records.

In these cases,

you need to verify that your A records

and your CNAME records were properly created.

With an A record,

you need to ensure the domain name is typed in properly,

and the IP address has been entered correctly.

A simple typo on either of these two parts of the A record

will cause users to not be able to locate your servers

and they won't be able to access them

using your domain name.

For your CNAME or Canonical Name records,

you need to ensure that the domain name used

as the source and destination are both spelled properly,

otherwise, you can be redirecting users to the wrong server

or to someplace that doesn't exist.

To verify your ANAME and CNAME records,

you can use the nslookup command.

Another common issue at DNS records

is the Time to Live

or TTL might be set incorrectly.

If the Time to Live is set too high,

the old DNS records will remain cached

until the Time to Live expires.

So if you have a Time to Live of 86,400 seconds,

your DNS server records won't expire

or be refreshed by DNS cache

until at least one day has elapsed.

In general, I like to keep my Time to Live

on my DNS server records at a pretty short interval,

something like 300 seconds,

which is about five minutes.

This avoids any caching issues

if I'm making frequent changes to my networks

or my websites.

Now another issue with DNS that occurs

is one of high latency.

If your DNS records are hosted far away from your users,

that's going to take more time and more delay

for them to access those records

when they're looking up a particular domain.

This is known as DNS Latency.

To reduce DNS latency

and improve the overall network performance for your users,

you should use DNS servers

that are located closer to your users,

such as one that you host yourself

within your DMZ or screened subnet,

or one hosted by your internet service provider directly.

Next, we're going to discuss NTP

or the Network Time Protocol.

And there's some issues around this as well.

Remember, NTP is a protocol

that allows the synchronization of system clocks

between different layers of a hierarchal,

semi-layered system of time sources.

This is important

because many of our distributed applications,

such as network authentication,

they're going to rely on proper synchronization of time

between your client and a server,

and our networks use NTP to do all of that.

In general, issues with NTP

are caused by the NTP packets not being received.

NTP packets may not be processed,

or the NTP packets have errors or packet loss.

If the NTP packets are not being received,

this needs to be troubleshot

to determine the root cause.

You need to begin at the physical layer

and ensure your clients and servers are properly connected

and cabled to your network.

Then if the NTP server is on your Local Area Network,

you need to verify it's communicating

between the client and the server

using their MAC addresses properly.

If the NTP servers located outside the Local Area Network,

you need to verify that the client can communicate

to that server using layer three IP addresses

for that server.

Now in general, if NTP packets are not being received,

this is more of a general network communication issue

at layer one, layer two, layer three,

or possibly a DNS server issue,

if you're referring to that NTP server

using its domain name and not its IP address.

Now, if the NTP packets are being received,

but they're not being processed properly,

you need to look at the network client or the NTP server

to ensure they're operating the NTP service

to read and process those NTP packets

that are being sent and received by these devices.

If the NTP process or service

doesn't act on the NTP packets being received,

there's going to be network communication issues

with other services, things like HTTPS

and network authentication processes.

Now, if the NTP packets are processed,

but there's errors or packet loss in them,

there's going to be a loss of time synchronization

that can occur.

The loss of synchronization might occur

if dispersion or delayed value for server goes really high.

High values indicate that packets are taking way too long

to get to the client from the server

in reference to the root of the clock.

So the local machine cannot trust the accuracy of the time

present in the packet

because it doesn't know how long

it took the packet to get there.

If there's a saturated link

or buffering is occurring along the way,

the packets can get delayed

as they come to the NTP client.

Now, the timestamp contained within a subsequent NTP packet

can occasionally vary a lot

and the local client cannot really adjust for that variance.

So if you're seeing errors

or lost packets with NTP,

that's going to cause a lot of loss of synchronization for you.

And you need to ensure that there's no saturation

in your network connections

and that your network connectivity is adequate

to be able to send the NTP packets in a timely manner.

Network performance issues.

In this video, we're going to discuss

how to troubleshoot network performance issues

that you may experience out in the field.

Now the five most common causes

of network performance issues

are high CPU usage in a network device,

high bandwidth usage in a network,

poor physical connectivity,

malfunctioning of your network or DNS problems.

First, it's important to realize that every network device

such as your routers, switches and firewalls

are at their core, a computer.

That includes a CPU or central processing unit.

If that device begins to experience

a high CPU utilization rate,

that device is going to start slowing down and in turn,

the network that is being processed for all those packets

is also going to slow down.

So whenever a CPU is overutilized,

the latency, jitter and packet loss will start to increase

and this can cause the entire network performance

to deteriorate on you.

So to solve this issue, you need to either

upgrade your network devices to more powerful ones

such as enterprise class routers and firewalls

or you need to simplify the processing load

that you're putting on those devices.

For example, I once saw an enterprise network

where their border firewall

was slowing down the entire network.

Now when we looked at it closer,

we saw their access list had over 3,000 entries in it.

That meant that every time a packet was received,

it was checked against these 3,000 individual entries

to find its match or to eventually block that packet.

Now this consumes a lot of processing time

and leads to high CPU utilization rates.

Now we conducted an ACO review

and we were able to simplify their rule set

down to about 300 rules.

This drastically reduced the CPU utilization rate they had

and sped up the network.

Second, high bandwidth utilization

is another cause of network performance deterioration.

Now when bandwidth utilization is high,

network communications have to wait

to enter or leave that network.

This can cause buffers to fill up

and in the worst cases, packets can be dropped.

Now when those packets are dropped,

they're going to be retransmitted if they were sent using TCP.

And this leads again,

to even higher bandwidth utilization rates

because we have retransmissions.

To solve this issue,

you can either increase your bandwidth size

by paying more to your internet service provider

or you can do a network flow analysis

and determine what sites and traffic types

are being used by all of your clients.

For example, if 90% of your traffic is being wasted

by people scrolling Facebook each day,

you may need to change your acceptable use policy

or reduce or eliminate

when people are allowed to use Facebook on your network.

Literally, I had one network where 90% of our traffic

was either going to or coming from Facebook

and our end users kept complaining

because they couldn't do any real work on their job

because our internet was so slow.

And this is why conducting a NetFlow analysis

can really help you understand

what your users are really doing on your network

and is it something you want to allow.

Third, you may have network performance issues

if you have a poor physical connection.

To solve this, you're going to need to check your cables

and test them one by one.

Now if you suspect it's an issue

with the internet search provider's portion of the network,

you need to connect a test client

directly to the demarcation point

and test the connection from there.

If that connection is poor,

then you know it's your ISP's problem to solve.

If it isn't, that means it's something in your network

that's the problem and you need to start testing every cable

from the from the demarc point

all the way back to your border router

and then to your switch and then to your client

until you find where that broken or damaged cable might be

that's causing the slowdown in your network connection.

Remember, a damaged cable may still operate,

but it's going to cause additional errors

and these errors require data

to be retransmitted over and over again

and this slows down your overall network performance.

To test your cables, always use a cable tester

for twisted pair connections

or a fiber light meter for fiber optic connections.

Fourth, we have malfunctioning of our network.

Now if you have misconfigurations of your devices

or hardware failures,

your network performance is obviously going to suffer.

Sometimes this can even be caused

by using old or outdated network operating systems.

Again, this is an area

where your seven step troubleshooting method

is going to help you identify the exact location

of the device that's having these issues

and then you can focus on whether it's a configuration issue

or a hardware failure issue

that's causing those network performance issues.

Finally, fifth, we have DNS problems in our network.

Now we already talked specifically about DNS issues

in a separate lesson,

but DNS issues are a serious cause

of a lot of our network performance issues.

Remember, if you have a high DNS latency,

this is going to slow down the overall user experience

because when that user requests a website,

they first have to go and resolve that domain name

all the way out to that DNS server

and get the IP address over DNS.

Other issues.

In this video we're going to discuss some other issues

you may need to troubleshoot.

Things like low optical link budgets, certificate issues,

license feature issues, BYOD challenges

and hardware failures.

First, let's talk about low optical link budgets.

And what exactly is an optical link budget?

Now an optical link budget is a calculation that considers

all the anticipated losses along the length

of a fiber optic connection.

This is important to understand.

Because the light signal that's going across

that fiber optic cable will lose signal strength

as it travels down this cable.

Now this occurs naturally due to the distance of the cable,

as well as from losses due to multiplexing,

benzing your cable, imperfect connections, patches

or splices that happen along the fiber optic cable.

If you experience a low optical link budget,

your fiber connection will experience issues

such as reduced transmission efficiency,

slower connection speeds

or even downtime on that connection.

To measure the condition of your fiber optic connection,

you're going to use an optical time domain reflectometer

to measure the amount of losses or reflections

that are occurring in the connection.

This reading from the optical time domain reflectometer

is going to be reported in decibels per kilometer.

And this indicates how much attenuation and degradation

is occurring over the length of that connection.

Normally, you should experience 0.25 decibels per kilometer

for a standard fiber optic cable.

But if you experience a higher rate than this,

then you may have a low optical link budget.

To calculate your link budget.

You simply take the receiver's power budget or how much

initial signal you're going to be transmitting out,

and then you subtract any multiplexing and demultiplexing

losses as well as losses from the fiber itself

that's caused by those distances and the imperfections.

And any losses from the connectors or patch panels

that are being used as well.

Now, this will give you the total optical link budget.

For example, let's say I designed a fiber optic circuit

with a receiver that can sense light received between

negative seven decibels and negative 23 decibels.

And I send the signal out at positive five decibels.

Now, if I only have a loss of 20 decibels

due to the distance, the connectors

and a splice in that cable.

The is going to be able to pick up that signal

because I still have negative 15 decibels of light signal

being received at that distant end.

And negative 15 is in between negative seven

and negative 23.

On the other hand, if the fiber connection was broken

and somebody went to repair it by splicing that connection,

maybe they did a really bad job of it.

And adds an extra 25 decibels of signal loss.

Now I'm going to transmit at the same five decibels

that I was before.

But I'm losing 15 decibels for distance

in that first splice.

And now because of this poor second splice,

I'm losing another 25 decibels.

This brings my total value on the receiving end

to negative 35 decibels.

And that means the receiver can't pick up that signal

because it can only sense the signals between negative seven

and negative 23 decibels.

And negative 35 is far too weak for the receiver to see it.

Now, we're going to have a broken fiber link essentially,

because we have a low optical link budget level.

So, what can we do to fix this?

Well, we can either increase the power of the transmitter

to say plus 20 decibels instead of plus five decibels.

Or we can have somebody go back and try to do a better job

of splicing that cable.

Now, this isn't a very realistic example

because most professional splices will only cause a loss

of 0.1 or 0.2 decibels.

But hopefully you're getting the idea of how low optical

link budget can work and negatively affect

your fiber networks.

Next, we have certificate issues

that can cause network issues for us as well.

A digital certificate is used as a credential

to facilitate the verification of identities

between users inside of a transaction.

For example, when you attempt to connect

to an e-commerce site over HTTPS,

your network client uses digital certificates

to validate the server's identity and decide

if it can really trust that server when sending sensitive

information over to it.

The most common certificate issues are going to occur

on a websites SSL or TLS certificate

when it's displaying as untrusted.

Now, this occurs for one of three reasons.

It can be that the digital certificate is not signed

by a trusted certificate authority,

the certificate itself has already expired

or the server didn't have a certificate associated

with a trusted route certificate.

Now, regardless of which of these three things is happening,

the end result is going to be the same.

Your client's browser is not going to show a secure

connection over HTTPS because it's web browser

and the server are not communicating over a secure tunnel.

Now, in either of these cases,

you can't solve the issue for your network clients

because you don't own that web server.

But if you were the one who owned that web server,

then it becomes your problem to fix.

Now in this case, you need to purchase a digital certificate

from a trusted certificate authority and install it.

Or you need to renew your expired digital certificate.

Or you need to install a certificate from a trusted

certificate authority with a valid route certificate

on your server.

In addition to using digital certificates with HTTPS

websites,

we also can use digital certificates inside of our networks

for network authentication using 802.1X with EAP.

In these cases, your security team's going to run

your organizations own certificate authority

to create these digital certificates and issue them

to the network clients and the servers.

Again,

if you're having issues with these digital certificates,

you need to ensure they're trusted, that they're not expired

and that they're installed properly on the network devices

and the network clients.

Next, we need to talk about licensed feature issues

that could arise in your networks.

Sometimes when troubleshooting issues in your network,

you may come across an error message such as error,

feature not licensed.

Now as you can see in this example

from a NetScaler VPX appliance,

there are many different features that are enabled

or disabled based upon the license has been purchased

by this organization.

For example, the license they have purchased will allow them

to do load balancing and content switching.

But it does not support global server load balancing

or clustering.

This is a different feature set that requires a different

and more expensive license.

Now if you get an error concerning a particular license

feature in this or another network device,

you first need to determine what license

you have loaded on that device.

Then compare the license you loaded

with the features it unlocks.

If the license is unlocking the features you expected,

you may need to contact the manufacturer to troubleshoot

the issue.

But you may realize you simply purchase the wrong license

for the features that you need.

And in this case,

you need to work with your organization's purchasing agents

and their contracting professionals to get the right license

procured so you can load it up into the device.

Now this is a common issue in large bureaucratic

organizations where the people who use the things

and install the devices are not the same ones

who are empowered to make purchasing decisions.

As a young network administrator.

I remember submitting the requisition forms

to my organization for all the licenses I needed.

I specified that I needed the platinum license.

And the contracting person decided, you know what,

the gold license would be just fine

because it costs 35% less.

Well, guess what?

That contracting person didn't know that a gold license

didn't include the three critical features

that we actually needed.

And those features were the whole reason we were buying

this particular network appliance.

So, when we received the license key

and we tried to load it up on the network appliance,

we kept getting the feature not licensed error message.

And it took us almost two days to figure out

that the reason was our organization gave us a gold license

and not a platinum license that we really needed.

So learn from our mistake.

Make sure you tell the contract personnel

that substitutions are simply not allowed.

You need this level of license or just won't work

for the features you need.

Next let's discuss BYOD challenges

or bring your own device challenges.

Now I don't want to specifically focus on security

challenges associated with BYOB policies.

Because we've already talked about that in other videos.

Instead, I really want to focus on the networking issues

that you may come across when you're trying to support

a BYOB policy inside your organization.

Now BYOD or bring your own device is this policy

that allows your end users to bring their own smartphones,

tablets, laptops and other technical devices into work

and use them on your organization's network.

Now BYOB allows the organization to save money

by not having to purchase all these devices

for the employees.

But instead they're relying on the employees

to bring their own equipment and their own devices

and then do the business on those devices

using your organization's network.

Now the biggest challenge with BYOD

besides securing these devices,

is actually supporting these devices.

When a user brings their own device,

you're no longer supporting one or two models of laptops,

but instead you've got 50 or 100

or 200 different varieties now.

Your employees may bring a Windows 10 Home Edition laptop

or a MacBook Air or a Chromebook.

And guess what,

you're going to be expected to support all of them.

This is a massive headache and a huge challenge

for support personnel,

like our service desk and our network technicians.

Now, when a device doesn't work properly

like we want to expect it to,

we have to determine is it the device

or is it some software the user loaded

or is it a network issue that we need to solve?

This makes it very challenging.

Honestly, well many organizations think that implementing

a BYOB policy can save them a lot of money

because they'll have a reduced capital expenditure

or CapEx costs.

It really just increases your OPEX

or operational expenditures because now you're wasting

so much time on labor hours to support and troubleshoot

all these different devices.

Another challenge with supporting these devices is ensuring

the security of your network and how these devices

are going to access your network.

Are you going to let these devices connect

on your wired network connections

or are you going to make them use wireless?

We require that they be registered ahead of time

so you know what their MAC addresses are and they can be

identified in waitlist.

Or are you going to require these BYOD devices

to remain on a separate VLAN?

That way they're not going to touch your internal network

services, and if they do,

they have to pass through a screened sub-net.

All of these are valid questions to consider

as you determine how you're going to support BYOB

on your network,

both operationally and from a troubleshooting

and repair perspective.

Finally, let's talk about hardware failures.

Hardware failures can occur all over your network.

Your routers, your switches and your firewalls

can fail for all sorts of reasons

just like your network clients can.

As you begin to troubleshoot this issue,

you need to pinpoint both which device is experiencing

the failure and which component on the device has failed.

Once you identify the device that failed,

such as a router that isn't passing traffic

from one subnet to another.

You then need to identify the component that failed.

Most components on our network devices

are field replaceable.

Which means you can swap them out with different components

and get the device back up and operational very quickly.

For example, if we had one of our dual power supplies fail

in a border router,

we can schedule an emergency maintenance window.

We can power down the device, open up the chassis,

replace the broken power supply

and then return the device to normal operations.

If an interface card or module is broken or defective,

we can simply replace that as well.

And many of these are considered hot pluggable modules.

So if you have an SFP plus module that fails,

we can simply replace it without even shutting down

the network device or taking it offline.

If a client or server on the other hand

is found to have a defective component or hardware failure,

we can work with our CompTIA A+ technicians

to solve those issues by replacing the associated

hardware components.

Normally with a defective or field piece of hardware,

the fastest way to restore service is simply to replace

the component that's failed us.

In some cases,

such as a failed motherboard on a router or switch,

you may need to replace the entire device.

In these cases, you should get a spare switch or router

from your supply closet, mounted into the rack,

load up your backup configurations from the failed device

and put that into the replacement device

and then reconnect all the cables to it.

And finally restore service using your new device.

Then you can take the field device out of the rack,

return it to the manufacturer for repair

and then it can become part of your spares in the future

if it's under warranty or you could dispose of it properly

if it's reached the end of its useful life.