Archive for November, 2007

Switchport Configurations Explained

November 27th, 2007 • Brad Hedlund • 0 comments • Related • Filed Under

It always helps me to think of the English translation when trying to memorize and understand some the Cisco IOS settings I think are important.

Here are some Cisco IOS switchport configurations translated into English:

‘switchport mode trunk‘ says: “Always trunk on this end, and I will send DTP to attempt to negotiate a trunk on the other end.”

‘switchport nonegotiate‘ says: “Do not send or respond to DTP from this end. Disable all DTP on this port.” (Best used on user access ports, when trunking to non-Cisco switches, when trunking to a router1, or if you are paranoid about fast convergence2)

VLAN Trunking using IEEE 802.1Q

November 27th, 2007 • Brad Hedlund • 0 comments • Related • Filed Under

IEEE 802.1Q (sometimes referred to as 1Q or DOT1Q) is a industry standards based implementation of carring traffic for multiple VLANs on a single trunking interface between two Ethernet switches. 802.1Q is for Ethernet networks only.

Unlike ISL , 802.1Q does not encapsulate the original Ethernet frame.

For Ethernet V2 frames, 802.1Q inserts a new 4-byte field between the SA and TYPE fields of the original Ethernet frame. Since the addition of this new DOT1Q field changes the original frame, 802.1Q also recomputes and rewrites the original 4-byte FCS at the end of the frame.
802.1Q Header Insertion into Ethernet II frame (click image to enlarge)
802.1Q header

VLAN Trunking using ISL

November 26th, 2007 • Brad Hedlund • 3 comments • Related • Filed Under

Inter-Switch Link (ISL) is a Cisco specific implementation of trunking multiple VLANs between two Cisco switches where a single interface will carry traffic for more than one VLAN. ISL was designed to work with Ethernet, FDDI, Token Ring, and ATM.

ISL completely encapsulates the original Ethernet frame by adding a new 26 byte header and new 4 byte FCS trailer. The new ISL header contains a VLAN ID field and QoS priority information (among other things).

ISL Header (click image to enlarge)

ISL HEADER

Things to know about VTP

November 21st, 2007 • Brad Hedlund • 0 comments • Related • Filed Under

Some notes about VTP (VLAN Trunking Protocol):

  • Cisco switches running Cisco IOS store VTP and VLAN information in a separate database stored in Flash, in file called vlan.dat.
  • Cisco switches running CatOS store VTP and VLAN information in the main switch configuration file, stored in NVRAM.
  • VTP information is only transmitted over trunk ports.
  • A VTP client does not need a VTP domain name to be configured to learn VLANs. If the domain name is left blank it will configure itself with the domain name learned from the first advertisement from the VTP server.
  • A VTP advertisement contains the VLANs configured in the domain that are allowed on the trunk, the VTP domain name, and the VTP configuration revision number.
  • If the revision number received in a VTP advertisement is greater than the current stored revision number, the switch will accept the new configuration and overwrite its existing vlan.dat file with the newly received VLAN configuration.

Identifying Ethernet Multicast

November 21st, 2007 • Brad Hedlund • 0 comments • Related • Filed Under

Just like there are 3 different Ethernet header types, there are also 3 different types of Ethernet addresses:

  • Unicast
  • Broadcast
  • Multicast

A unicast frame contains the unique MAC address of the destination receiver. A broadcast frame contains all binary 1’s as the destination address (FFFF.FFFF.FFFF). A multicast frame contains the unique multicast MAC address of an application, protocol, or datastream.

Why is it important to be able to distinguish between the 3 types of Ethernet address type? In an Ethernet switch, each of the three are treated differently.

Identifying Ethernet Header Types

November 19th, 2007 • Brad Hedlund • 1 comment • Related • Filed Under

There are 3 different Ethernet Header types defined by the IEEE and in use today. So, one question comes to mind: When a Ethernet receiver receives a frame, how does it know what kind of header it is? After all, if a receiver is unable to properly recognize the header type, it will not be able to properly extract the frame data and send it to the proper upper layer protocol or application.

DSCP Assured Forwarding PHB

November 19th, 2007 • Brad Hedlund • 0 comments • Related • Filed Under

RFC 2597 defines a group of DSCP settings called “Assured Forwarding” Per Hop Behavior (PHB) to be recognized by RFC compliant DSCP routers and switches called DS nodes. The Assured Forwarding PHB class is presented as AF(xy), where x=traffic class, and y=drop precedence. 4 traffic classes, and 3 drop precedences are defined. For example, AF21 = traffic class 2, drop precedence 1. The traffic class values (1-4) have escalating priority values where traffic marked as AF11 has a lower priority than AF41. Conversely, the drop precedence value (1-3) represents an escalating drop preference within the specified class, a descending priorty. For example, traffic marked as AF43 is more likely to be dropped than AF41.

Route Summarization with Alternate Paths

November 19th, 2007 • Brad Hedlund • 0 comments • Related • Filed Under

Route summarization can be a good thing when done correctly. By summarizing a group of specific routes into one larger summarized (aggregate) route you can greatly improve the stability of the internetwork routing protocol. When a router advertises a summary it hides link failures and instabilities behind the summary from being seen by the rest of the routers in the network receiving the summary. This hiding behavior prevents uneccessary routing protocol convergence and keeps the internetwork stable if a routing loop or flapping link is affecting a peripheral area of the network. However, as with most good things, there are trade-offs. When we use summarization we are trading network stability for routing accuracy. If done incorrectly, route summarization can prevent a network from converging properly, create black holes, and cause sub-optimal routing conditions. Configuring route summarization can get particularly tricky where there are one or more alternate paths to a summarized destination.

Here are two common mistakes when implementing route summarization with alternate paths:

  1. Using alternate paths to bypass a point of summarization.
  2. Specfic routes leaking out of the summarized area from an alternate path.