Tag Archives: ccie

VLAN Trunking Protocol (VTP) Version 3

CCIE Security, , , , ,

VTP

In this Nugget, let’s make sure we are up to speed on the basics of VTP version 3 for a variety of Cisco Certifications, including foremost on my mind, the CCIE Security Written.

VTP v3 does everything that your older versions 1 and 2 can do, plus a lot more. Here is a summary of those additional features:

  • Enhanced authentication—in VTP version 3, you can configure the authentication password to be hidden using the vtp password command. When you configure the authentication password to be hidden, it does not appear in plain text in the configuration. Instead, the secret associated with the password is saved in hexadecimal format in the running configuration.
  • The extended range VLANs and private VLAN features are fully supported!
  • VTP v3 supports the synchronization of remote-SPAN VLANs.
  • VTP v3 supports MST database propagation finally. This is done separately from the VLAN database.
  • VTP status is made up of primary and secondary servers. You use the primary status only when you need to make changes to the VLAN database. By default, your switches come up as secondary servers.
  • To communicate across a VTP domain of version 1 or 2, that domain must be configured in transparent mode.
  • VTP v3 can be configured on and off on a global or per-trunk basis.

Here is a look at a sample configuration:

vtp domain MYDOMAIN
vtp version 3
vtp primary
vlan 100
!
vtp mode server mst
exit
vtp primary mst

The Mechanics of IPv4 Fragmentation

CCIE Security, , ,

Apartment-Audience-Fragmentation

It is important that we understand IPv4 fragmentation as we study for many Cisco and related certifications.

Remember that the IPv4 header has several fields and flags within fields that are critical to this process. This article will review the process and will also point out these important values in the IPv4 header that are critical to the process.

When the sending router in the IPv4 network sees the MTU cannot accommodate the packet size, it will fragment the packet. The key to this process is the fact that the receiving system must be provided with the appropriate information in order for it to perform the reassembly.

The first field that is critical is the Total Length field in the IPv4 header. As you might guess, after the fragmentation, this value indicates the total length of the fragment.

A unique identifier is assigned to each message being fragmented. This value is placed in the Identification field in the IPv4 header of each fragment sent. The Identification field is 16 bits wide, so a total of 65,536 different identifiers can be used. The source device decides on the specific method for ensures each ID value is unique.

Another key value in the header that is used is the More Fragments flag. This flag is set to a 1 for all fragments except the last one, which is set to 0. When the fragment with a value of 0 in the More Fragments flag is seen, the destination knows it has received the last fragment of the message.

The other critical field is the Fragment Offset field. This field solves the problem of sequencing fragments by indicating to the recipient device where in the overall message each particular fragment should be placed. The field is 13 bits wide, so the offset can be from 0 to 8191. Fragments are specified in units of 8 bytes, which is why fragment length must be a multiple of 8.

While the above recaps what is required for the fragmentation process, there are some other values in the header that are related to fragmentation. Let’s quickly review those:

  • The Copied option – if a packet containing options must be fragmented, some of the options may be copied to each of the fragments – this is controlled by the Copied setting in each option field.
  • The Don’t Fragment flag – this flag can be set to 1 by a transmitting device to specify that a datagram not be fragmented in transit. This is often also for testing the maximum transmission unit (MTU) of a link.