F5.COM (HTTPS://F5.COM) | GITHUB (HTTPS://GITHUB.

COM/F5NETWORKS)

| DEVCENTRAL (HTTPS://DEVCENTRAL.F5.COM) | SUPPORT (HTTPS://SUPPORT.F5.COM)

(https://f5.com)
R

Uno cial - F5 Certi cation Exam Prep Material (../../index.html) > F5 101 - App Delivery Fundamentals Exam Study Guide -
Created 03/06/20 (../class1.html)
Source (../../_sources/class1/modules/module2.rst.txt) | Edit on  (https://github.com/f5devcentral/f5-agility-labs-cert)
PDF

Section 2 - Troubleshooting¶

Objective - 2.01 Identify application and network errors¶

2.01 - Identify general meanings of HTTP error codes

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
(https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)

HTTP error codes

The Internet Assigned Numbers Authority (IANA) maintains the o cial registry of HTTP status
codes.

All HTTP response status codes are separated into ve classes or categories. The rst digit of the
status code de nes the class of response, while the last two digits do not have any classifying or
categorization role. There are ve classes de ned by the standard:

1xx informational response – An informational response indicates that the request was received
and understood. It is issued on a provisional basis while request processing continues. It alerts
the client to wait for a nal response. The message consists only of the status line and optional
header elds, and is terminated by an empty line. As the HTTP/1.0 standard did not de ne any
1xx status codes, servers must not send a 1xx response to an HTTP/1.0 compliant client except
under experimental conditions.
2xx successful – This class of status codes indicates the action requested by the client was
received, understood and accepted.
3xx redirection – This class of status code indicates the client must take additional action to
complete the request. Many of these status codes are used in URL redirection. A user agent
may carry out the additional action with no user interaction only if the method used in the
 second request is GET or HEAD. A user agent may automatically redirect a request. A user
agent should detect and intervene to prevent cyclical redirects.
4xx client error – This class of status code is intended for situations in which the error seems to
have been caused by the client. Except when responding to a HEAD request, the server should
include an entity containing an explanation of the error situation, and whether it is a temporary
or permanent condition. These status codes are applicable to any request method. User agents
should display any included entity to the user.
5xx server error – The server failed to ful ll a request. Response status codes beginning with
the digit “5” indicate cases in which the server is aware that it has encountered an error or is
otherwise incapable of performing the request. Except when responding to a HEAD request, the
server should include an entity containing an explanation of the error situation and indicate
whether it is a temporary or permanent condition. Likewise, user agents should display any
included entity to the user. These response codes are applicable to any request method.

For this topic, it is good to know the di erent class levels and to also understand many of the
common errors within each class beyond the common 302 and 404 and 503. All of which can be
found on the link provided. You never know what might appear on the exam.

There are also codes that are not speci ed by any standard, but they are likely not going to appear
on this exam.

2.01 - Identify possible reasons and methods for connection termination

(Ref:2) https://learning.oreilly.com/library/view/tcpip-illustrated-volume/0201633469/ch18.html%20-
%20ch18lev2sec4

https://www.oreilly.com/library/view/http-the-de nitive/1565925092/ch04s07.html
(https://www.oreilly.com/library/view/http-the-de nitive/1565925092/ch04s07.html)

TCP

While it takes three segments to establish a connection, it takes four to terminate a connection.
This is caused by TCP’s half-close. Since a TCP connection is full-duplex (that is, data can be
owing in each direction independently of the other direction), each direction must be shut down
independently. The rule is that either end can send a FIN when it is done sending data. When a
TCP receives a FIN, it must notify the application that the other end has terminated that direction of
data ow. The sending of a FIN is normally the result of the application issuing a close.

The receipt of a FIN only means there will be no more data owing in that direction. A TCP can still
send data after receiving a FIN. While it’s possible for an application to take advantage of this half-
close, in practice few TCP applications use it.

HTTP Connection Termination

Any HTTP client, server, or proxy can close a TCP transport connection at any time. The
connections normally are closed at the end of a message, but during error conditions, the
connection may be closed in the middle of a header line or in other strange places.
This situation is common with pipelined persistent connections. HTTP applications are free to close
persistent connections after any period of time. For example, after a persistent connection has
been idle for a while, a server may decide to shut it down.

However, the server can never know for sure that the client on the other end of the line wasn’t
about to send data at the same time that the “idle” connection was being shut down by the server.
If this happens, the client sees a connection error in the middle of writing its request message.

Content-Length and Truncation

Each HTTP response should have an accurate Content-Length header to describe the size of the
response body. Some older HTTP servers omit the Content-Length header or include an erroneous
length, depending on a server connection close to signify the actual end of data.

When a client or proxy receives an HTTP response terminating in connection close, and the actual
transferred entity length doesn’t match the Content-Length (or there is no Content-Length), the
receiver should question the correctness of the length.

If the receiver is a caching proxy, the receiver should not cache the response (to minimize future
compounding of a potential error). The proxy should forward the questionable message intact,
without attempting to “correct” the Content-Length, to maintain semantic transparency.

Connection Close Tolerance, Retries, and Idempotency

Connections can close at any time, even in non-error conditions. HTTP applications have to be
ready to properly handle unexpected closes. If a transport connection closes while the client is
performing a transaction, the client should reopen the connection and retry one time, unless the
transaction has side e ects. The situation is worse for pipelined connections. The client can
enqueue a large number of requests, but the origin server can close the connection, leaving
numerous requests unprocessed and in need of rescheduling.

Side e ects are important. When a connection closes after some request data was sent but before
the response is returned, the client cannot be 100% sure how much of the transaction actually was
invoked by the server. Some transactions, such as GETting a static HTML page, can be repeated
again and again without changing anything. Other transactions, such as POSTing an order to an
online bookstore, shouldn’t be repeated, or you may risk multiple orders.

A transaction is idempotent if it yields the same result regardless of whether it is executed once or
many times. Implementors can assume the GET, HEAD, PUT, DELETE, TRACE, and OPTIONS
methods share this property.[19] Clients shouldn’t pipeline nonidempotent requests (such as
POSTs). Otherwise, a premature termination of the transport connection could lead to
indeterminate results. If you want to send a nonidempotent request, you should wait for the
response status for the previous request.

Nonidempotent methods or sequences must not be retried automatically, although user agents
may o er a human operator the choice of retrying the request. For example, most browsers will
o er a dialog box when reloading a cached POST response, asking if you want to post the
transaction again.

Graceful Connection Close

TCP connections are bidirectional, as shown in the following gure. Each side of a TCP connection
has an input queue and an output queue, for data being read or written. Data placed in the output
of one side will eventually show up on the input of the other side.

Full and half closes

An application can close either or both of the TCP input and output channels. A close( ) sockets call
closes both the input and output channels of a TCP connection. This is called a “full close” and is
depicted in gure “a” below. You can use the shutdown( ) sockets call to close either the input or
output channel individually. This is called a “half close” and is depicted in gure “b” and “c” below.

TCP close and reset errors

Simple HTTP applications can use only full closes. But when applications start talking to many
other types of HTTP clients, servers, and proxies, and when they start using pipelined persistent
connections, it becomes important for them to use half closes to prevent peers from getting
unexpected write errors.

In general, closing the output channel of your connection is always safe. The peer on the other side
of the connection will be noti ed that you closed the connection by getting an end-of-stream
noti cation once all the data has been read from its bu er.
Closing the input channel of your connection is riskier, unless you know the other side doesn’t plan
to send any more data. If the other side sends data to your closed input channel, the operating
system will issue a TCP “connection reset by peer” message back to the other side’s machine, as
shown in the gure below. Most operating systems treat this as a serious error and erase any
bu ered data the other side has not read yet. This is very bad for pipelined connections.

Say you have sent 10 pipelined requests on a persistent connection, and the responses already
have arrived and are sitting in your operating system’s bu er (but the application hasn’t read them
yet). Now say you send request #11, but the server decides you’ve used this connection long
enough, and closes it. Your request #11 will arrive at a closed connection and will re ect a reset
back to you. This reset will erase your input bu ers.

When you nally get to reading data, you will get a connection reset by peer error, and the
bu ered, unread response data will be lost, even though much of it successfully arrived at your
machine.

Graceful close

The HTTP speci cation counsels that when clients or servers want to close a connection
unexpectedly, they should “issue a graceful close on the transport connection,” but it doesn’t
describe how to do that.

In general, applications implementing graceful closes will rst close their output channels and then
wait for the peer on the other side of the connection to close its output channels. When both sides
are done telling each other they won’t be sending any more data (i.e., closing output channels), the
connection can be closed fully, with no risk of reset.

Unfortunately, there is no guarantee that the peer implements or checks for half closes. For this
reason, applications wanting to close gracefully should half close their output channels and
periodically check the status of their input channels (looking for data or for the end of the stream).
If the input channel isn’t closed by the peer within some timeout period, the application may force
connection close to save resources.

2.01 - Identify possible causes for failure to establish connection

Application Connection failures

When it comes to connection failures to application’s the sky is the limit for causes. At the simplest
level it can be a loss of network connectivity for the initiating system or receiving system and it
goes up the OSI stack from there with reasons the application is not responding. You can also have
a human error like mistyping a URL, miscon guring a setting in a browser or application tool like
Putty. When identifying problems like this you should start with the simplest causes and work your
way up to more complicated issues.

Objective - 2.02 Given a scenario, verify Layer 2 mapping (ARP)¶

2.02 - Explain one-to-one mapping of MAC to IP

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-
administration-11-6-0/11.html (https://techdocs.f5.com/kb/en-us/products/big-
ip_ltm/manuals/product/tmos-routing-administration-11-6-0/11.html)

Address Resolution Protocol on the BIG-IP system

The BIG-IP system is a multi-layer network device, and as such, needs to perform routing functions.
To do this, the BIG-IP system must be able to nd destination MAC addresses on the network,
based on known IP addresses. The way that the BIG-IP system does this is by supporting Address
Resolution Protocol (ARP), an industry-standard Layer 3 protocol. ARP will keep a table that
contains a one-to-one mapping of known IP addresses to their corresponding MAC addresses on
the systems local area networks.

2.02 - Given a network diagram or ARP command output, determine if ARP resolution was
successful

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-
administration-11-6-0/11.html (https://techdocs.f5.com/kb/en-us/products/big-
ip_ltm/manuals/product/tmos-routing-administration-11-6-0/11.html)

Troubleshooting ARP

What are the states of ARP entries?

When you use the BIG-IP Con guration utility to view the entries in the ARP cache, you can view
the state of each entry.

RESOLVED

Indicates that the system has successfully received an ARP response (a MAC address) for the
requested IP address within two seconds of initiating the request. An entry in a RESOLVED state
remains in the ARP cache until the timeout period has expired.
INCOMPLETE

Indicates that the system has made one or more ARP requests within the maximum number of
requests allowed, but has not yet received a response.

DOWN

Indicates that the system has made the maximum number of requests allowed, and still receives no
response. In this case, the system discards the packet, and sends an ICMP host unreachable
message to the sender. An entry with a DOWN state remains in the ARP cache until the rst of
these events occurs:

Twenty seconds elapse.

The BIG-IP system receives either a resolution response or a gratuitous ARP from the
destination host. (A gratuitous ARP is an ARP message that a host sends without having been
prompted by an ARP request.)
You explicitly delete the entry from the ARP cache.

About BIG-IP responses to ARP requests from rewall devices

The system does not respond to ARP requests sent from any rewall that uses a multicast IP
address as its source address.

About gratuitous ARP messages

When dynamically updating the ARP cache, the BIG-IP system includes not only entries resulting
from responses to ARP requests, but also entries resulting from gratuitous ARP messages.

For security reasons, the system does not fully trust gratuitous ARP entries. Consequently, if there
is no existing entry in the cache for the IP address/MAC pair, and the BIG-IP system cannot verify
the validity of the gratuitous ARP entry within a short period of time, the BIG-IP system deletes the
entry.

2.02 - Given the ARP command output, determine if ARP resolution was successful

ARP resolution

You should be familiar with looking at ARP entries on a BIG-IP system. To see ARP entries on the
BIG-IP enter the following command at the bash prompt:

[root@bigip-a1 (mailto:root%40bigip-a1):Active:Standalone] con g # tmsh show net arp all

Or the following command in the tmsh shell:

root@(bigip-a1)(cfg-sync Standalone)(Active)(/Common)(tmos)# show net arp all

2.02 - Explain the purpose of MAC masquerading

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-
clustering-admin-11-6-0/6.html#unique_1550208857 (https://techdocs.f5.com/kb/en-
us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-admin-11-6-
0/6.html#unique_1550208857)

About MAC masquerade addresses

A MAC masquerade address is a unique, oating Media Access Control (MAC) address that you
create and control. You can assign one MAC masquerade address to each tra c group on a BIG-IP
device. By assigning a MAC masquerade address to a tra c group, you indirectly associate that
address with any oating IP addresses (services) associated with that tra c group. With a MAC
masquerade address per tra c group, a single VLAN can potentially carry tra c and services for
multiple tra c groups, with each service having its own MAC masquerade address.

A primary purpose of a MAC masquerade address is to minimize ARP communications or dropped

packets as a result of a failover event. A MAC masquerade address ensures that any tra c
destined for the relevant tra c group reaches an available device after failover has occurred,
because the MAC masquerade address oats to the available device along with the tra c group.
Without a MAC masquerade address, on failover the sending host must relearn the MAC address
for the newly-active device, either by sending an ARP request for the IP address for the tra c or by
relying on the gratuitous ARP from the newly-active device to refresh its stale ARP entry.

The assignment of a MAC masquerade address to a tra c group is optional. Also, there is no
requirement for a MAC masquerade address to reside in the same MAC address space as that of
the BIG-IP device.

Note: When you assign a MAC masquerade address to a tra c group, the BIG-IP system sends a
gratuitous ARP to notify other hosts on the network of the new address.

Objective - 2.03 Given a scenario, verify tra c is arriving at a destination¶

2.03 - Explain how to acquire packet captures

http://support.f5.com/kb/en-us/solutions/public/0000/400/sol411.html (http://support.f5.com/kb/en-
us/solutions/public/0000/400/sol411.html)

Packet Captures

A packet capture can be one of the most powerful tools that an administrator has at their
command. If you are not used to doing packet captures or have never done one, you should do
them in your lab environment as soon as possible to start becoming pro cient. There are multiple
tools that can be used to do a packet capture such as tcpdump, Wireshark, Windump (Windows
based tcpdump), tshark, etc..

Running tcpdump on a busy system

Important: The BIG-IP system is designed as an application delivery network platform and not as a
packet capture device. If you intend to capture tra c under high load conditions, F5 recommends
mirroring tra c to a dedicated sni ng device.

Running tcpdump on a BIG-IP system is considered best e ort, as it will place more load on the
CPU and may result in inaccuracies in the tcpdump output, such as missed packets or packet
timestamp irregularities. If you run tcpdump on a heavily loaded BIG-IP system, the packet capture
process may not capture all matching tra c, and the statistical values reported by tcpdump may be
inaccurate.

If you run tcpdump on a heavily loaded system, F5 recommends using tcpdump lter expressions
to mitigate the potential for missed packets.

If you are using a packet capture tool other than tcpdump on the Big-IP platform, you will need to
make sure that the system you are running the capture tool on has access to the local network,
which you need to capture. This may mean that you need to be in line between devices or you may
need a network tap or a span port. If you are capturing the tra c on your workstation you will need
to make sure the network card can support promiscuous mode and has the right drivers to support
the capture software.

tcpdump

The tcpdump utility is a command line packet sni er with many features and options. For a full
description, refer to the tcpdump man pages by typing the following command: man tcpdump

You can read the binary output of a tcpdump using a packet analyzer. Some analyzer software can
also be used to capture tra c as well like Wireshark.

Running the tcpdump utility

Following are examples of commands used to run the tcpdump utility:

Selecting an Interface or VLAN

The tcpdump utility is able to sni for packets on only one interface or VLAN. By default, it selects
the lowest numbered interface.

To select an interface, use the -i ag, as follows:

tcpdump -i <interface>

For example:

To tcpdump a speci c interface:

tcpdump -i 2.1

tcpdump -i 1.08
To tcpdump a speci c vlan:

tcpdump -i internal

tcpdump -i external

To tcpdump the management interface:

tcpdump -i eth0

Note: Do not attempt to run tcpdump on an interface that contains a colon.

For example: eth0:mgmt

Disabling name resolution

By default, tcpdump attempts to look up IP addresses and use names, rather than numbers, in the
output. The BIG-IP system must wait for a response from the DNS server, so the lookups can be
time consuming and the output may be confusing.

To disable name resolution, use the -n ag as in the following examples:

tcpdump -n

tcpdump -ni internal

Saving tcpdump output to a le

You can save the tcpdump data to one of the following le formats:

A binary le that contains all the information collected by the tcpdump and is readable by the
tcpdump utility as well as many other tra c analysis packages.

A text le that contains a subset of the full tcpdump data but is readable only as plain text.

When working with F5 Technical Support, you must provide the tcpdump output in the binary le
format.

Binary le

To save the tcpdump output to a binary le, type the following command:

tcpdump -w < lename>

For example: tcpdump -w dump1.bin

Note: The tcpdump utility does not print data to the screen while it is capturing to a le. To stop the
capture, press CTRL-C.

Text le

To save the tcpdump output to a text le, type the following command:

tcpdump >< lename>

For example: tcpdump >dump1.txt

Reading tcpdump binary le output

To read data from a binary tcpdump le (that you saved by using the tcpdump -w command), type
the following command:

tcpdump -r < lename>

For example: tcpdump -r dump1.bin

In this mode, the tcpdump utility reads stored packets from the le, but otherwise operates just as
it would if it were reading from the network interface. As a result, you can use formatting
commands and lters.

Beginning in BIG-IP 11.2.0-HF3, 11.2.1-HF3, and 11.3.0, a pseudo header which includes the following
parameters is added to the start of each binary tcpdump capture:

The tcpdump command syntax used, including all options

Version of software

Hostname of the system

Platform ID

Product

Filters

The tcpdump utility allows you to use lters to, among other things, restrict the output to speci ed
addresses, ports, and tcp ags.

Filtering on a host address

To view all packets that are traveling to or from a speci c IP address, type the following command:

tcpdump host <IP address>

For example: tcpdump host 10.90.100.1

To view all packets that are traveling from a speci c IP address, type the following command:

tcpdump src host <IP address>

For example:

tcpdump src host 10.90.100.1

To view all packets that are traveling to a particular IP address, type the following command:

tcpdump dst host <IP address>

For example:

tcpdump dst host 10.90.100.1

Filtering on a port
To view all packets that are traveling through the BIG-IP system and are either sourced from or
destined to a speci c port, type the following command:

tcpdump port <port number>

For example: tcpdump port 80

To view all packets that are traveling through the BIG-IP system and sourced from a speci c port,
type the following command:

tcpdump src port<port number>

For example: tcpdump src port 80

To view all packets that are traveling through the BIG-IP system and destined to a speci c port,
type the following command:

tcpdump dst port <port number>

For example: tcpdump dst port 80

Filtering on a tcp ag

To view all packets that are traveling through the BIG-IP system that contain the SYN ag, type the
following command:

tcpdump ‘tcp[tcp ags] & (tcp-syn) != 0’

To view all packets that are traveling through the BIG-IP system that contain the RST ag, type the
following command:

tcpdump ‘tcp[tcp ags] & (tcp-rst) != 0’

2.03 - View a packet capture and identify source and destination

https://bencane.com/2014/10/13/quick-and-practical-reference-for-tcpdump/
(https://bencane.com/2014/10/13/quick-and-practical-reference-for-tcpdump/)

https://www.tcpdump.org/manpages/tcpdump.1.html
(https://www.tcpdump.org/manpages/tcpdump.1.html)

Packet capture data le structure

When looking through a packet capture from a tool like tcpdump, you should be familiar with the
format which the output data is placed into the capture by the tool.

If you are trying to look for a particular conversation between two systems, you are looking for the
systems IP addreses sending and receiving packets between each other.

The tcpdump tool will write a le listing out each packet as it is captured. Each capture packet line
item will include a timestamp, sender IP, sender port, receiver IP, receiver port and ags etc.
SrcIP.port > dstIP.port: Flags [tcp ags], seq data-seqno, ack ackno, win window, urg urgent, options
[opts], length len

You can nd the start of a conversation between two systems by looking for the SYN Flag. First a
host, such as your computer, initiates a TCP connection by providing a TCP SYN packet to the
destination host (let’s just say it’s a le sharing server for this example). After the server receives
the TCP SYN it returns a packet in response with SYN ACK. Now, once your computer receives the
SYN ACK, it will send out one more packet to establish the connection which contains ACK.

2.03 - Interpret statistics to show tra c ow

https://techdocs.f5.com/content/kb/en-us/products/big-ip_ltm/manuals/product/ltm-
implementations-13-1-0/_jcr_content/pdfAttach/download/ le.res/BIG-
IP_Local_Tra c_Manager__Implementations.pdf (https://techdocs.f5.com/content/kb/en-
us/products/big-ip_ltm/manuals/product/ltm-implementations-13-1-
0/_jcr_content/pdfAttach/download/ le.res/BIG-IP_Local_Tra c_Manager__Implementations.pdf)

Tra c ow in statistics

The BIG-IP collects statistics and allows you to review them in the GUI or CLI. In the GUI the
information can be found in Statistics > Module Statistics > Local Tra c. At a high level these
statistics can re ect that tra c is or is not reaching a certain destination. For example, if tra c is
coming into a virtual server and being sent to a pool for load balancing, you may want to see if the
tra c is being sent across all of the pool members e ectively.

Screen shot of virtual server tra c being re ected in the statistics on BIG-IP:
Screen shot of pool tra c being re ected in the statistics on BIG-IP and can be expanded to show
the pool members connection information:

Objective - 2.04 Given a scenario, verify Layer 1 connectivity¶

2.04 - Given an exhibit of the front ethernet panel, explain why there is an imbalance in link use
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/platform-i2000-
i4000/1.html#guid-0f2cb19a-9 1-4583-9f0a-0f3c2cc04a88 (https://techdocs.f5.com/kb/en-
us/products/big-ip_ltm/manuals/product/platform-i2000-i4000/1.html#guid-0f2cb19a-9 1-4583-
9f0a-0f3c2cc04a88)

Front Panel Link Status

Link status can be determined from the front panel LEDs.

Network Interface LED Behavior

The appearance and behavior of the network interface LEDs on the platform indicate network
tra c activity, interface speed, and interface duplexity.

SFP/SFP+ port LED behavior

The appearance and behavior of the SFP/SFP+ port LEDs indicate network tra c activity, interface
speed, and interface duplexity.

State Description
o (not lit) No link.
amber solid Linked at 1GbE.
amber blinking Link is actively transmitting or receiving data at 1GbE.
green solid Linked at 10GbE.
green blinking Link is actively transmitting or receiving data at 10GbE.

2.04 - Interpret ifcon g output (interface bandwidth)

https://en.wikipedia.org/wiki/Ifcon g (https://en.wikipedia.org/wiki/Ifcon g)

Ifcon g output

You can read up on Ifcon g in many locations on the internet and I am including a link to Wikipedia,
but essentially ifcon g is a common Linux command line tool it has been replaced by the IP
command in modern Linux distributions. It can be used to set-up (con gure) any/all the network
interfaces as well as look at interface statistics. There is a great amount of information that can be
derived from the output of the tool like MAC address, MTU size, IP address, transmit and receive
errors, etc..

If you use the ifcon g command without any parameters, it will show you the interface details from
all of the active network interfaces. From this information, you can determine the amount of data
that has transgressed an interface since it was enabled. This information can give you an idea of
the bandwidth utilization, however understanding the current interface bandwidth is not as simple
as adding the values of the TX Bytes and the RX Bytes together.

Since the TX and RX data counters continue to grow as the interface passes tra c, the values
being displayed are over a period of time that started when the interface was last enabled. There is
no ability to clear the counters in ifcon g without an interruption of service. So, to determine
current bandwidth safely you will need to run the date command for the system time and the
ifcon g command to gather the TX and RX values then do it all for a second time and do some
math…

Add the TX and RX vales from the rst ifcon g execution and add the TX and RX values from the
second ifcon g execution. Subtract the rst value from the second value. This will give you the
amount of data that transgressed the interface between the 2 ifcon g executions. Remember that
the data is displayed in Bytes, so your results are in MB not Mb. Then subtract the rst date value
from the second date value to see roughly how long it took the calculated data to pass through
interface. Then divide the amount of calculated data by the number of calculated seconds and you
will have a rough per second bandwidth value.

Example of part of the output from an ifcon g command execution on a BIG-IP:

2.04 - Explain potential L1 failure modes (duplex settings, cable out of speci cation)

Physical Layer (Layer 1) Failures

Physical layer or Layer 1 failures can be caused by many di erent problems from a simple
miscon guration or a hardware/infrastructure failure. Interface con gurations like speed or duplex
mismatch can be a failure due to auto-negotiate not working correctly or a mistake in manual
con guration on interfaces at either end of the connection. This may result in a loss of packets in
higher volume networks, collisions and or duplex errors. Interfaces may not be enabled in the
con guration of the software causing interfaces to not respond at all.

Hardware and/or infrastructure failures can be caused by many di erent issues. Everything from
power outages, power cycled devices, hardware failures, faulty SFP or built-in interface,
disconnected cables, broken cabling, cabling that is out of TIA speci cations, EMI and so on.
Hardware failures usually result in a complete loss of connectivity but can sometimes cause errors
to be logged on the actual system or in neighboring device logs.
 Previous (module1.html) Next  (module3.html)

ABOUT F5
Corporate Information (https://www.f5.com/company)
Newsroom (https://www.f5.com/company/news)
Investor Relations (https://www.f5.com/company/investor-relations)
MYF5 (https://f5.com/myf5)
Contact Information (https://www.f5.com/company/contact)
Certi cations (https://www.f5.com/certi cations)

EDUCATION
Training (/services/training)
Certi cation (/services/certi cation)
LearnF5 (https://account.f5.com/learnf5/signin)
Free Online Training (https://f5.com/education/training/free-courses)

F5 SITES
F5.com (https://www.f5.com)
DevCentral (https://devcentral.f5.com/)
Support Portal (https://support.f5.com/)
Partner Central (https://partners.f5.com/)
F5 Labs (https://www.f5.com/labs)

SUPPORT TASKS
Read Support Policies (https://www.f5.com/services/support/support-o erings/support-policies)
Create Service Request (https://support.f5.com/csp/my-support/service-request)
Leave feedback [+] (https://support.f5.com/csp/site-feedback)

CONNECT WITH US
  (//twitter.com/f5networks)  (//www.linkedin.com/companies/f5-networks)
 (//www.facebook.com/f5networksinc)  (//www.youtube.com/f5networksinc)
 (https://devcentral.f5.com)

©2020 F5, Inc. All rights reserved. | Policies (https://www.f5.com/company/policies) | Privacy Policy

(https://www.f5.com/company/policies/privacy-policy) | Terms of Use

(https://www.f5.com/company/policies/terms-of-use) | Trademarks

(https://www.f5.com/company/policies/trademarks) | Cookie Preferences