Jonathan's CCNP Blog

My CCNP track commences...

sparky — Mon, 14 Sep 2009 14:15:00 +0100

So, the time has come to look at the CCNP

For the next 15 weeks I'll be looking at the Implementing Secure Converged Wide Area Networks (642-825 ISCW) course.

Again, I'm attending the Cisco Networking Academy in Leeds and I'll be doing each of the 4 courses associated with each of the exams. If you've had trouble getting in to the CCNP then I must recommend that you check out the Cisco Networking Academy its well worth the effort!

During the coming weeks I'll be posting relevant artcles that I find useful as an online record. Make of it what you will, this is for me.

If you're studying for any certification then my best advice would be to book your exam as a priority. That way you have defined target to aim for and you can plan accordingly.

All the best and stay focused.

Erase the Config on a PIX firewall

sparky — Thu, 03 Sep 2009 09:45:00 +0100

Erase the Config on a PIX firewall

pix# write erase
Erase PIX configuration in flash memory? [confirm]
pix# reload
Proceed with reload? [confirm]

Nuff said

I passed!!

sparky — Tue, 25 Aug 2009 11:22:00 +0100

Well, after a year studying the CCNA at the Cisco Networking Academy at Leeds City College I sat the CCNA exam last Monday morning and passed with flying colours!!

On to the CCNP in September starting with the ISCW course.

Configure NAT

sparky — Fri, 07 Aug 2009 08:31:00 +0100

Configuring NAT is covered in this article : Configuring Network Address Translation

How Network Address Translation works

sparky — Fri, 07 Aug 2009 08:28:00 +0100

Introduction to How Network Address Translation Works

Network Address Translation helps improve security by reusing IP addresses. The NAT router translates traffic coming into and leaving the private network.

If you are reading this article, you are most likely connected to the Internet and viewing it at the HowStuffWorks Web site. There's a very good chance that you are using Network Address Translation (NAT) right now.

The Internet has grown larger than anyone ever imagined it could be. Although the exact size is unknown, the current estimate is that there are about 100 million hosts and more than 350 million users actively on the Internet. That is more than the entire population of the United States! In fact, the rate of growth has been such that the Internet is effectively doubling in size each year.

So what does the size of the Internet have to do with NAT? Everything! For a computer to communicate with other computers and Web servers on the Internet, it must have an IP address. An IP address (IP stands for Internet Protocol) is a unique 32-bit number that identifies the location of your computer on a network. Basically, it works like your street address -- as a way to find out exactly where you are and deliver information to you.

When IP addressing first came out, everyone thought that there were plenty of addresses to cover any need. Theoretically, you could have 4,294,967,296 unique addresses (2³²). The actual number of available addresses is smaller (somewhere between 3.2 and 3.3 billion) because of the way that the addresses are separated into classes, and because some addresses are set aside for multicasting, testing or other special uses.

With the explosion of the Internet and the increase in home networks and business networks, the number of available IP addresses is simply not enough. The obvious solution is to redesign the address format to allow for more possible addresses. This is being developed (called IPv6), but will take several years to implement because it requires modification of the entire infrastructure of the Internet.

This is where NAT (RFC 1631) comes to the rescue. Network Address Translation allows a single device, such as a router, to act as an agent between the Internet (or "public network") and a local (or "private") network. This means that only a single, unique IP address is required to represent an entire group of computers.

But the shortage of IP addresses is only one reason to use NAT. In this edition of HowStuffWorks, you will learn more about how NAT can benefit you. But first, let's take a closer look at NAT and exactly what it can do...

What Does NAT Do?

NAT is like the receptionist in a large office. Let's say you have left instructions with the receptionist not to forward any calls to you unless you request it. Later on, you call a potential client and leave a message for that client to call you back. You tell the receptionist that you are expecting a call from this client and to put her through.

The client calls the main number to your office, which is the only number the client knows. When the client tells the receptionist that she is looking for you, the receptionist checks a lookup table that matches your name with your extension. The receptionist knows that you requested this call, and therefore forwards the caller to your extension.

Developed by Cisco, Network Address Translation is used by a device (firewall, router or computer) that sits between an internal network and the rest of the world. NAT has many forms and can work in several ways:

Static NAT - Mapping an unregistered IP address to a registered IP address on a one-to-one basis. Particularly useful when a device needs to be accessible from outside the network.

In static NAT, the computer with the IP address of 192.168.32.10 will always translate to 213.18.123.110.

Dynamic NAT - Maps an unregistered IP address to a registered IP address from a group of registered IP addresses.

In dynamic NAT, the computer with the IP address 192.168.32.10 will translate to the first available address in the range from 213.18.123.100 to 213.18.123.150.

Overloading - A form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address by using different ports. This is known also as PAT (Port Address Translation), single address NAT or port-level multiplexed NAT.

In overloading, each computer on the private network is translated to the same IP address (213.18.123.100), but with a different port number assignment.

Overlapping - When the IP addresses used on your internal network are registered IP addresses in use on another network, the router must maintain a lookup table of these addresses so that it can intercept them and replace them with registered unique IP addresses. It is important to note that the NAT router must translate the "internal" addresses to registered unique addresses as well as translate the "external" registered addresses to addresses that are unique to the private network. This can be done either through static NAT or by using DNS and implementing dynamic NAT.

The internal IP range (237.16.32.xx) is also a registered range used by another network. Therefore, the router is translating the addresses to avoid a potential conflict with another network. It will also translate the registered global IP addresses back to the unregistered local IP addresses when information is sent to the internal network.

The internal network is usually a LAN (Local Area Network), commonly referred to as the stub domain. A stub domain is a LAN that uses IP addresses internally. Most of the network traffic in a stub domain is local, so it doesn't travel outside the internal network. A stub domain can include both registered and unregistered IP addresses. Of course, any computers that use unregistered IP addresses must use Network Address Translation to communicate with the rest of the world.

In the next section we'll look at the different ways NAT can be configured.

NAT Configuration

NAT can be configured in various ways. In the example below, the NAT router is configured to translate unregistered (inside, local) IP addresses, that reside on the private (inside) network, to registered IP addresses. This happens whenever a device on the inside with an unregistered address needs to communicate with the public (outside) network.

An ISP assigns a range of IP addresses to your company. The assigned block of addresses are registered, unique IP addresses and are called inside global addresses. Unregistered, private IP addresses are split into two groups. One is a small group (outside local addresses) that will be used by the NAT routers. The other, much larger group, known as inside local addresses, will be used on the stub domain. The outside local addresses are used to translate the unique IP addresses, known as outside global addresses, of devices on the public network.

IP addresses have different designations based on whether they are on the private network (stub domain) or on the public network (Internet), and whether the traffic is incoming or outgoing.

Most computers on the stub domain communicate with each other using the inside local addresses.
Some computers on the stub domain communicate a lot outside the network. These computers have inside global addresses, which means that they do not require translation.
When a computer on the stub domain that has an inside local address wants to communicate outside the network, the packet goes to one of the NAT routers.
The NAT router checks the routing table to see if it has an entry for the destination address. If it does, the NAT router then translates the packet and creates an entry for it in the address translation table. If the destination address is not in the routing table, the packet is dropped.
Using an inside global address, the router sends the packet on to its destination.
A computer on the public network sends a packet to the private network. The source address on the packet is an outside global address. The destination address is an inside global address.
The NAT router looks at the address translation table and determines that the destination address is in there, mapped to a computer on the stub domain.
The NAT router translates the inside global address of the packet to the inside local address, and sends it to the destination computer.

NAT overloading utilizes a feature of the TCP/IP protocol stack, multiplexing, that allows a computer to maintain several concurrent connections with a remote computer (or computers) using different TCP or UDP ports. An IP packet has a header that contains the following information:

Source Address - The IP address of the originating computer, such as 201.3.83.132
Source Port - The TCP or UDP port number assigned by the originating computer for this packet, such as Port 1080
Destination Address - The IP address of the receiving computer, such as 145.51.18.223
Destination Port - The TCP or UDP port number that the originating computer is asking the receiving computer to open, such as Port 3021

The addresses specify the two machines at each end, while the port numbers ensure that the connection between the two computers has a unique identifier. The combination of these four numbers defines a single TCP/IP connection. Each port number uses 16 bits, which means that there are a possible 65,536 (2¹⁶) values. Realistically, since different manufacturers map the ports in slightly different ways, you can expect to have about 4,000 ports available.

Dynamic NAT and Overloading

Here's how dynamic NAT works:

An internal network (stub domain) has been set up with IP addresses that were not specifically allocated to that company by IANA (Internet Assigned Numbers Authority), the global authority that hands out IP addresses. These addresses should be considered non-routable since they are not unique.
The company sets up a NAT-enabled router. The router has a range of unique IP addresses given to the company by IANA.
A computer on the stub domain attempts to connect to a computer outside the network, such as a Web server.
The router receives the packet from the computer on the stub domain.
The router saves the computer's non-routable IP address to an address translation table. The router replaces the sending computer's non-routable IP address with the first available IP address out of the range of unique IP addresses. The translation table now has a mapping of the computer's non-routable IP address matched with the one of the unique IP addresses.
When a packet comes back from the destination computer, the router checks the destination address on the packet. It then looks in the address translation table to see which computer on the stub domain the packet belongs to. It changes the destination address to the one saved in the address translation table and sends it to that computer. If it doesn't find a match in the table, it drops the packet.
The computer receives the packet from the router. The process repeats as long as the computer is communicating with the external system.

Here's how overloading works:

An internal network (stub domain) has been set up with non-routable IP addresses that were not specifically allocated to that company by IANA.
The company sets up a NAT-enabled router. The router has a unique IP address given to the company by IANA.
A computer on the stub domain attempts to connect to a computer outside the network, such as a Web server.
The router receives the packet from the computer on the stub domain.
The router saves the computer's non-routable IP address and port number to an address translation table. The router replaces the sending computer's non-routable IP address with the router's IP address. The router replaces the sending computer's source port with the port number that matches where the router saved the sending computer's address information in the address translation table. The translation table now has a mapping of the computer's non-routable IP address and port number along with the router's IP address.
When a packet comes back from the destination computer, the router checks the destination port on the packet. It then looks in the address translation table to see which computer on the stub domain the packet belongs to. It changes the destination address and destination port to the ones saved in the address translation table and sends it to that computer.
The computer receives the packet from the router. The process repeats as long as the computer is communicating with the external system.
Since the NAT router now has the computer's source address and source port saved to the address translation table, it will continue to use that same port number for the duration of the connection. A timer is reset each time the router accesses an entry in the table. If the entry is not accessed again before the timer expires, the entry is removed from the table.

In the next section we'll look at the organization of stub domains.

Stub Domains

Look at this table to see how the computers on a stub domain might appear to external networks.

Source Computer	Source Computer's IP Address	Source Computer's Port	NAT Router's IP Address	NAT Router's Assigned Port Number
A	192.168.32.10	400	215.37.32.203	1
B	192.168.32.13	50	215.37.32.203	2
C	192.168.32.15	3750	215.37.32.203	3
D	192.168.32.18	206	215.37.32.203	4

As you can see, the NAT router stores the IP address and port number of each computer in the address translation table. It then replaces the IP address with its own registered IP address and the port number corresponding to the location, in the table, of the entry for that packet's source computer. So any external network sees the NAT router's IP address and the port number assigned by the router as the source-computer information on each packet.

You can still have some computers on the stub domain that use dedicated IP addresses. You can create an access list of IP addresses that tells the router which computers on the network require NAT. All other IP addresses will pass through untranslated.

The number of simultaneous translations that a router will support are determined mainly by the amount of DRAM (Dynamic Random Access Memory) it has. But since a typical entry in the address-translation table only takes about 160 bytes, a router with 4 MB of DRAM could theoretically process 26,214 simultaneous translations, which is more than enough for most applications.

IANA has set aside specific ranges of IP addresses for use as non-routable, internal network addresses. These addresses are considered unregistered (for more information check out RFC 1918: Address Allocation for Private Internets, which defines these address ranges). No company or agency can claim ownership of unregistered addresses or use them on public computers. Routers are designed to discard (instead of forward) unregistered addresses. What this means is that a packet from a computer with an unregistered address could reach a registered destination computer, but the reply would be discarded by the first router it came to.

There is a range for each of the three classes of IP addresses used for networking:

Range 1: Class A - 10.0.0.0 through 10.255.255.255
Range 2: Class B - 172.16.0.0 through 172.31.255.255
Range 3: Class C - 192.168.0.0 through 192.168.255.255

Although each range is in a different class, your are not required to use any particular range for your internal network. It is a good practice, though, because it greatly diminishes the chance of an IP address conflict.

Security and Administration

Implementing dynamic NAT automatically creates a firewall between your internal network and outside networks, or between your internal network and the Internet. NAT only allows connections that originate inside the stub domain. Essentially, this means that a computer on an external network cannot connect to your computer unless your computer has initiated the contact. You can browse the Internet and connect to a site, and even download a file; but somebody else cannot latch onto your IP address and use it to connect to a port on your computer.

In specific circumstances, Static NAT, also called inbound mapping, allows external devices to initiate connections to computers on the stub domain. For instance, if you wish to go from an inside global address to a specific inside local address that is assigned to your Web server, Static NAT would enable the connection.

Static NAT (inbound mapping) allows a computer on the stub domain to maintain a specific address when communicating with devices outside the network.

Some NAT routers provide for extensive filtering and traffic logging. Filtering allows your company to control what type of sites employees visit on the Web, preventing them from viewing questionable material. You can use traffic logging to create a log file of what sites are visited and generate various reports from it.

NAT is sometimes confused with proxy servers, but there are definite differences between them. NAT is transparent to the source and to destination computers. Neither one realizes that it is dealing with a third device. But a proxy server is not transparent. The source computer knows that it is making a request to the proxy server and must be configured to do so. The destination computer thinks that the proxy server IS the source computer, and deals with it directly. Also, proxy servers usually work at layer 4 (transport) of the OSI Reference Model or higher, while NAT is a layer 3 (network) protocol. Working at a higher layer makes proxy servers slower than NAT devices in most cases.

NAT operates at the Network layer (layer 3) of the OSI Reference Model -- this is the layer that routers work at.

A real benefit of NAT is apparent in network administration. For example, you can move your Web server or FTP server to another host computer without having to worry about broken links. Simply change the inbound mapping at the router to reflect the new host. You can also make changes to your internal network easily, because the only external IP address either belongs to the router or comes from a pool of global addresses.

NAT and DHCP (dynamic host configuration protocol ) are a natural fit. You can choose a range of unregistered IP addresses for your stub domain and have the DHCP server dole them out as necessary. It also makes it much easier to scale up your network as your needs grow. You don't have to request more IP addresses from IANA. Instead, you can just increase the range of available IP addresses configured in DHCP to immediately have room for additional computers on your network.

Multi-homing

As businesses rely more and more on the Internet, having multiple points of connection to the Internet is fast becoming an integral part of their network strategy. Multiple connections, known as multi-homing, reduces the chance of a potentially catastrophic shutdown if one of the connections should fail.

In addition to maintaining a reliable connection, multi-homing allows a company to perform load-balancing by lowering the number of computers connecting to the Internet through any single connection. Distributing the load through multiple connections optimizes the performance and can significantly decrease wait times.

Multi-homed networks are often connected to several different ISPs (Internet Service Providers). Each ISP assigns an IP address (or range of IP addresses) to the company. Routers use BGP (Border Gateway Protocol), a part of the TCP/IP protocol suite, to route between networks using different protocols. In a multi-homed network, the router utilizes IBGP (Internal Border Gateway Protocol) on the stub domain side, and EBGP (External Border Gateway Protocol) to communicate with other routers.

Multi-homing really makes a difference if one of the connections to an ISP fails. As soon as the router assigned to connect to that ISP determines that the connection is down, it will reroute all data through one of the other routers.

NAT can be used to facilitate scalable routing for multi-homed, multi-provider connectivity. For more on multi-homing, see Cisco: Enabling Enterprise Multihoming.

Configure DHCP on a Cisco Router

sparky — Fri, 07 Aug 2009 08:20:00 +0100

Configure DHCP on a Cisco Router

Steps are as follows:

1. Define the DHCP address pool,

Router(config)#ip dhcp pool POOLNAME

Router(dhcp-config)#network XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY

where,

XXX.XXX.XXX.XXX is the network address to be used by the DHCP pool

YYY.YYY.YYY.YYY is the subnet mask for the network.

You can replace the subnet mask by a (/PREFIX) to provide the subnet mask.

2. Configure the parameters to be sent to the client,

Router(dhcp-config)#dns-server XXX.XXX.XXX.XXX

To provide the DNS server IP address

Router(dhcp-config)#default-router XXX.XXX.XXX.XXX

To provide the IP address of the default gateway

Router(dhcp-config)#domain-name NAME

To provide the name of the domain of the network (if in a domain environment)

Router(dhcp-config)#netbios-name-server XXX.XXX.XXX.XXX

To provide the IP address of the NetBIOS name server

Router(dhcp-config)#lease DAYS HOURS MINUTES

To define the lease time of the addresses given to the client. You can make it infinite by using this command instead; lease infinite

There is a large group of settings that you can configure to be sent to the clients, and I have only mentioned the most frequently used.

3. Configure the IP addresses to be excluded from the pool. This is usually done to avoid the conflicts caused by the DHCP with servers and printers. Remember to give ALL servers and network printers static IP addresses in the same range of the DHCP pool. And then exclude these addresses from the pool to avoid conflicts.

Router(config)#ip dhcp excluded-address XXX.XXX.XXX.XXX

Use the command in the previous form to excluded a single address. You can repeat it as much as you see fit for the IP addresses you want to exclude. Or,

Router(config)#ip dhcp excluded-address YYY.YYY.YYY.YYY ZZZ.ZZZ.ZZZ.ZZZ

where,

YYY.YYY.YYY.YYY is the start of the range to be excluded from the pool

ZZZ.ZZZ.ZZZ.ZZZ is the end of the range

This way you can exclude a range or ranges of IP addresses and reserve them for static addresses use.

4. Enable the DHCP service in the router

Router(config)#service dhcp

To disable it use

Router(config)#no service dhcp

Usually the DHCP service is enabled by default on your router.

5. Use the following commands to check the DHCP operation on the router:

Router#show ip dhcp binding

This command shows the current bindings of addresses given to clients

Router#show ip dhcp server statistics

This command show the DHCP server statistics.

Router#debug ip dhcp server

This debug command is used to troubleshoot DHCP issues.

Implementation notes:

1. If you have a DHCP server other than the router, and you would like to let the router to forward the DHCP requests from a certain LAN to the DHCP server laying outside that LAN, go to the Ethernet interface that does not have the DHCP server and type the following command:

Router(config-if)#ip helper-address XXX.XXX.XXX.XXX

where XXX.XXX.XXX.XXX is the IP address of the server laying outside this LAN.

2. You can create a DHCP database agent that stores the DHCP binding database. A DHCP database agent is any host, for example, an FTP, TFTP, or RCP server that stores the DHCP bindings database. You can configure multiple DHCP database agents and you can configure the interval between database updates and transfers for each agent. To configure a database agent and database agent parameters, use the following command in global configuration mode:

Router(config)#ip dhcp database url [timeout seconds | write-delay seconds]

An example url is this

ftp://user:password @ 192.168.0.3/router-dhcp (remove the spaces before implementing)

If you choose not to configure a DHCP database agent, disable the recording of DHCP address conflicts on the DHCP server. To disable DHCP address conflict logging, use the following command in global configuration mode:

Router(config)#no ip dhcp conflict logging

3. DHCP service uses port 67 and 68. So, if you are using a firewall, remember to open these ports.

4. To clear DHCP server variables, use the following commands as needed:

Router#clear ip dhcp binding *

If you want to clear a certain binding not all of them, replace the * in the previous command with the IP address to be cleared.

Router#clear ip dhcp server statistics

----------------------------------------
Article courtesy of www.routergeek.com

Quick CatOS Configuration Guide

sparky — Mon, 13 Jul 2009 15:25:00 +0100

Quick CatOS Configuration Guide

Platform: - Cisco 6509 catos
Author: - Surender Singh

Setting the IP address and default gateway of the switch

# set int sc0 {ipaddress} {subnet mask}
# set route default {ipaddress}

For setting the name of ports for each module.

# set port name {mod-num/port-num} {name}

For Setting the port Speed

# set port speed {mod-num/port-num} auto

For setting the port in half duplex or full duplex

# set port duplex {mod-num/port-num} {half/full}

For setting the ports for flow control for controlling the traffic or delay of traffic

# set port flow control {mod-num/port-num} Send ON (the port will send Flow control to far end.)
# set port flow control {mod-num/port-num} Receive ON (the port will require far end to send flow control)

Port Negotiation before establishing a link

1) # Set port negotiation {mod-num/port-num}{enable/disable}
2) #show port

Clear config all will clear out all the config and all ports will collapse into VLAN1 which will cause instability. In order to avoid this all the ports are put into a blocking state.

# set default port status

Configuring Ether Channels

In this all Ethernet links are grouped together to form one Ether Channel. A max of 8 Ether links can join a Admin Group. Port Aggression Protocol communicates by exchanging packets between the ports to establish a link; it adds the Ether channel to a spanning tree as one single bridge port to avoid loops.

# set port channel {mod-num/port-num} {admin-group(1-1024}
# set port chaneel {mod-num/port-num} { auto|desirable}

3) #set port channel all distribution {ipaddress|mac address} {source|destination}
4) # Show port channel

Configuring Spanning Tree Protocol (IEEE 802.1 d)

In a switched network only a single path must exist between two stations .Each vlan has its STP defined.
If multiple patches exists between two stations loops can occur.

STP spans the extended switch network and force certain redundant paths into a standby or blocked state if any of the link goes down then the blocked path comes into forwarding state .All switches participate in a STP by exchanging Bridge protocol data units .the BPDU contains information of the switch ,port mac-address, priority, cost. This is used to elect the root switch.

Enabling STP on VLAN

# Set spantree enable {vlan_num}

Changing the port priority for putting it into forwarding state

# set spantree port priority {mod-num/port-num} {priority}
# set spantree port vlan priority {mod-num/port-num} {priority} {vlan-num}

Changing the port cost

#set spantree port cost {mod-num/port-num} {cost}
#set spantree port vlan cost {mod-num/port-num} {cost} {vlan_num}

Configure a switch for root & secondary root

#set spantree root {Vlans} dia 4
#set spantree root secondary {Vlans} dia 5 hello 1

Disabling Spantree

#set spantree disable

How Port Fast works

By enabling port fast the port does not wait for the STP to converge and always remain in the forwarding state

Portfast BPDU Guard

It can prevent loops by moving a non trunking port into the Errdisable state when a BPDU is received on that port. When this is enabled STP shuts down the port.

Configuring Spatree portfast

#set spantree portfast {mod-num/port-num} enable
#set spantree portfast bpdu-guard enable
#set spantree uplinkfast enable(if the interface goes down between two switches ,uplink fast enables a blocked state interface directly into forwarding state).
#set spantree backbonefast enable (it enables an indirect link into forwarding state).

Configuring VTP

#set VTP domain {name}
#set VTP mode {server|client|transparent}
#set VTP password
#set VTP V2 enable
#set VTP purn eligible {Vlan Range}
#show trunks (verifies that appropriate Vlans are trunked)
#show VTP statistics

Configuring VLAN

#set Vlan {Vlan number (2-1000)} name {name}

VLAN 1 is by default the inband (SC0) interface of a switch ,by which any switch can be accessed without going thru the router.

#set Vlan {vlan number} {mod-num/port-num}

Valid range of Vlans for ISL is 1-1000; valid range for IEEE 802.1q is 0-4095

If non-Cisco devices r connected to Cisco devices thru 802.1q trunks, we must Map 802.1q Vlan numbers greater than 1000 to ISL Vlan numbers .802.1q vlan numbers in the range of 1-1000 r automatically mapped to ISL vlan .If greater than 1000 it has to be mapped manually to be recognized by Cisco switches. Upto 16 802.1q Vlans can be configured to ISL VLANs

#SET Vlan Mapping dot1q {vlan number} ISL {Vlan number}

Trunking (Important)

Configuring an ISL or dot1q trunk

# set trunk {mod-num/port-num} {auto|desirable|ON|OFF} dot1q

Negotiation

#set trunk {mod-num/port-num} desirable (mode) negotiate (dot1q or ISL) (assuming that the end port is in auto mode)

By default all Vlans are allowed when a trunk is set.
To disallow specific trunks

#clear trunk {mod-num/port-num} {vlan range}
# set trunk {mod-num/port-num} {vlan number or range}
# sh trunk {mod-num/port-num}

Disabling Trunk port

#set trunk {mod-num/port-num} OFF (turns trunking OFF on the port)
#clear trunk {mod-num/port-num} (puts the port its default trunking)

GVRP: Generic attribute registration protocol

-------------------------
article courtesy of www.knowurtech.com

VRF - Virtual Routing and Forwarding

sparky — Mon, 13 Jul 2009 09:54:00 +0100

Virtual Routing and Forwarding

Virtual routing and forwarding (VRF) is a technology included in IP
(Internet Protocol) network routers that allows multiple instances of a
routing table to exist in a router and work simultaneously. This
increases functionality by allowing network paths to be segmented
without using multiple devices. Because traffic is automatically
segregated, VRF also increases network security and can eliminate the
need for encryption and authentication. Internet service providers
(ISPs) often take advantage of VRF to create separate virtual private
networks (VPNs) for customers; thus the technology is also referred to
as VPN routing and forwarding.

VRF acts like a logical router, but while a logical router may include
many routing tables, a VRF instance uses only a single routing table.
In addition, VRF requires a forwarding table that designates the next
hop for each data packet, a list of devices that may be called upon to
forward the packet, and a set of rules and routing protocols that
govern how the packet is forwarded. These tables prevent traffic from
being forwarded outside a specific VRF path and also keep out traffic
that should remain outside the VRF path.

Configuring VPN Routing and Forwarding

sparky — Mon, 13 Jul 2009 08:51:00 +0100

Configuring a VRF

Doug Downer
11.01.2005

In a recent tip called Keeping it all separate with VRFs, I started talking about an increasingly common scenario which involves the requirement to separate customers on shared devices using VPN Routing and Forwarding (VRF) instances. VRFs allow us to logically separate L2 and L3 functions for customers which share common network devices. This separation also allows service providers the ability to separate customers on their backbone with other technologies such as MPLS. MPLS is not within the scope of this series so we'll stick to just the VRF for now. In this tip, I'll show you how to configure a VRF using the scenario we looked at before.

Scenario recap

We have been looking at a scenario involving the requirement for two customers (A and B) to be given Internet access from a service provider (you). Because of the relatively small size of the service provider and customer -- one shared network device was installed to support this requirement. At first glance this scenario allows for the networks of Customer A and Customer B to mix together. To prevent that, the service provider puts each customer within a VRF.

Creating the VRF

The actual configuration of a VRF is not a difficult task. There are two main components to a VRF: The route distinguisher and the route target. A route distinguisher (RD) is a number -- which doesn't actually have any real significance other than to help identify a VPN in a provider's network and allow for overlapping IP space. The RD is an 8-byte number with two parts: A 2-byte type field followed by a 6-byte value field. Without going into too much detail, the value field of the RD is most often represented as an autonomous system number (ASN 2 bytes) followed by an arbitrary number (4 bytes) or an IP address (4 bytes) followed by an arbitrary number (2 bytes). You can enter an RD in either of these formats:

16-bit AS number: your 32-bit number
For example, 101:3.

32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.

The route target (RT) indicates the VPN membership of a route and allows VPN routes to be imported or exported into or out of your VRFs. The RT functions a little like a routing policy -- determining how routes are distributed throughout the particular VPN. Like the RD, the RT is 8 bytes in length and can be entered as:

16-bit AS number: your 32-bit number
For example, 101:3.

32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.

Using the example scenario, let's configure two VRFs on the service provider router. Customer A will have an RD of 192.168.1.1:100 and Customer B will have an RD of 192.168.2.1:200

Customer ASP_Router(config)#interface loopback 1 SP_Router(config-if)#description Loopback interface for Customer_A VRF SP_Router(config)#interface g0/0 SP_Router(config-if)#description Connection to the Customer_A router SP_Router(config)#ip vrf Customer_A SP_Router(config-vrf)#rd 192.168.1.1:100 SP_Router(config-vrf)#route-target import 192.168.1.255:100 SP_Router(config-vrf)#route-target export 192.168.1.255:100

Customer BSP_Router(config)#interface loopback 2 SP_Router(config-if)#description Loopback interface for Customer_B VRF SP_Router(config)#interface g0/1 SP_Router(config-if)#description Connection to the Customer_B router SP_Router(config)#ip vrf Customer_B SP_Router(config-vrf)#rd 192.168.2.1:200 SP_Router(config-vrf)#route-target import 192.168.2.255:200 SP_Router(config-vrf)#route-target export 192.168.2.255:200

Assigning the interfaces

Once you have created the VRF you can begin to assign the particular interfaces and start to separate the customers. Notice I did not assign an IP address to the interfaces which are intended to be in the VRF. If you put the IP addresses on prior to putting the interface in the VRF, the IP address will be removed and cause you to have to re-IP the interfaces.

Customer ASP_Router(config)#interface lo1 SP_Router(config-if)#ip vrf forwarding Customer_A SP_Router(config-if)#ip address 192.168.1.1 255.255.255.255 SP_Router(config)#interface g0/0 SP_Router(config-if)#ip vrf forwarding Customer_A SP_Router(config-if)#ip address 10.1.1.1 255.255.255.252

Customer B SP_Router(config)#interface lo2 SP_Router(config-if)#ip vrf forwarding Customer_B SP_Router(config-if)#ip address 192.168.2.1 255.255.255.255 SP_Router(config)#interface g0/1 SP_Router(config-if)#ip vrf forwarding Customer_B SP_Router(config-if)#ip address 10.1.2.1 255.255.255.252

These configurations have modified our picture somewhat. The figure below shows what the things look like now:

You can verify your configurations by using the show ip vrf command:

SP_Router #show ip vrf
Name	Default RD	Interfaces
Customer_A	192.168.1.1:100	Loopback1
		GigabitEthernet0/0
Customer_B	192.168.2.1:200	Loopback2
		GigabitEthernet0/1

Once you have the proper interfaces within the correct VRF, you can begin to establish IP connectivity and routing between the customer routers and the service provider routers.

--------------------------------------

article courtesy of searchenterprisewan.com

Access Control Lists

sparky — Wed, 01 Jul 2009 15:12:00 +0100

Cisco Access Control Lists (ACL)

By Joshua Erdman
Digital Foundation, inc.

The Cisco access control list (ACL) is probably the most commonly used object in the IOS. It is not only used for packet filtering (a type of firewall) but also for selecting types of traffic to be analyzed, forwarded, or influenced in some way.

Access Control List Types

Cisco ACLs are divided into types. Standard IP, Extended IP, IPX, Appletalk, etc. Here we will just go over the standard and extended access lists for TCP/IP.

As you create ACLs you assign a number to each list, however, each type of list is limited to an assigned range of numbers. This makes it very easy to determine what type of ACL you will be working with.

TCP/IP Access Lists

You can have up to 99 Standard IP Access Lists ranging in number from 1 to 99, the Extended IP Access Lists number range is assigned from 100 to 199. The most common use of the Extended IP access list to is create a packet filtering firewall. This is where you specify the allowed destinations of each packet from an allowed source.

Standard IP Access Lists

A Standard Access List only allows you to permit or deny traffic from specific IP addresses. The destination of the packet and the ports involved do not matter.

Here is an example:

access-list 10 permit 192.168.3.0 0.0.0.255

This list allows traffic from all addresses in the range 192.168.3.0 to 192.168.3.255

You can see how the last entry looks similar to a subnet mask, but with Cisco ACLs they use inverse subnet masks. Also realize that by default, there is an implicit deny added to every access list. If you entered the command:
show access-list 10
The output would be:

access-list 10 permit 192.168.3.0 0.0.0.255
access-list 10 deny any

Extended IP Access Lists

Extended ACLs allow you to permit or deny traffic from specific IP addresses to a specific destination IP address and port. It also allows you to specify different types of traffic such as ICMP, TCP, UDP, etc. Needless to say, it is very grangular and allows you to be very specific. If you intend to create a packet filtering firewall to protect your network it is an Extended ACL that you will need to create.

Typically you would allow outgoing traffic and incoming initiated traffic. In other words, you want your users to be able to connect to web servers on the internet for browsing but you do not want anyone on the Internet to be able to connect to your machines. This will require 2 ACLs. One to only limit our users on the company network to only use a web browser (so this will block outgoing FTP, e-mail, Kazaa, napster, online gaming, etc.) The other access-list will only allow incoming traffic from the Internet that has been initiated from a machine on the inside. This is called an established connection. Let's see what our access list would look like for starters:

Assumptions:
internal network: 63.36.9.0

access-list 101 - Applied to traffic leaving the office (outgoing)

access-list 102 - Applied to traffic entering the office (incoming)

ACL 101
access-list 101 permit tcp 63.36.9.0 0.0.0.255 any eq 80

ACL 102
access-list 102 permit tcp any 63.36.9.0 0.0.0.255 established

ACL 101

As you can see, ACL 101 says to permit traffic originating from any address on the 63.36.9.0 network. The 'any' statement means that the traffic is allowed to have any destination address with the limitation of going to port 80 (which is the web port for HTTP). This is still only half of the solution. If you only use this access list you have totally accomplished limiting your users from doing nothing more on the internet than just be able to browse from website to website. However, you have taken no action on the incoming trafic. The Internet still has full access to all the IPs and all the ports. This leaves you vulnerable.

ACL 102

Since you only want your users to be able to browse the Internet, you must block all incoming traffic accept for the established connections in which the websites are replying to a computer on your network. Doing this is impossible unless you use the 'established' command.

Now that we are familiar with the 'established' command, ACL 102 simply states to permit established traffic from anywhere to all computers within our 63.36.9.0 network.

You may ask why access-list 102 does not read:

access-list 102 permit tcp any any established

In this situation this works just as good, but because it is not as specific, it is considered a hole or an area of vulnerability (especially if you ever got another block of IP addresses).

Activating an Access Control List

Now that you have created these ACLs they are useless until you declare them to be used in some way. As of right now they are an inactive list doing nothing. Our next article will cover applying ACLs on interfaces and how to specify if the ACL is for incoming or outgoing traffic on that interface.

We will apply our ACLs to the serial (T1) interface to protect our network and to limit our user's Internet access to just web browsing.

Before we do that, we need to add one more entry to access-list 101 to allow HTTPS for web browsing. If you have a clue about TCP/IP you know that web browsing (HTTP) is done on port 80 and that web browsing securely (HTTPS) is done on port 443. So we also need to open port 443 if any user is to be able to let's say place an online order or check their bank account. Typically, the web page where you enter your personal information should be secure and thus requires the use of HTTPS.

The line we add is very similar to the line that is already in access list 101. You probably already have it figured out by now:

access-list 101 tcp permit 63.36.9.0 0.0.0.255 any eq 443

Now that our ACLs are complete, here is how we apply them to an interface.

In or Out

We first must decide the traffic that we are filtering is going in or out. Our users trying to access websites on the Internet is a good example of traffic going OUT from our business. Receiving e-mails from the Internet is a good example of traffic coming IN to our business. But depending on the interface you want to apply the ACLs to, will determine the direction of the traffic.

Take for example a router with 2 interfaces. It has a serial port, ser0/0, (AKA T-1 connection) and an ethernet port, eth0/0. The Internet traffic coming IN to our office is going IN the ser0/0 interface, but is also going OUT the eth0/0 interface to reach the office network. See how that works?

Now you have all kinds of options as to where you put your restrictions on your serial ports or your ethernet ports and this is just with a simple example!

For now we will activate the access lists on the serial port so the point of views (POV) are the same. Traffic coming IN the office is also going IN the serial port and traffic going OUT of the office is going OUT that same serial port.

Applying Access Lists

Finally the instructions you all have been waiting for! Make sure you are in enabled mode. Then use the command below:

conf t
int ser0/0
access-group 101 out
access-group 102 in

See how you must be in configuration mode of the interface to apply an access-list? Remember that you can only apply ONE ACL in each direction of an interface.

Editing and adding ACLs

If you need to add more permissions, you must add to the ACL you have already created. Any lines you add will be appended to at the bottom of the list.

How I keep track of all the ACLs I use is by keeping each one in a separate text file. I then make changes to the text file then I delete the whole access-list from the router's memory (running-config) and then copy and paste the new list each time I make updates.

Clue: There is no way to remove a single line from an ACL. Instead it is better to copy the whole ACL into a text editor and remove the offending line. Then remove the whole ACL from the router's memory (see below) and then add the modified ACL.

Removing ACLs

To remove an ACL from the router, be sure you are in enabled mode. Then use the command:

no access-list <list number>

That is all there is to it.

Clue: When you delete an access-list that is currently being applied to an interface, all traffic that is to be filtered through the specified access list will be allowed until the access list is reinstated or a new access-list is specified in the access-group command.

Advanced ACLs'

We will create an ACL that allows the users in our office to access the internet using a range of common ports. As you can see in the example above, we have been just specifying individual ports.

Port Ranges

In the example you see the letters 'eq' before the port is declared. This is short for 'equal to'. Other ones include:

gt - Greater Than followed by the port number.
lt - Less Than followed by the port number
range - To specify an inclusive port range
after the keyword range put in the first port in the range followed by a space and then the last port in the range.

Commenting

As your access lists grow and become more complex it is a great idea to add comments. Adding a comment is as simple as beginning the comment line with an exclamation point.

Filter Masks

First be sure that you brush up on your binary and read our article on TCP/IP Addressing and Calculating Subnet Masks. You must first have a good grasp of the use of binary to calculate subnet masks.

Using filter masks allow you to group IP Addresses together instead of having to specify each IP address individually. So for example, if you were to have five servers and all their addresses were 10.10.10.1 - 10.10.10.5 it is easy to grant or deny access to all 5 with only one line in the access list. If you have the addresses scattered you either have to make 5 separate entries or change the IPs of the servers.

The way you specify a group of IP addresses is very similar to how a subnet mask is used, except that the 1s and 0s are inversed. For example, all the web servers on our sample network fall in the subnet of 10.10.10.1 - 10.10.10.15 (if this was a subnet mask it would be: 255.255.255.240). We would never assign the servers this subnet mask because we want the workstations (using addresses 10.10.10.65-10.10.10.254) to talk directly to the servers. This prevents our router from being taxed. But now that we know the equivalent subnet mask for this ip block of servers, we can easily create the access-list filter mask, which is 0.0.0.15 As I mentioned earlier the filter mask is the opposite of the subnet mask. Here is how it looks in binary:

    128 64 32 16|8 4 2 1
SM    1  1  1  1|0 0 0 0=240
FM    0  0  0  0|1 1 1 1=15

Clue: If you put the servers and workstations on 2 different network blocks the router will have an insane amount of traffic to route. Definitely not a good idea.

With filter masks you can almost easily guess the correct value as long as the numbers in the filter mask are a power of 2 minus 1. IFor example, I know that my web servers aregrouped in the first 15 IP addresses. The smallest power of two that 15 can fit into is 16. Then subtract 1 and my filter mask is 0.0.0.15

Filter Masks in Access Lists

So if I wanted to permit all incoming web traffic requests to my web servers (To prevent any Internet access to Rogue web servers on employee's workstations). I would enter this line in the access list:

!Permit HTTP port 80 traffic
access-list 102 permit tcp any 10.10.10.0 0.0.0.15 eq 80

!Permit HTTPS port 443 traffic
access-list 102 permit tcp any 10.10.10.0 0.0.0.15 eq 443

Many, Many ACLs

When I last worked for an ISP we had several connections terminating into one router. To make things as secure as possible I made 2 access lists for each interface. One for incomming traffic and one for outgoing. Keeping track of all this quickly became a nightmare. What I did to help was to have a notepad text file for each access list. At the top of each access list was the function of each access list, a description of the lastest modifications, modification date and who made the modification.

--------------------------------

Article taken from - www.networkclue.com

Switch Port Analysising - SPAN

sparky — Wed, 01 Jul 2009 14:54:00 +0100

Overview of SPAN

What is SPAN and why is it needed? The SPAN feature was introduced on switches because of a fundamental difference that switches have with hubs. When a hub receives a packet on one port, the hub sends out a copy of that packet on all ports except on the one where the hub received the packet. After a switch boots, it starts to build up a Layer 2 forwarding table on the basis of the source MAC address of the different packets that the switch receives. After this forwarding table is built, the switch forwards traffic that is destined for a MAC address directly to the corresponding port.

For example, if you want to capture Ethernet traffic that is sent by host A to host B, and both are connected to a hub, just attach a sniffer to this hub. All other ports see the traffic between hosts A and B:

On a switch, after the host B MAC address is learned, unicast traffic from A to B is only forwarded to the B port. Therefore, the sniffer does not see this traffic:

In this configuration, the sniffer only captures traffic that is flooded to all ports, such as:

Broadcast traffic
Multicast traffic with CGMP or Internet Group Management Protocol (IGMP) snooping disabled
Unknown unicast traffic

Unicast flooding occurs when the switch does not have the destination MAC in its content-addressable memory (CAM) table. The switch does not know where to send the traffic. The switch floods the packets to all the ports in the destination VLAN.

An extra feature is necessary that artificially copies unicast packets that host A sends to the sniffer port:

In this diagram, the sniffer is attached to a port that is configured to receive a copy of every packet that host A sends. This port is called a SPAN port. The other sections of this document describe how you can tune this feature very precisely in order to do more than just monitor a port.

SPAN Terminology

Ingress traffic—Traffic that enters the switch.
Egress traffic—Traffic that leaves the switch.
Source (SPAN) port —A port that is monitored with use of the SPAN feature.
Source (SPAN) VLAN —A VLAN whose traffic is monitored with use of the SPAN feature.
Destination (SPAN) port —A port that monitors source ports, usually where a network analyzer is connected.
Reflector Port —A port that copies packets onto an RSPAN VLAN.
Monitor port—A monitor port is also a destination SPAN port in Catalyst 2900XL/3500XL/2950 terminology.

Local SPAN—The SPAN feature is local when the monitored ports are all located on the same switch as the destination port. This feature is in contrast to Remote SPAN (RSPAN), which this list also defines.
Remote SPAN (RSPAN)—Some source ports are not located on the same switch as the destination port. RSPAN is an advanced feature that requires a special VLAN to carry the traffic that is monitored by SPAN between switches. RSPAN is not supported on all switches. Check the respective release notes or configuration guide to see if you can use RSPAN on the switch that you deploy.
Port-based SPAN (PSPAN)—The user specifies one or several source ports on the switch and one destination port.
VLAN-based SPAN (VSPAN)—On a particular switch, the user can choose to monitor all the ports that belong to a particular VLAN in a single command.
ESPAN—This means enhanced SPAN version. This term has been used several times during the evolution of the SPAN in order to name additional features. Therefore, the term is not very clear. Use of this term is avoided in this document.
Administrative source—A list of source ports or VLANs that have been configured to be monitored.
Operational source—A list of ports that are effectively monitored. This list of ports can be different from the administrative source. For example, a port that is in shutdown mode can appear in the administrative source, but is not effectively monitored.

Further details available at - http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml

Frame Relay

sparky — Mon, 01 Jun 2009 08:30:00 +0100

Frame Relay

Introduction

Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI reference model. Frame Relay originally was designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well. This chapter focuses on Frame Relay's specifications and applications in the context of WAN services.

Frame Relay is an example of a packet-switched technology. Packet-switched networks enable end stations to dynamically share the network medium and the available bandwidth. The following two techniques are used in packet-switching technology:

•Variable-length packets

•Statistical multiplexing

Variable-length packets are used for more efficient and flexible data transfers. These packets are switched between the various segments in the network until the destination is reached.

Statistical multiplexing techniques control network access in a packet-switched network. The advantage of this technique is that it accommodates more flexibility and more efficient use of bandwidth. Most of today's popular LANs, such as Ethernet and Token Ring, are packet-switched networks.

Frame Relay often is described as a streamlined version of X.25, offering fewer of the robust capabilities, such as windowing and retransmission of last data that are offered in X.25. This is because Frame Relay typically operates over WAN facilities that offer more reliable connection services and a higher degree of reliability than the facilities available during the late 1970s and early 1980s that served as the common platforms for X.25 WANs. As mentioned earlier, Frame Relay is strictly a Layer 2 protocol suite, whereas X.25 provides services at Layer 3 (the network layer) as well. This enables Frame Relay to offer higher performance and greater transmission efficiency than X.25, and makes Frame Relay suitable for current WAN applications, such as LAN interconnection.

Frame Relay Standardization

Initial proposals for the standardization of Frame Relay were presented to the Consultative Committee on International Telephone and Telegraph (CCITT) in 1984. Because of lack of interoperability and lack of complete standardization, however, Frame Relay did not experience significant deployment during the late 1980s.

A major development in Frame Relay's history occurred in 1990 when Cisco, Digital Equipment Corporation (DEC), Northern Telecom, and StrataCom formed a consortium to focus on Frame Relay technology development. This consortium developed a specification that conformed to the basic Frame Relay protocol that was being discussed in CCITT, but it extended the protocol with features that provide additional capabilities for complex internetworking environments. These Frame Relay extensions are referred to collectively as the Local Management Interface (LMI).

Since the consortium's specification was developed and published, many vendors have announced their support of this extended Frame Relay definition. ANSI and CCITT have subsequently standardized their own variations of the original LMI specification, and these standardized specifications now are more commonly used than the original version.

Internationally, Frame Relay was standardized by the International Telecommunication Union—Telecommunications Standards Section (ITU-T). In the United States, Frame Relay is an American National Standards Institute (ANSI) standard.

Frame Relay Devices

Devices attached to a Frame Relay WAN fall into the following two general categories:

•Data terminal equipment (DTE)

•Data circuit-terminating equipment (DCE)

DTEs generally are considered to be terminating equipment for a specific network and typically are located on the premises of a customer. In fact, they may be owned by the customer. Examples of DTE devices are terminals, personal computers, routers, and bridges.

DCEs are carrier-owned internetworking devices. The purpose of DCE equipment is to provide clocking and switching services in a network, which are the devices that actually transmit data through the WAN. In most cases, these are packet switches. Figure 10-1 shows the relationship between the two categories of devices.

Figure 10-1 DCEs Generally Reside Within Carrier-Operated WANs

The connection between a DTE device and a DCE device consists of both a physical layer component and a link layer component. The physical component defines the mechanical, electrical, functional, and procedural specifications for the connection between the devices. One of the most commonly used physical layer interface specifications is the recommended standard (RS)-232 specification. The link layer component defines the protocol that establishes the connection between the DTE device, such as a router, and the DCE device, such as a switch. This chapter examines a commonly utilized protocol specification used in WAN networking: the Frame Relay protocol.

Frame Relay Virtual Circuits

Frame Relay provides connection-oriented data link layer communication. This means that a defined communication exists between each pair of devices and that these connections are associated with a connection identifier. This service is implemented by using a Frame Relay virtual circuit, which is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN).

Virtual circuits provide a bidirectional communication path from one DTE device to another and are uniquely identified by a data-link connection identifier (DLCI). A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network. This capability often can reduce the equipment and network complexity required to connect multiple DTE devices.

A virtual circuit can pass through any number of intermediate DCE devices (switches) located within the Frame Relay PSN.

Frame Relay virtual circuits fall into two categories: switched virtual circuits (SVCs) and permanent virtual circuits (PVCs).

Switched Virtual Circuits

Switched virtual circuits (SVCs) are temporary connections used in situations requiring only sporadic data transfer between DTE devices across the Frame Relay network. A communication session across an SVC consists of the following four operational states:

•Call setup—The virtual circuit between two Frame Relay DTE devices is established.

•Data transfer—Data is transmitted between the DTE devices over the virtual circuit.

•Idle—The connection between DTE devices is still active, but no data is transferred. If an SVC remains in an idle state for a defined period of time, the call can be terminated.

•Call termination—The virtual circuit between DTE devices is terminated.

After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged. It is expected that SVCs will be established, maintained, and terminated using the same signaling protocols used in ISDN.

Few manufacturers of Frame Relay DCE equipment support switched virtual circuit connections. Therefore, their actual deployment is minimal in today's Frame Relay networks.

Previously not widely supported by Frame Relay equipment, SVCs are now the norm. Companies have found that SVCs save money in the end because the circuit is not open all the time.

Permanent Virtual Circuits

Permanent virtual circuits (PVCs) are permanently established connections that are used for frequent and consistent data transfers between DTE devices across the Frame Relay network. Communication across a PVC does not require the call setup and termination states that are used with SVCs. PVCs always operate in one of the following two operational states:

•Data transfer—Data is transmitted between the DTE devices over the virtual circuit.

•Idle—The connection between DTE devices is active, but no data is transferred. Unlike SVCs, PVCs will not be terminated under any circumstances when in an idle state.

DTE devices can begin transferring data whenever they are ready because the circuit is permanently established.

Data-Link Connection Identifier

Frame Relay virtual circuits are identified by data-link connection identifiers (DLCIs). DLCI values typically are assigned by the Frame Relay service provider (for example, the telephone company).

Frame Relay DLCIs have local significance, which means that their values are unique in the LAN, but not necessarily in the Frame Relay WAN.

Figure 10-2 illustrates how two different DTE devices can be assigned the same DLCI value within one Frame Relay WAN.

Figure 10-2 A Single Frame Relay Virtual Circuit Can Be Assigned Different DLCIs on Each End of a VC

Congestion-Control Mechanisms

Frame Relay reduces network overhead by implementing simple congestion-notification mechanisms rather than explicit, per-virtual-circuit flow control. Frame Relay typically is implemented on reliable network media, so data integrity is not sacrificed because flow control can be left to higher-layer protocols. Frame Relay implements two congestion-notification mechanisms:

•Forward-explicit congestion notification (FECN)

•Backward-explicit congestion notification (BECN)

FECN and BECN each is controlled by a single bit contained in the Frame Relay frame header. The Frame Relay frame header also contains a Discard Eligibility (DE) bit, which is used to identify less important traffic that can be dropped during periods of congestion.

The FECN bit is part of the Address field in the Frame Relay frame header. The FECN mechanism is initiated when a DTE device sends Frame Relay frames into the network. If the network is congested, DCE devices (switches) set the value of the frames' FECN bit to 1. When the frames reach the destination DTE device, the Address field (with the FECN bit set) indicates that the frame experienced congestion in the path from source to destination. The DTE device can relay this information to a higher-layer protocol for processing. Depending on the implementation, flow control may be initiated, or the indication may be ignored.

The BECN bit is part of the Address field in the Frame Relay frame header. DCE devices set the value of the BECN bit to 1 in frames traveling in the opposite direction of frames with their FECN bit set. This informs the receiving DTE device that a particular path through the network is congested. The DTE device then can relay this information to a higher-layer protocol for processing. Depending on the implementation, flow-control may be initiated, or the indication may be ignored.

Frame Relay Discard Eligibility

The Discard Eligibility (DE) bit is used to indicate that a frame has lower importance than other frames. The DE bit is part of the Address field in the Frame Relay frame header.

DTE devices can set the value of the DE bit of a frame to 1 to indicate that the frame has lower importance than other frames. When the network becomes congested, DCE devices will discard frames with the DE bit set before discarding those that do not. This reduces the likelihood of critical data being dropped by Frame Relay DCE devices during periods of congestion.

Frame Relay Error Checking

Frame Relay uses a common error-checking mechanism known as the cyclic redundancy check (CRC). The CRC compares two calculated values to determine whether errors occurred during the transmission from source to destination. Frame Relay reduces network overhead by implementing error checking rather than error correction. Frame Relay typically is implemented on reliable network media, so data integrity is not sacrificed because error correction can be left to higher-layer protocols running on top of Frame Relay.

Frame Relay Local Management Interface

The Local Management Interface (LMI) is a set of enhancements to the basic Frame Relay specification. The LMI was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation. It offers a number of features (called extensions) for managing complex internetworks. Key Frame Relay LMI extensions include global addressing, virtual circuit status messages, and multicasting.

The LMI global addressing extension gives Frame Relay data-link connection identifier (DLCI) values global rather than local significance. DLCI values become DTE addresses that are unique in the Frame Relay WAN. The global addressing extension adds functionality and manageability to Frame Relay internetworks. Individual network interfaces and the end nodes attached to them, for example, can be identified by using standard address-resolution and discovery techniques. In addition, the entire Frame Relay network appears to be a typical LAN to routers on its periphery.

LMI virtual circuit status messages provide communication and synchronization between Frame Relay DTE and DCE devices. These messages are used to periodically report on the status of PVCs, which prevents data from being sent into black holes (that is, over PVCs that no longer exist).

The LMI multicasting extension allows multicast groups to be assigned. Multicasting saves bandwidth by allowing routing updates and address-resolution messages to be sent only to specific groups of routers. The extension also transmits reports on the status of multicast groups in update messages.

Frame Relay Network Implementation

A common private Frame Relay network implementation is to equip a T1 multiplexer with both Frame Relay and non-Frame Relay interfaces. Frame Relay traffic is forwarded out the Frame Relay interface and onto the data network. Non-Frame Relay traffic is forwarded to the appropriate application or service, such as a private branch exchange (PBX) for telephone service or to a video-teleconferencing application.

A typical Frame Relay network consists of a number of DTE devices, such as routers, connected to remote ports on multiplexer equipment via traditional point-to-point services such as T1, fractional T1, or 56-Kb circuits. An example of a simple Frame Relay network is shown in Figure 10-3.

Figure 10-3 A Simple Frame Relay Network Connects Various Devices to Different Services over a WAN

The majority of Frame Relay networks deployed today are provisioned by service providers that intend to offer transmission services to customers. This is often referred to as a public Frame Relay service. Frame Relay is implemented in both public carrier-provided networks and in private enterprise networks. The following section examines the two methodologies for deploying Frame Relay.

Public Carrier-Provided Networks

In public carrier-provided Frame Relay networks, the Frame Relay switching equipment is located in the central offices of a telecommunications carrier. Subscribers are charged based on their network use but are relieved from administering and maintaining the Frame Relay network equipment and service.

Generally, the DCE equipment also is owned by the telecommunications provider.
DTE equipment either will be customer-owned or perhaps will be owned by the telecommunications provider as a service to the customer.

The majority of today's Frame Relay networks are public carrier-provided networks.

Private Enterprise Networks

More frequently, organizations worldwide are deploying private Frame Relay networks. In private Frame Relay networks, the administration and maintenance of the network are the responsibilities of the enterprise (a private company). All the equipment, including the switching equipment, is owned by the customer.

Frame Relay Frame Formats

To understand much of the functionality of Frame Relay, it is helpful to understand the structure of the Frame Relay frame. Figure 10-4 depicts the basic format of the Frame Relay frame, and Figure 10-5 illustrates the LMI version of the Frame Relay frame.

Flags indicate the beginning and end of the frame. Three primary components make up
the Frame Relay frame: the header and address area, the user-data portion, and the frame check sequence (FCS). The address area, which is 2 bytes in length, is comprised of 10
bits representing the actual circuit identifier and 6 bits of fields related to congestion management. This identifier commonly is referred to as the data-link connection identifier (DLCI). Each of these is discussed in the descriptions that follow.

Standard Frame Relay Frame

Standard Frame Relay frames consist of the fields illustrated in Figure 10-4.

Figure 10-4 Five Fields Comprise the Frame Relay Frame

The following descriptions summarize the basic Frame Relay frame fields illustrated in Figure 10-4.

•Flags—Delimits the beginning and end of the frame. The value of this field is always the same and is represented either as the hexadecimal number 7E or as the binary number 01111110.

•Address—Contains the following information:

–DLCI—The 10-bit DLCI is the essence of the Frame Relay header. This value represents the virtual connection between the DTE device and the switch. Each virtual connection that is multiplexed onto the physical channel will be represented by a unique DLCI. The DLCI values have local significance only, which means that they are unique only to the physical channel on which they reside. Therefore, devices at opposite ends of a connection can use different DLCI values to refer to the same virtual connection.

–Extended Address (EA)—The EA is used to indicate whether the byte in which the EA value is 1 is the last addressing field. If the value is 1, then the current byte is determined to be the last DLCI octet. Although current Frame Relay implementations all use a two-octet DLCI, this capability does allow longer DLCIs to be used in the future. The eighth bit of each byte of the Address field is used to indicate the EA.

–C/R—The C/R is the bit that follows the most significant DLCI byte in the Address field. The C/R bit is not currently defined.

–Congestion Control—This consists of the 3 bits that control the Frame Relay congestion-notification mechanisms. These are the FECN, BECN, and DE bits, which are the last 3 bits in the Address field.

Forward-explicit congestion notification (FECN) is a single-bit field that can be set to a value of 1 by a switch to indicate to an end DTE device, such as a router, that congestion was experienced in the direction of the frame transmission from source to destination. The primary benefit of the use of the FECN and BECN fields is the capability of higher-layer protocols to react intelligently to these congestion indicators. Today, DECnet and OSI are the only higher-layer protocols that implement these capabilities.

Backward-explicit congestion notification (BECN) is a single-bit field that, when set to a value of 1 by a switch, indicates that congestion was experienced in the network in the direction opposite of the frame transmission from source to destination.

Discard eligibility (DE) is set by the DTE device, such as a router, to indicate that the marked frame is of lesser importance relative to other frames being transmitted. Frames that are marked as "discard eligible" should be discarded before other frames in a congested network. This allows for a basic prioritization mechanism in Frame Relay networks.

•Data—Contains encapsulated upper-layer data. Each frame in this variable-length field includes a user data or payload field that will vary in length up to 16,000 octets. This field serves to transport the higher-layer protocol packet (PDU) through a Frame Relay network.

•Frame Check Sequence—Ensures the integrity of transmitted data. This value is computed by the source device and verified by the receiver to ensure integrity of transmission.

LMI Frame Format

Frame Relay frames that conform to the LMI specifications consist of the fields illustrated in Figure 10-5.

Figure 10-5 Nine Fields Comprise the Frame Relay That Conforms to the LMI Format

The following descriptions summarize the fields illustrated in Figure 10-5.

•Flag—Delimits the beginning and end of the frame.

•LMI DLCI—Identifies the frame as an LMI frame instead of a basic Frame Relay frame. The LMI-specific DLCI value defined in the LMI consortium specification is DLCI = 1023.

•Unnumbered Information Indicator—Sets the poll/final bit to zero.

•Protocol Discriminator—Always contains a value indicating that the frame is an LMI frame.

•Call Reference—Always contains zeros. This field currently is not used for any purpose.

•Message Type—Labels the frame as one of the following message types:

–Status-inquiry message—Allows a user device to inquire about the status of the network.

–Status message—Responds to status-inquiry messages. Status messages include keepalives and PVC status messages.

•Information Elements—Contains a variable number of individual information elements (IEs). IEs consist of the following fields:

–IE Identifier—Uniquely identifies the IE.

–IE Length—Indicates the length of the IE.

–Data—Consists of 1 or more bytes containing encapsulated upper-layer data.

•Frame Check Sequence (FCS)—Ensures the integrity of transmitted data.

Summary

Frame Relay is a networking protocol that works at the bottom two levels of the OSI reference model: the physical and data link layers. It is an example of packet-switching technology, which enables end stations to dynamically share network resources.

Frame Relay devices fall into the following two general categories:

•Data terminal equipment (DTEs), which include terminals, personal computers, routers, and bridges

•Data circuit-terminating equipment (DCEs), which transmit the data through the network and are often carrier-owned devices (although, increasingly, enterprises are buying their own DCEs and implementing them in their networks)

Frame Relay networks transfer data using one of the following two connection types:

•Switched virtual circuits (SVCs), which are temporary connections that are created for each data transfer and then are terminated when the data transfer is complete (not a widely used connection)

•Permanent virtual circuits (PVCs), which are permanent connections

The DLCI is a value assigned to each virtual circuit and DTE device connection point in the Frame Relay WAN. Two different connections can be assigned the same value within the same Frame Relay WAN—one on each side of the virtual connection.

In 1990, Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation developed a set of Frame Relay enhancements called the Local Management Interface (LMI). The LMI enhancements offer a number of features (referred to as extensions) for managing complex internetworks, including the following:

•Global addressing

•Virtual circuit status messages

•Multicasting

Using the Capture command on a PIX firewall

sparky — Tue, 26 May 2009 10:47:00 +0100

Using the Capture command on a PIX firewall

A vital tool to use when troubleshooting computer networking problems and monitoring computer networks is a packet sniffer. That being said, one of the best methods to use when troubleshooting connection problems or monitoring suspicious network activity in a Cisco Systems PIX firewall is by using the capture command. Many times Cisco TAC will request captures from a PIX in PCAP format for open problem tickets associated with unusual problems or activity associated with the PIX and the network.

The capture command was first introduced to the PIX OS in version 6.2 and has the ability to capture all data that passes through the PIX device. You can use access-lists to specify the type of traffic that you wish to capture, along with the source and destination addresses and ports. Multiple capture statements can be used to attach the capture command to multiple interfaces. You can even copy the raw header and hexadecimal data in PCAP format to a tftp server and open it with TCPDUMP or Ethereal.

NOTE: You must be in privileged mode to invoke the capture command.

Below is the command usage and syntax description per Cisco's PIX OS 7.0 documentation:

To enable packet capture capabilities for packet sniffing and network fault isolation, use the capture command. To disable packet capture capabilities, use the no form of this command (see the "Usage Guidelines" section for additional information about the no form of this command).

capture capture_name [access-list access_list_name] [buffer buf_size] [ethernet-type type] [interface interface_name] [packet-length bytes] [circular-buffer]

capture capture_name type asp-drop [drop-code] [buffer buf_size] [circular-buffer] [packet-length bytes]

capture capture_name type isakmp [access-list access_list_name] [buffer buf_size] [circular-buffer] [interfacepacket-length bytes] interface_name] [

capture capture_name type raw-data [access-list access_list_name] [buffer buf_size] [circular-buffer] [ethernet-type type] [interface interface_name] [packet-length bytes]

capture capture_name type webvpn user webvpn-user [url url]

no capture capture_name

Syntax Description:

access-list access_list_name	(Optional) Selects packets based on IP or higher fields for a specific access list identification.
buffer buf_size	(Optional) Defines the buffer size used to store the packet in bytes.
capture_name	Specifies the name of the packet capture.
circular-buffer	(Optional) Overwrites the buffer, starting from the beginning, when the buffer is full.
ethernet-type type	(Optional) Selects an Ethernet type to capture.
interface interface_name	(Optional) Specifies the interface on which to use packet capture, where interface_name is the name assigned to the interface by the nameif command.
packet-length bytes	(Optional) Sets the maximum number of bytes of each packet to store in the capture buffer.
type asp-drop drop-code	(Optional) Captures packets dropped for a reason. You can specify a particular reason by using the drop-code argument. Valid values for the drop-code argument are listed in the "Usage Guidelines" section, below.
type isakamp	(Optional) Captures encrypted and decrypted ISAKMP payloads.
type raw-data	(Optional) Captures inbound and outbound packets on one or more interfaces. This is the default.
type webvpn	(Optional) Captures WebVPN data for a specific WebVPN connection.
url url	(Optional) Specifies a URL for a WebVPN connection capture.
user webvpn-user	(Optional) Specifies a username for a WebVPN capture.

The Capture command defaults are as follows:

The capture type is raw data.
The buffer size is 512 KB.
All the Ethernet types are accepted.
All the IP packets are matched.
The packet-length is 68 bytes.

Since the documentation above is not very easy to interpret for a beginner, I will be providing a simple monitoring situation and example below to help familiarize you with the commands associated with running a packet capture on a Cisco Secure Pix Firewall.

EXAMPLE:

(NOTE: The following scenario is made up, the domain and IP addresses are invalid and purely for example.)

You are wanting to monitor traffic between any users and a questionable Internet website from the inside to the outside via TCP port 80 for an internal security auditor needing proof of the transaction. The website www.madeupsite.com resolves with the IP address 192.168.1.1. In this example, the internal (Local) IP address is 10.1.1.1 and the external (Global) NAT IP Address is 192.168.2.2 and the PIX firewall is running 7.X code.

To accomplish this first we will write an extended access-list to apply to the capture that will allow us to capture any TCP traffic from any source address or port to the destination address 192.168.1.1 port 80 and vice versa. Next we will apply a capture to both the inside and outside interfaces of the firewall such that we can capture all the data specified in the access-list. Then we will then copy the raw captures in PCAP format to a TFTP server on the inside network with the IP address 10.1.1.100 such that the files can be viewed with TCPDUMP or Ethereal. Finally we will remove the captures and access-list from the PIX firewall.

Start: Secure Shell connection to the PIX:

! Go into global config mode and configure an extended access-list permitting any tcp traffic from any source host/port to destination host 192.168.1.1/port 80 and any tcp traffic from source host 192.168.1.1/port 80 to any destination host/port.

PIX# config t

PIX(config)# access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq 80

PIX(config)# access-list webcap line 2 extended permit tcp host 192.168.1.1 eq 80 any

PIX(config)# exit

! Exit from global config mode and verify your access-list using the show access-list command.

PIX# show access-list webcap

access-list webcap; 2 elements

access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq www (hitcnt=0)

access-list webcap line 2 extended permit tcp host 192.168.1.1 eq www any (hitcnt=0)

! From privileged mode configure two raw-data captures based on the access-list requirements configured above and apply one to the outside interface and one to the inside interface of the PIX firewall.

PIX# capture webcapinside type raw-data access-list webcap interface inside

PIX# capture webcapoutside type raw-data access-list webcap interface outside

! Verify your captures using the show capture command.

PIX# show capture

capture webcapinside type raw-data access-list webcap interface inside

capture webcapoutside type raw-data access-list webcap interface outside

! In this example we will assume that the captures were on long enough to capture the data below. This data consists of a TCP connection from 10.1.1.1 (Local) / 192.168.2.2 (Global) to 192.168.1.1 over port 80. The capture data is displayed in the PIX console by using the show capture command.

NOTE: The data captured on the outside interface shows the source as the global IP.

PIX# show capture webcapoutside

17 packets captured

1: 09:03:02.244906 192.168.2.2.2536 > 192.168.1.1.80: S 39829922:39829922(0) win 65535 <mss 1260,nop,nop,sackOK>

2: 09:03:02.275620 192.168.1.1.80 > 192.168.2.2.2536: S 1295066193:1295066193(0) ack 39829923 win 5840 <mss 1380>

3: 09:03:02.275940 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295066194 win 65535

4: 09:03:02.282303 192.168.2.2.2536 > 192.168.1.1.80: P 39829923:39830620(697) ack 1295066194 win 65535

5: 09:03:02.314864 192.168.1.1.80 > 192.168.2.2.2536: . ack 39830620 win 6970

6: 09:03:05.029722 192.168.1.1.80 > 192.168.2.2.2536: . 1295066194:1295067454(1260) ack 39830620 win 6970

7: 09:03:05.030805 192.168.1.1.80 > 192.168.2.2.2536: . 1295067454:1295068714(1260) ack 39830620 win 6970

8: 09:03:05.031309 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295068714 win 65535

9: 09:03:05.064129 192.168.1.1.80 > 192.168.2.2.2536: . 1295068714:1295069974(1260) ack 39830620 win 6970

10: 09:03:05.065182 192.168.1.1.80 > 192.168.2.2.2536: . 1295069974:1295071234(1260) ack 39830620 win 6970

11: 09:03:05.065700 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295071234 win 65535

12: 09:03:05.066296 192.168.1.1.80 > 192.168.2.2.2536: . 1295071234:1295072494(1260) ack 39830620 win 6970

13: 09:03:05.098597 192.168.1.1.80 > 192.168.2.2.2536: . 1295072494:1295073754(1260) ack 39830620 win 6970

14: 09:03:05.099146 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295073754 win 65535

15: 09:03:05.099588 192.168.1.1.80 > 192.168.2.2.2536: . 1295073754:1295075014(1260) ack 39830620 win 6970

16: 09:03:05.100168 192.168.1.1.80 > 192.168.2.2.2536: P 1295075014:1295075958(944) ack 39830620 win 6970

17: 09:03:05.100595 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295075958 win 65535

17 packets shown

NOTE: The data captured on the intside interface shows the source as the local IP.

PIX# show capture webcapinside

17 packets captured

1: 09:03:02.244784 10.1.1.1.2536 > 192.168.1.1.80: S 4015780382:4015780382(0) win 65535 <mss 1260,nop,nop,sackOK>

2: 09:03:02.275651 192.168.1.1.80 > 10.1.1.1.2536: S 2468538302:2468538302(0) ack 4015780383 win 5840 <mss 1380>

3: 09:03:02.275895 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468538303 win 65535

4: 09:03:02.282288 10.1.1.1.2536 > 192.168.1.1.80: P 4015780383:4015781080(697) ack 2468538303 win 65535

5: 09:03:02.314894 192.168.1.1.80 > 10.1.1.1.2536: . ack 4015781080 win 6970

6: 09:03:05.029753 192.168.1.1.80 > 10.1.1.1.2536: . 2468538303:2468539563(1260) ack 4015781080 win 6970

7: 09:03:05.030821 192.168.1.1.80 > 10.1.1.1.2536: . 2468539563:2468540823(1260) ack 4015781080 win 6970

8: 09:03:05.031278 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468540823 win 65535

9: 09:03:05.064144 192.168.1.1.80 > 10.1.1.1.2536: . 2468540823:2468542083(1260) ack 4015781080 win 6970

10: 09:03:05.065197 192.168.1.1.80 > 10.1.1.1.2536: . 2468542083:2468543343(1260) ack 4015781080 win 6970

11: 09:03:05.065670 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468543343 win 65535

12: 09:03:05.066311 192.168.1.1.80 > 10.1.1.1.2536: . 2468543343:2468544603(1260) ack 4015781080 win 6970

13: 09:03:05.098612 192.168.1.1.80 > 10.1.1.1.2536: . 2468544603:2468545863(1260) ack 4015781080 win 6970

14: 09:03:05.099131 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468545863 win 65535

15: 09:03:05.099619 192.168.1.1.80 > 10.1.1.1.2536: . 2468545863:2468547123(1260) ack 4015781080 win 6970

16: 09:03:05.100199 192.168.1.1.80 > 10.1.1.1.2536: P 2468547123:2468548067(944) ack 4015781080 win 6970

17: 09:03:05.100580 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468548067 win 65535

17 packets shown

! Now we will copy the raw data that we captured to a tftp server on the inside network with the IP address of 10.1.1.100 in PCAP format using the copy /pcap command.

! NOTE: The !!!!! indicates successful transfer of data.

PIX# copy /pcap capture:webcapinside tftp:

Source capture name [webcapinside]? <enter>

Address or name of remote host []? 10.1.1.100

Destination filename [webcapinside]? <enter> ! NOTE: The filename could be changed here.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

NOTE: The !!!!! indicates successful transfer of data.

PIX# copy /pcap capture:webcapoutside tftp:

Source capture name [webcapoutside]? <enter>

Address or name of remote host []? 10.1.1.100

Destination filename [webcapoutside]? <enter> ! NOTE: The filename could be changed here.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Now we will remove the captures from the PIX firewall using the no form of the capture command.

PIX# no capture webcapinside type raw-data access-list webcap interface inside.

PIX# no capture webcapoutside type raw-data access-list webcap interface outside

! Finally we will remove the access-list entries from the PIX firewall using the no form of the access-list command.

PIX# config t

PIX(config)# access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq 80

PIX(config)# access-list webcap line 2 extended permit tcp host 192.168.1.1 eq 80 any

PIX(config)# exit

PIX#

Now we have accomplished our task and the captures wanted by the auditor can be opened with TCPDUMP or Ethereal from the TFTP server. I hope you've enjoyed this simple tutorial on using the capture command in the PIX firewall. This command can be very powerful and very useful if configured properly.

---------------------------------------------------------------------------------

Article courtesy of www.ComputerNetworkingHelp.com

Synchronous Communications Overview

sparky — Mon, 18 May 2009 14:05:00 +0100

SYNCHRONOUS SERIAL COMMUNICATION OVERVIEW

Coordinated Speed

As its name implies, synchronous communication takes place between a transmitter and a receiver operating on synchronized clocks. In a synchronous system, the communication partners have a short conversation before data exchange begins. In this conversation, they align their clocks and agree upon the parameters of the data transfer, including the time interval between bits of data. Any data that falls outside these parameters will be assumed to be either in error or a placeholder used to maintain synchronization. (Synchronous lines must remain constantly active in order to maintain synchronization, thus the need for placeholders between valid data.) Once each side knows what to expect of the other, and knows how to indicate to the other whether what was expected was received, then communication of any length can commence.

The theory behind asynchronous and synchronous communication is essentially the same: Point B needs to know when a transmission from Point A begins, when it ends, and if it was processed correctly. However, the difference lies in how the transmission is broken down. Think of the difference in terms of a friendly chat. With asynchronous communication you would need to stop after every word to make sure the listener understood your meaning, and knew that you were about to speak the next word. With synchronous communication, you would establish with your listener that you were speaking English, that you will be speaking words at measured intervals, and that you would utter a complete sentence, or paragraph, or extended soliloquy, before pausing to confirm understanding. Further, you would establish with your listener beforehand that any extraneous noises you make during the speech or between speeches (coughing, burping, hiccupping) should be ignored. Clearly the second approach is much faster, even though initializing communication may take slightly longer. In fact, by replacing the start, stop and parity bits around individual words with start, stop and control (processing instructions and error checking) sequences around large continuous data blocks, synchronous communication is about 30% faster than asynchronous communication, before any other factors are considered.

Clock Synchronization

In order to initiate a successful synchronous communication link, several distinct pieces of hardware must be configured around a common clock. This configuration must take two data lines into account, the transmission line (the line it uses to send data) and the reception line (the line it uses to receive data). It is essential not only that all devices in the system be synchronized with each other, but also that each individual device have its transmission and reception lines synchronized as well.

There are three clocking methods by which to achieve synchronization: internal, external, and recovered clocking. All three methods derive the clock signal for the reception line from the incoming data. The clock signal for the transmission line will always be generated by the devices internal oscillator, but the phase reference used by the internal oscillator differs for each of the clocking methods. When internal clocking is used, the transmit clock is phase locked to the device's own internal oscillator. For external clocking, the transmit clock is phase locked to the phase of the oscillator belonging to another device in the network. For recovered clocking, the transmit clock phase is locked to the clock derived from the incoming data.

In general, the DCE device (such as a modem) uses internal clocking, while the DTE device (such as a PC) uses external clocking and synchronizes around the DCE device. (See the RS-232 overview for a discussion of DTE and DCE devices.) In cases where DTE-DTE or DCE-DCE connections are necessary, one device must be configured atypically, or a device such as a modem-eliminator or tail-circuit buffer must be placed between the two. However, in large networks with multiple devices this is not always possible. One solution for such networks is to have all devices synchronize around a single modem's clock source. However, this solution has the tendency to result in clock drift, and thus can potentially corrupt data. The other solution is to use recovered clocking so that a modem can derive the clock from data on its reception line then send that information out on its transmit line to be used by the next modem in line, etc.

Byte Oriented Synchronous Protocols

Synchronous communication can be implemented for full and half-duplex networks using bit- or byte-oriented protocols. Half-duplex networks, whether point-to-point or multipoint, can only support communication in one direction at a time. The most commonly used protocol for such networks is IBM's Binary Synchronous Communication Procedures (BiSync). BiSync is a byte oriented protocol, which means that it approaches transmitted data as “blocks" that must each be decoded and tracked to determine what they are, and what they are telling the receiver to do.

In a BiSync system one computer is designated as a control station. It is responsible for initiating all data transfers, and thereby controlling the direction of flow on the communication line. Byte-oriented communication begins with establishing synchronization, it then establishes communication parameters that define instructions for processing given bit sequences. Finally, the actual data will be transmitted, and then followed by several frames that validate the transmission. BiSync transmission is also governed by a strict set of rules for data transmission. These rules require frequent handshaking and validation--speaking in sentences rather than paragraphs between pauses. As a result of the extensive handshaking, and because communication can take place in only one direction, BiSync communication is best suited for low-speed applications.

Byte Oriented Synchronous Protocols

In bit-oriented protocols, data is accepted as a long string of bits whose order does not impart specific instructions to the receiver. Data is flagged by a set bit pattern at either end, and is validated by a single frame check sequence at the end of the message that either accepts it or demands retransmission. Any bits received outside of valid flag sequences are ignored as placeholders.

Clearly, bit-oriented communication requires considerably less overhead than byte-oriented communication, because it is not constantly attempting to match bit sequences to numerous predetermined arrangements. The only sequence the bit-oriented protocol is concerned with identifying is the flag sequence. Bit protocols have other advantages over byte protocols as well. In a byte-oriented system, because of the constant handshaking, communication can take place in only one direction at a time. In bit-oriented systems, both ends can talk to each other at once, enabling effective use of full-duplex networks. Further, a single master device using bit protocols can communicate with multiple slave devices by using an address field following the start of message flag. This address field is tailored to each individual slave, and slaves only process data that is specifically addressed to them. Likewise, when the master receives from the slave, it knows from precisely where the transmission originated.

The two main bit-oriented protocols used today are Synchronous Data Link Control (SDLC) and High-Level Data Link Control (HDLC). SDLC, which was developed by IBM in the 1970s, is based around a network of primary and secondary network nodes. The primary controls the network and continually polls the secondaries to determine whether they have data to transmit. Four configurations are available for SDLC networks:

Point to Point: one primary connected to one secondary
Multipoint: one primary connected to multiple secondaries
Loop: one primary connects to the first and last secondary, and secondaries in the middle pass messages through each other to the primary.
Hub go-ahead: Uses one inbound and one outbound channel. The primary sends on the outbound channel and the secondaries send on the inbound channel. Secondaries pass messages through each other back to the primary.

Key to SDLC communication is the control characters it uses to maintain data integrity. The figure below shows the six fields that comprise a single SDLC data frame.

Flag

Address

Control

Data

Frame Check Sequence

Flag

(SDLC Data Frame)

The Flag field starts and ends error checking. The Address field is used to indicate the intended data destination, and can be a single address, a group of addresses, or a broadcast to the entire network. The Data field is the information being transmitted, and the Frame Check Sequence (FCS) is generally a Cyclic Redundancy Check (CRC) calculation. A calculation on the transmitted data is done by the transmitter and the result is sent in the FCS. This calculation is then performed by the receiver after data transmission is complete. If the results don't match, an error is assumed.

The Control field uses three different formats depending on the type of SDLC frame. The diagram below breaks out the different data bits in the control field. Explanations for the three control formats follow.

(Control Field Formats for SDLC Frames)

The Information Frame is used when actual data is being transmitted. It is also used to provide sequencing, flow and error control functions. The sequence number bits are used to indicate the number of the frame that will be sent/received next, and are used by both the primary and secondary nodes. The Poll Final bit is used by the primary to tell the secondary whether or not an immediate response is required. The secondary uses the Poll Final bit to indicate whether the current frame is the last in its response, or whether more frames are coming.

The Supervisory Frame is used to control the communication network. It can request or suspend data transfer, report status, and acknowledge receipt of data. Note that since Supervisory frames are used exclusively for control, they do not have data fields.

The Unnumbered Frame is unsequenced, can contain one or two bytes, and is used to provide miscellaneous control commands. For instance, it might be used by a primary node to activate the secondary nodes in the network.

Another bit-oriented synchronous communication protocol, High Level Data Link Control (HDLC) which is based on SDLC, also uses the frame format described above. However HDLC, which was approved by the International Standards Organization (ISO) in 1979, differs from SDLC in several ways. With HDLC, 32-bit checksums can be used, thereby providing an advantage over SDLC in the sophistication and accuracy of error checking, and thus data integrity. Unlike SDLC, HDLC protocols cannot operate using loop or hub go-ahead configurations.

The largest difference between the two, is that SDLC uses only a single transfer mode, while HDLC provides three choices. Both use Normal Response Mode (NRM) in which a secondary node is precluded from communicating with a primary node until the primary gives permission. The two additional HDLC modes are Asynchronous Response Mode (ARM) and Asynchronous Balanced Mode (ABM). In ARM mode, any secondary can initiate communication without receiving permission from the primary. ABM mode requires that all devices be configured as combination nodes that, depending on the situation, can assume the role of primary or secondary in the network. In such a system, any device can initiate communication at any time without permission.

Data Buffers

Though synchronous communication enables transmission of large amounts of data at high speed, it puts in place extensive control and error-checking mechanisms to prevent data corruption. However, in full-duplex networks using bit-oriented protocols, the transmitter is most likely sending frame B before it knows if frame A was received successfully. (This is not as much of a problem in slower byte-oriented protocols where data flows in only one direction at a time.) To maintain the highest possible data rates, synchronous hardware must contain sufficient data buffers to store transmitted data (for resending if necessary) until a successful transfer is confirmed.

Quatech synchronous serial PCMCIA and PCI cards use a 1024-byte FIFO for data buffering. Our ISA synchronous cards use DMA. All support both bit and byte protocols, and point-to-point and multipoint full- and half-duplex networks. We also supply SyncDrive and SyncDrive Plus software with all synchronous cards. SYNCDrive provides hardware specific device drivers, DLLs and APIs to simplify incorporating Quatech boards into your BiSync, SDLC and HDLC applications under DOS, Windows 98/98/Me and OS/2. SyncDrive Plus provides device drivers for SDLC and HDLC applications under Windows 2000/XP.

----------------------------------------------------------------------------------------------------------------------

Article courtesy of quatech.com

Asynchronous Serial Communications

sparky — Mon, 18 May 2009 14:03:00 +0100

ASYNCHRONOUS SERIAL COMMUNICATION OVERVIEW

The Simple, Inexpensive Choice

Most PC serial devices such as mice, keyboards and modems are asynchronous. Asynchronous communication requires nothing more than a transmitter, a receiver and a wire. It is thus the simplest of serial communication protocols, and the least expensive to implement. As the name implies, asynchronous communication is performed between two (or more) devices which operate on independent clocks. Therefore, even if the two clocks agree for a time, there is no guarantee that they will continue to agree over extended periods, and thus there is no guarantee that when point A begins transmitting, point B will begin receiving, or that Point B will continue to sample at the rate Point A transmits. See the figure below for an illustration of what happens when transmission clocks differ significantly.

To combat this timing problem, asynchronous communication requires additional bits to be added around actual data in order to maintain signal integrity. Asynchronously transmitted data is preceded with a start bit which indicates to the receiver that a word (a chunk of data broken up into individual bits) is about to begin. To avoid confusion with other bits, the start bit is twice the size of any other bit in the transmission. The end of a word is followed by a stop bit, which tells the receiver that the word has come to an end, that it should begin looking for the next start bit, and that any bits it receives before getting the start bit should be ignored. To ensure data integrity, a parity bit is often added between the last bit of data and the stop bit. The parity bit makes sure that the data received is composed of the same number of bits in the same order in which they were sent. Use the link below to view a portrayal of how asynchronous communication works.

asynchronous communication, data is preceded with a start bit which indicates to the receiver that a word (a chunk of data broken up into individual bits) is about to begin. To avoid confusion with other bits, the start bit is twice the size of any other bit in the transmission. The end of a word is followed by a stop bit, which tells the receiver that the word has come to an end, that it should begin looking for the next start bit, and that any bits it receives before getting the start bit should be ignored. To insure data integrity, a parity bit is often added between the last bit of data and the stop bit. The parity bit makes sure that the data received is composed of the same number of bits in the same order in which they were sent. See the diagram in Figure 11 for a portrayal of how asynchronous communication works.

Upgraded UARTs For Increased Performance

At the heart of every asynchronous serial system is the Universal Asynchronous Receiver/Transmitter or UART. The UART is responsible for implementing the asynchronous communication process described above as both a transmitter and a receiver (both encoding and decoding data frames). The UART not only controls the transfer of data, but the speed at which communication takes place. However, the first UARTs could only handle one byte of information at a time, which meant that the computer needed to immediately process any transmission or risk losing data as the next byte of information pushed its way onto the UART. Not only does this makes for unreliable and slow communication, it can slow down the entire system.

Improved UARTs, such as the 16750 UARTs, increase communication speed and lower system overhead by offering 64-byte FIFOs (first in first out buffers). With the 64-byte FIFO buffer, the UART can store enough information that the data stream need not be suspended while the computer is busy. This is particularly helpful in heavy multitasking operating systems such as Windows 95/98/Me/NT/2000/XP and OS/2.

Enhanced Serial Adapters for Even More Speed

Even with top of the line 16750 UARTs, a standard serial board with a standard 1.8432 MHz clock can only reach data transfer rates of 115.2 kbps. This is because the UART sets the baud rate by dividing down the clock frequency, and the lower the clock speed, the lower the possible data rate. An obvious solution to faster data rates is to simply get a faster clock--and many Quatech serial boards can be custom configured with upgraded crystals to achieve higher speeds. The other solution is to create a faster clock from the standard clock by multiplying its frequency. Quatech enhanced serial adapters do just that.

All Quatech PCI serial products are based on the enhanced design, as are some of the ISA and PCMCIA asynchronous serial boards. The standard clock rate on these boards can be multiplied by a factor of one, two, four, or eight by using jumper or software controls. High baud rates, up to 921.6 kbps, can be produced through a combination of changing the clock rate multiplier and the UART baud rate divisor (see chart below). For example, a baud rate of 230.4 kbps could be achieved by setting the clock rate multiplier to X2 and setting a software application for 115.2 kbps. However, because of the limitations of the 16-byte FIFOs on 16550 UARTs, 16750 UARTs will be needed to take full advantage of 4X and 8X clock multiplying.

Clock Rate Multiplier	UART Clock Frequency	Max Data Rate
X1	1.832 MHz	115.2 kbaud
X2	3.6834 MHz	230.4 kbaud
X3	7.3728 MHz	460.8 kbaud
X4	14.7456 MHz	921.6 kbaud

-----------------------------------------------------------------------------------------------------------------------
Artice courtesy of quatech.com

Point To Point Protocol

sparky — Tue, 05 May 2009 10:19:00 +0100

Point-to-Point Protocol

Introduction

The Point-to-Point Protocol (PPP) originally emerged as an encapsulation protocol for transporting IP traffic over point-to-point links. PPP also established a standard for the assignment and management of IP addresses, asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network layer address negotiation and data-compression negotiation. PPP supports these functions by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCPs) to negotiate optional configuration parameters and facilities. In addition to IP, PPP supports other protocols, including Novell's Internetwork Packet Exchange (IPX) and DECnet.

PPP Components

PPP provides a method for transmitting datagrams over serial point-to-point links. PPP contains three main components:

•A method for encapsulating datagrams over serial links. PPP uses the High-Level Data Link Control (HDLC) protocol as a basis for encapsulating datagrams over point-to-point links. (See Chapter 16, "Synchronous Data Link Control and Derivatives," for more information on HDLC.)

•An extensible LCP to establish, configure, and test the data link connection.

•A family of NCPs for establishing and configuring different network layer protocols. PPP is designed to allow the simultaneous use of multiple network layer protocols.

General Operation

To establish communications over a point-to-point link, the originating PPP first sends LCP frames to configure and (optionally) test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, the originating PPP sends NCP frames to choose and configure one or more network layer protocols. When each of the chosen network layer protocols has been configured, packets from each network layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP frames close the link, or until some external event occurs (for example, an inactivity timer expires or a user intervenes).

Physical Layer Requirements

PPP is capable of operating across any DTE/DCE interface. Examples include EIA/TIA-232-C (formerly RS-232-C), EIA/TIA-422 (formerly RS-422), EIA/TIA-423 (formerly RS-423), and International Telecommunication Union Telecommunication Standardization Sector (ITU-T) (formerly CCITT) V.35. The only absolute requirement imposed by PPP is the provision of a duplex circuit, either dedicated or switched, that can operate in either an asynchronous or synchronous bit-serial mode, transparent to PPP link layer frames. PPP does not impose any restrictions regarding transmission rate other than those imposed by the particular DTE/DCE interface in use.

PPP Link Layer

PPP uses the principles, terminology, and frame structure of the International Organization for Standardization (ISO) HDLC procedures (ISO 3309-1979), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/Stop Transmission." ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments. The PPP control procedures use the definitions and control field encodings standardized in ISO 4335-1979 and ISO 4335-1979/Addendum 1-1979. The PPP frame format appears in Figure 13-1.

Figure 13-1 Six Fields Make Up the PPP Frame

The following descriptions summarize the PPP frame fields illustrated in Figure 13-1:

•Flag—A single byte that indicates the beginning or end of a frame. The flag field consists of the binary sequence 01111110.

•Address—A single byte that contains the binary sequence 11111111, the standard broadcast address. PPP does not assign individual station addresses.

•Control—A single byte that contains the binary sequence 00000011, which calls for transmission of user data in an unsequenced frame. A connectionless link service similar to that of Logical Link Control (LLC) Type 1 is provided. (For more information about LLC types and frame types, refer to Chapter 16.)

•Protocol—Two bytes that identify the protocol encapsulated in the information field of the frame. The most up-to-date values of the protocol field are specified in the most recent Assigned Numbers Request For Comments (RFC).

•Data—Zero or more bytes that contain the datagram for the protocol specified in the protocol field. The end of the information field is found by locating the closing flag sequence and allowing 2 bytes for the FCS field. The default maximum length
of the information field is 1,500 bytes. By prior agreement, consenting PPP implementations can use other values for the maximum information field length.

•Frame check sequence (FCS)—Normally 16 bits (2 bytes). By prior agreement, consenting PPP implementations can use a 32-bit (4-byte) FCS for improved error detection.

The LCP can negotiate modifications to the standard PPP frame structure. Modified frames, however, always will be clearly distinguishable from standard frames.

PPP Link-Control Protocol

The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. LCP goes through four distinct phases.

First, link establishment and configuration negotiation occur. Before any network layer datagrams (for example, IP) can be exchanged, LCP first must open the connection and negotiate configuration parameters. This phase is complete when a configuration-acknowledgment frame has been both sent and received.

This is followed by link quality determination. LCP allows an optional link quality determination phase following the link-establishment and configuration-negotiation phase. In this phase, the link is tested to determine whether the link quality is sufficient to bring up network layer protocols. This phase is optional. LCP can delay transmission of network layer protocol information until this phase is complete.

At this point, network layer protocol configuration negotiation occurs. After LCP has finished the link quality determination phase, network layer protocols can be configured separately by the appropriate NCP and can be brought up and taken down at any time. If LCP closes the link, it informs the network layer protocols so that they can take appropriate action.

Finally, link termination occurs. LCP can terminate the link at any time. This usually is done at the request of a user but can happen because of a physical event, such as the loss of carrier or the expiration of an idle-period timer.

Three classes of LCP frames exist. Link-establishment frames are used to establish and configure a link. Link-termination frames are used to terminate a link, and link-maintenance frames are used to manage and debug a link.

These frames are used to accomplish the work of each of the LCP phases.

Summary

PPP provides a method for transmitting datagrams over serial point-to-point links, which include the following three components:

•A method for encapsulating datagrams over serial links

•An extensible LCP to establish, configure, and test the connection

•A family of NCPs for establishing and configuring different network layer protocols

PPP is capable of operating across any DTE/DCE interface. PPP does not impose any restriction regarding transmission rate other than those imposed by the particular DTE/DCE interface in use.

Six fields make up the PPP frame. The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection.

---

Article courtesy of the Cisco Internetworking Handbook

Intelligent Platform Management Interface - IPMI

sparky — Mon, 06 Apr 2009 10:42:00 +0100

Intelligent Platform Management Interface

The Intelligent Platform Management Interface (IPMI) specification defines a set of common interfaces to a computer system which system administrators can use to monitor system health and manage the system. Several dozen companies support IPMI. Dell, HP, Intel Corporation and NEC Corporation announced IPMI v1.0 on 1998-09-16, v1.5 on 2001-03-01, and v2.0 on 2004-02-14.

IPMI operates independently of the operating system and allows administrators to manage a system remotely even in the absence of an operating system or the system management software, or even if the monitored system is powered off, but connected to a power source. IPMI can also function after the operating system has started, and offers enhanced features when used with system management software. IPMI prescribes only the structure and format of the interfaces as a standard, while detailed implementations may vary.

An implementation of IPMI version 1.5 and later can send out alerts via a direct serial connection, a local area network (LAN) or a serial over LAN (SOL) connection to a remote client. System administrators can then use IPMI messaging to query platform status, to review hardware logs, or to issue other requests from a remote console through the same connections. The standard also defines an alerting mechanism for the system to send a simple network management protocol (SNMP) platform event trap (PET).

The IPMI consists of a main controller called the Baseboard Management Controller (BMC) and other satellite controllers. The satellite controllers within the same chassis connect to the BMC via the system interface called IPMB (Intelligent Platform Management Bus/Bridge) — an enhanced implementation of I²C (Inter-Integrated Circuit). The BMC connects to satellite controllers or another BMC in another chassis via IPMC (Intelligent Platform Management Chassis) bus/bridge. It may be managed with the Remote Management Control Protocol (RMCP), a specialized wire protocol defined by this specification.

A Field Replaceable Unit (FRU) holds the inventory (such as vendor id, manufacturer etc.) of potentially replaceable devices. A Sensor Data Records (SDR) repository provides the properties of the individual sensors present on the board. For example, the board may contain sensors for temperature, fan speed, and voltage.

IEEE 802 Standards

sparky — Mon, 23 Mar 2009 14:42:00 +0000

IEEE 802 refers to a family of IEEE standards dealing with local area networks and metropolitan area networks.

More specifically, the IEEE 802 standards are restricted to networks carrying variable-size packets. (By contrast, in cell-based networks data is transmitted in short, uniformly sized units called cells. Isochronous networks, where data is transmitted as a steady stream of octets, or groups of octets, at regular time intervals, are also out of the scope of this standard.) The number 802 was simply the next free number IEEE could assign, though “802” is sometimes associated with the date the first meeting was held — February 1980.

The services and protocols specified in IEEE 802 map to the lower two layers (Data Link and Physical) of the seven-layer OSI networking reference model. In fact, IEEE 802 splits the OSI Data Link Layer into two sub-layers named Logical Link Control (LLC) and Media Access Control (MAC) , so that the layers can be listed like this:

The IEEE 802 family of standards is maintained by the IEEE 802 LAN/MAN Standards Committee (LMSC). The most widely used standards are for the Ethernet family, Token Ring, Wireless LAN, Bridging and Virtual Bridged LANs. An individual Working Group provides the focus for each area.

See its working groups:

IEEE 802.1 Bridging (networking) and Network Management

802.1D - MAC Bridges
802.1Q - Virtual LANs
802.1w - Rapid Reconfiguration of Spanning Tree

IEEE 802.2 Logical link control (inactive)
IEEE 802.3 Ethernet
IEEE 802.4 Token bus (disbanded)
IEEE 802.5 Defines the MAC layer for a Token Ring (inactive)
IEEE 802.6 Metropolitan Area Networks (disbanded)
IEEE 802.7 Broadband LAN using Coaxial Cable (disbanded)
IEEE 802.8 Fiber Optic TAG (disbanded)
IEEE 802.9 Integrated Services LAN (disbanded)
IEEE 802.10 Interoperable LAN Security (disbanded)
IEEE 802.11 Wireless LAN & Mesh (Wi-Fi certification)
IEEE 802.12 demand priority (disbanded)
IEEE 802.13 Not used (officially)
IEEE 802.14 Cable modems (disbanded)
IEEE 802.15 Wireless PAN
- IEEE 802.15.1 (Bluetooth certification)
- IEEE 802.15.4 (ZigBee certification)
IEEE 802.16 Broadband Wireless Access (WiMAX certification)
- IEEE 802.16e (Mobile) Broadband Wireless Access
- IEEE 802.16.1 Local Multipoint Distribution Service
IEEE 802.17 Resilient packet ring
IEEE 802.18 Radio Regulatory TAG
IEEE 802.19 Coexistence TAG
IEEE 802.20 Mobile Broadband Wireless Access
IEEE 802.21 Media Independent Handoff
IEEE 802.22 Wireless Regional Area Network

Router On A Stick

sparky — Mon, 23 Mar 2009 14:39:00 +0000

Router On A Stick

Basic Cisco theory states that for hosts in different VLANs to communicate, a Layer 3 device must be involved to handle the routing between the VLANs. That device is a router, and there are special considerations that must be taken into account for both the physical router itself and the configuration you'll be writing.

The router will be connected to a switch via a FastEthernet port (or higher). The router port cannot be a regular Ethernet port, since the router port will need the ability to send and receive data at the same time.

The configuration of the interface is where things get interesting. Let's say we have two VLANs that will be using router-on-a-stick to communicate. Here is the VLAN information:

VLAN 20: 20.20.20.0 /24

VLAN 40: 40.40.40.0 /24

The port on the switch that will be connected to the router's FastEthernet port must be in trunking mode, and you must know the trunking protocol in use. We'll go with the Cisco-proprietary Dot1q here.

The physical FE port on the router will not have an IP address. The use of router-on-a-stick mandates the use of logical subinterfaces. While we don't have to use the VLAN numbers for the subinterface numbers, I've found this helps you keep the interfaces straight. One subinterface must be given an IP address in VLAN 20, and the other will have an IP address in VLAN 40.

After creating subinterfaces fast 0.20 and fast 0.40, the config looks like this:

interface fastethernet0

no ip address

interface FastEthernet 0.20

ip address 20.20.20.1 255.255.255.0

interface FastEthernet 0.40

ip address 40.40.40.1 255.255.255.0

Believe it or not, you're almost done! Now we need the encapsulation statement under each subinterface. The subinterface statement must reflect both the VLAN number and the encapsulation type being used. When we're finished, the config would look like this:

interface fastethernet0

no ip address

interface FastEthernet 0.20

ip address 20.20.20.1 255.255.255.0

encapsulation dot1q 20

interface FastEthernet 0.40

ip address 40.40.40.1 255.255.255.0

encapsulation dot1q 40

And that's it! Your hosts in VLAN 20 should now be able to communicate with hosts in VLAN 40, and vice versa.

A couple of final troubleshooting points - the most common error with router-on-a-stick is to put the wrong vlan number in the encapsulation statement. Also, make sure you have configured the router's IP address in VLAN 20 as the default gateway for hosts in VLAN 20, and do the same for VLAN 40.

STP

sparky — Mon, 02 Mar 2009 15:00:00 +0000

Understanding Spanning-Tree Protocol - www.cisco.com

Spanning-Tree Protocol is a link management protocol that provides path redundancy while preventing undesirable loops in the network. For an Ethernet network to function properly, only one active path can exist between two stations.

Multiple active paths between stations cause loops in the network. If a loop exists in the network topology, the potential exists for duplication of messages. When loops occur, some switches see stations appear on both sides of the switch. This condition confuses the forwarding algorithm and allows duplicate frames to be forwarded.

To provide path redundancy, Spanning-Tree Protocol defines a tree that spans all switches in an extended network. Spanning-Tree Protocol forces certain redundant data paths into a standby (blocked) state. If one network segment in the Spanning-Tree Protocol becomes unreachable, or if Spanning-Tree Protocol costs change, the spanning-tree algorithm reconfigures the spanning-tree topology and reestablishes the link by activating the standby path.

Spanning-Tree Protocol operation is transparent to end stations, which are unaware whether they are connected to a single LAN segment or a switched LAN of multiple segments.

Election of the Root Switch

All switches in an extended LAN participating in Spanning-Tree Protocol gather information on other switches in the network through an exchange of data messages. These messages are bridge protocol data units (BPDUs). This exchange of messages results in the following:

The election of a unique root switch for the stable spanning-tree network topology.
The election of a designated switch for every switched LAN segment.
The removal of loops in the switched network by placing redundant switch ports in a backup state.

The Spanning-Tree Protocol root switch is the logical center of the spanning-tree topology in a switched network. All paths that are not needed to reach the root switch from anywhere in the switched network are placed in Spanning-Tree Protocol backup mode. Table C-1 describes the root switch variables, that affect the entire spanning-tree performance.

Table C-1: Root Switch Variables Affecting STP

Variable	Description
Hello Time	Determines how often the switch broadcasts its hello message to other switches.
Maximum Age Timer	Measures the age of the received protocol information recorded for a port and ensures that this information is discarded when its age limit exceeds the value to the maximum age parameter recorded by the switch. The timeout value for this timer is the maximum age parameter of the switches.
Forward Delay Timer	Monitors the time spent by a port in the learning and listening states. The timeout value is the forward delay parameter of the switches.

BPDUs contain information about the transmitting switch and its ports, including switch and port Media Access Control (MAC) addresses, switch priority, port priority, and port cost. The Spanning-Tree Protocol uses this information to elect the root switch and root port for the switched network, as well as the root port and designated port for each switched segment.

Figure C-1 shows how BPDUs enable a Spanning-Tree Protocol topology.

Figure C-1: BPDUs Enabling a Stable Spanning-Tree Protocol Topology

Bridge Protocol Data Units

The stable active topology of a switched network is determined by the following:

The unique switch identifier (MAC address) associated with each switch.
The path cost to the root associated with each switch port.
The port identifier (MAC address) associated with each switch port.

Each configuration BPDU contains the following minimal information:

The unique identifier of the switch that the transmitting switch believes to be the root switch.
The cost of the path to the root from the transmitting port.
The identifier of the transmitting port.

The switch sends configuration BPDUs to communicate and compute the spanning-tree topology. A MAC frame conveying a BPDU sends the switch group address to the destination address field. All switches connected to the LAN on which the frame is transmitted receive the BPDU. BPDUs are not directly forwarded by the switch, but the information contained in the frame can be used to calculate a BPDU by the receiving switch, and, if the topology changes, instigate a BPDU transmission.

A BPDU exchange results in the following:

One switch is elected as the root switch.
The shortest distance to the root switch is calculated for each switch.
A designated switch is selected. This is the switch closest to the root switch through which frames will be forwarded to the root.
A port for each switch is selected. This is the port providing the best path from the switch to the root switch.
Ports included in the Spanning-Tree Protocol are selected.

Spanning-Tree Protocol Configuration

If all switches are enabled with default settings, the switch with the lowest MAC address in the network becomes the root switch. The network in Figure C-2 assumes that Switch A has the lowest MAC address and is therefore the root switch. However, due to traffic patterns, number of forwarding ports, or line types, Switch A might not be the ideal root switch. By increasing the priority (lowering the numerical priority number) of the ideal switch so that it then becomes the root switch, you force a Spanning-Tree Protocol recalculation to form a new, stable topology.

Figure C-2: Configuring a Stable Topology

When the stable Spanning-Tree Protocol topology is based on default parameters, the path between source and destination stations in a switched network might not be the most ideal. For instance, connecting higher speed links to a port that has a higher number than the current root port can cause a root-port change. The point is to make the fastest link the root port.

For example, assume that Port 2 on Switch B in Figure C-3 is a fiber-optic link, and that Port 1 on Switch B (a UTP link) is the root port. Network traffic might be more efficiently handled over the high-speed fiber-optic link. By changing the Port Priority parameter for Port 2 to a higher priority (lower numerical value) than Port 1, Port 2 becomes the root port. The same change can occur by changing the Port Cost parameter for Port 2 to a lower value than that of Port 1.

Figure C-3: Default Parameters Resulting in Lower Network Efficiency

Spanning-Tree Protocol Port States

Propagation delays can occur when protocol information is passed through a switched LAN. As a result, topology changes can take place at different times and at different places in a switched network. When a switch port transitions directly from non-participation in the stable topology to the forwarding state, it can create temporary data loops. Ports must wait for new topology information to propagate through the switched LAN before starting to forward frames. They must also allow the frame lifetime to expire for frames that have been forwarded using the old topology.

Each port on a switch using Spanning-Tree Protocol exists in one of the following five states:

Blocking
Listening
Learning
Forwarding
Disabled

A port moves through these five states as follows:

From initialization to blocking
From blocking to listening or to disabled
From listening to learning or to disabled
From learning to forwarding or to disabled
From forwarding to disabled

Figure C-4 illustrates how a port moves through the five states.

Figure C-4: Spanning-Tree Protocol Port States

You can modify each port state by using management software. When Spanning-Tree Protocol is enabled, every switch in the network goes through the blocking state and the transitory states of listening and learning at power up. If properly configured, the ports then stabilize to the forwarding or blocking state.

When the spanning-tree algorithm determines that a port should be placed in the forwarding state, the following occurs:

The port is put into the listening state while it waits for protocol information that suggests it should go to the blocking state.
The port waits for the expiration of a protocol timer that moves the port to the learning state.
In the learning state, the port continues to block frame forwarding as it learns station location information for the forwarding database.
The expiration of a protocol timer moves the port to the forwarding state, where both learning and forwarding are enabled.

Blocking State

A port in the blocking state does not participate in frame forwarding, as shown in Figure C-5. After initialization, a BPDU is sent to each port in the switch. A switch initially assumes it is the root until it exchanges BPDUs with other switches. This exchange establishes which switch in the network is really the root. If only one switch resides in the network, no exchange occurs, the forward delay timer expires, and the ports move to the listening state. A switch always enters the blocking state following switch initialization.

Figure C-5: Port States

A port in the blocking state performs as follows:

Discards frames received from the attached segment.
Discards frames switched from another port for forwarding.
Does not incorporate station location into its address database. (There is no learning at this point, so there is no address database update.)
Receives BPDUs and directs them to the system module.
Does not transmit BPDUs received from the system module.
Receives and responds to network management messages.

Listening State

The listening state is the first transitional state a port enters after the blocking state, when Spanning-Tree Protocol determines that the port should participate in frame forwarding. Learning is disabled in the listening state. Figure C-5 shows a port in the listening state.

A port in the listening state performs as follows:

Discards frames received from the attached segment.
Discards frames switched from another port for forwarding.
Does not incorporate station location into its address database. (There is no learning at this point, so there is no address database update.)
Receives BPDUs and directs them to the system module.
Processes BPDUs received from the system module.
Receives and responds to network management messages.

Learning State

A port in the learning state is preparing to participate in frame forwarding. This is the second transitional state through which a port moves in anticipation of frame forwarding. The port enters the learning state from the listening state through the operation of Spanning-Tree Protocol.

A port in the learning state performs as follows:

Discards frames received from the attached segment.
Discards frames switched from another port for forwarding.
Incorporates station location into its address database.
Receives BPDUs and directs them to the system module.
Receives, processes, and transmits BPDUs received from the system module.
Receives and responds to network management messages.

Forwarding State

A port in the forwarding state forwards frames, as shown in Figure C-5. The port enters the forwarding state from the learning state through the operation of Spanning-Tree Protocol.

A port in the forwarding state performs as follows:

Forwards frames received from the attached segment.
Forwards frames switched from another port for forwarding.
Incorporates station location information into its address database.
Receives BPDUs and directs them to the system module.
Processes BPDUs received from the system module.
Receives and responds to network management messages.

Caution Use the immediate-forwarding (portfast) mode only on ports connected to individual workstations to allow these ports to come up and go directly to the forwarding state, rather than having to go through the entire spanning-tree initialization process. To prevent illegal topologies, enable Spanning-Tree Protocol on ports connected to switches or other devices that forward messages.

Disabled State

A port in the disabled state does not participate in frame forwarding or the operation of Spanning-Tree Protocol, as shown in Figure C-6. A port in the disabled state is virtually nonoperational.

Figure C-6: Port 2 in Disabled State

A disabled port performs as follows:

Discards frames received from the attached segment.
Discards frames switched from another port for forwarding.
Does not incorporate station location into its address database. (There is no learning, so there is no address database update.)
Receives BPDUs, but does not direct them to the system module.
Does not receive BPDUs for transmission from the system module.
Receives and responds to network management message

VLANs and Trunking

sparky — Tue, 24 Feb 2009 11:55:00 +0000

Trunking

VLANs are local to each switch's database, and VLAN information is not passed between switches.
Trunk links provide VLAN identification for frames traveling between switches.
Cisco switches have two Ethernet trunking mechanisms: ISL and IEEE 802.1Q.
Certain types of switches can negotiate trunk links.
Trunks carry traffic from all VLANs to and from the switch by default but can be configured to carry only specified VLAN traffic.
Trunk links must be configured to allow trunking on each end of the link.

Enabling Trunking

Trunk links are required to pass VLAN information between switches. A port on a Cisco switch is either an access port or a trunk port. Access ports belong to a single VLAN and do not provide any identifying marks on the frames that are passed between switches. Access ports also carry traffic that comes from only the VLAN assigned to the port. A trunk port is by default a member of all the VLANs that exist on the switch and carry traffic for all those VLANs between the switches. To distinguish between the traffic flows, a trunk port must mark the frames with special tags as they pass between the switches. Trunking is a function that must be enabled on both sides of a link. If two switches are connected together, for example, both switch ports must be configured for trunking, and they must both be configured with the same tagging mechanism (ISL or 802.1Q).

To enable trunking between the switches, use the following steps:

Enable trunking on a port.

Enable the trunk:

COS

set trunk mod/port [auto |desirable| on | nonegotiate |off]

IOS

(global) interface type mod/port

(interface) switchport mode dynamic [auto| desirable]

(interface) switchport mode trunk

(interface) switchport nonegotiate

The most basic way to configure a trunk link is using the option on. This option enables the trunk and requires that you also specify a tagging mechanism for the trunk. For IOS devices, the command switchport mode trunk is equivalent to the set trunk mod/port on command. When specifying the option on, you must also choose a tagging mechanism (see Step 1b).

NOTE

Some IOS switches do not support Dynamic Trunking Protocol. For these switches, the only command that you can use to configure trunking is switchport mode trunk, which essentially turns trunking on.

Many Cisco switches employ an automatic trunking mechanism known as the Dynamic Trunking Protocol (DTP), which allows a trunk to be dynamically established between two switches. All COS switches and integrated IOS switches can use the DTP protocol to form a trunk link. The COS options auto, desirable, and on and the IOS options of dynamic auto, dynamic desirable, and trunk configure a trunk link using DTP. If one side of the link is configured to trunk and will send DTP signals, the other side of the link will dynamically begin to trunk if the options match correctly.

If you want to enable trunking and not send any DTP signaling, use the option nonegotiate for switches that support that function. If you want to disable trunking completely, use the off option for a COS switch or the no switchport mode trunk command on an IOS switch.

Table 6-2 shows the DTP signaling and the characteristics of each mode.

TIP

It is important to remember that not all switches support DTP and might not establish a trunk without intervention. Also remember that DTP offers no benefit when you are trunking with a non-Cisco switch. To eliminate any overhead associated with DTP, it is useful to use the nonegotiate option when DTP is not supported.

NOTE

When enabling trunking, it is not possible to specify a range of ports.

Table 6-2 Trunking Mode Characteristics

Trunking Mode	Characteristics
COS = on IOS = mode trunk	Trunking is on for these links. They will also send DTP signals that attempt to initiate a trunk with the other side. This will form a trunk with other ports in the states on, auto, or desirable that are running DTP. A port that is in on mode always tags frames sent out the port.
COS = desirable IOS = mode dynamic desirable	These links would like to become trunk links and will send DTP signals that attempt to initiate a trunk. They will only become trunk links if the other side responds to the DTP signal. This will form a trunk with other ports in the states on, auto, or desirable that are running DTP. This is the default mode for the 6000 running Supervisor IOS.
COS = auto IOS = mode dynamic auto	These links will only become trunk links if they receive a DTP signal from a link that is already trunking or desires to trunk. This will only form a trunk with other ports in the states on or desirable. This is the default mode for COS switches.
COS = nonegotiate IOS = mode nonegotiate	Sets trunking on and disables DTP. These will only become trunks with ports in on or nonegotiate mode.
COS = off IOS = no switchport mode trunk	This option sets trunking and DTP capabilities off. This is the recommended setting for any access port because it will prevent any dynamic establishments of trunk links.

NOTE

Cisco 2950 and 3500XL switches do not support DTP and are always in a mode similar to nonegotiate. If you turn trunking on for one of these devices, it will not negotiate with the other end of the link and requires that the other link be configured to on or nonegotiate.

Specify the encapsulation method:

COS

set trunk mod/port [negotiate | isl | dot1Q]

IOS

(global) interface type mod/port

(interface) switchport trunk encapsulation [negotiate | isl | dot1Q]

The other option when choosing a trunk link is the encapsulation method. For Layer 2 IOS switches, such as the 2900XL or the 3500XL, the default encapsulation method is isl. You can change from the default with the switchport trunk encapsulation command. For COS switches or integrated IOS switches, the default encapsulation is negotiate. This method signals between the trunked ports to choose an encapsulation method. (ISL is preferred over 802.1Q.) The negotiate option is valid for auto or desirable trunking modes only. If you choose on as the mode or if you want to force a particular method or if the other side of the trunk cannot negotiate the trunking type, you must choose the option isl or dot1Q to specify the encapsulation method.

NOTE

Not all switches allow you to negotiate a trunk encapsulation setting. The 2900XL and 3500XL trunks default to isl and you must use the switchport trunk encapsulation command to change the encapsulation type. The 2950 and some 4000 switches support only 802.1Q trunking and provide no options for changing the trunk type.
(Optional) Specify the native VLAN:

COS

set vlan number mod/port

IOS

(global) interface type mod/port

(interface) switchport trunk native vlan number

For switches running 802.1Q as the trunking mechanism, the native VLAN of each port on the trunk must match. By default all COS ports are in VLAN 1; and the native VLAN on the IOS devices is also configured for VLAN 1, so the native VLAN does match. If you choose to change the native VLAN, use the set vlan command for COS switches or the switchport trunk native vlan command for IOS switches to specify the native VLAN. Remember that the native VLAN must match on both sides of the trunk link for 802.1Q; otherwise the link will not work. If there is a native VLAN mismatch, Spanning Tree Protocol (STP) places the port in a port VLAN ID (PVID) inconsistent state and will not forward on the link.

NOTE

Cisco Discovery Protocol (CDP) version 2 passes native VLAN information between Cisco switches. If you have a native VLAN mismatch, you will see CDP error messages on the console output.

Specifying VLANs to Trunk

By default a trunk link carries all the VLANs that exist on the switch. This is because all VLANs are active on a trunk link; and as long as the VLAN is in the switch's local database, traffic for that VLAN is carried across the trunks. You can elect to selectively remove and add VLANs from a trunk link. To specify which VLANs are to be added or removed from a trunk link, use the following commands.

(Optional) Manually remove VLANs from a trunk link:

COS

clear trunk mod/port vlanlist

IOS

(global) interface type mod/port

(interface) switchport trunk allowed vlan remove vlanlist

By specifying VLANs in the vlanlist field of this command, the VLANs will not be allowed to travel across the trunk link until they are added back to the trunk using the command set trunk mod/port vlanlist or switchport trunk allowed vlan add vlanlist.

Verifying Trunks

After configuring a port for trunking, use one of the following commands to verify the VLAN port assignments:

COS

show trunk [mod] [mod/port]

IOS

(privileged) show interface type mod/port switchport

-OR-

show interfaces trunk

-OR-

show interface [mod] [interface_id] trunk

NOTE

The commands show interfaces trunk and show interface [mod] [interface_id] trunk are not available on all switches that run IOS.

Feature Example

In this example the switches Access_1 and Distribution_1 and Core_1 are connected as shown in Figure 6-2. 802.1Q trunking is configured in the on mode between Access_1 and Distribution_1 switches. ISL is configured in desirable mode on the Distribution_1 switch to the link connecting to the core. The core is configured for autotrunking mode and encapsulation negotiate. The trunk connected between the access switch is configured to only trunk for VLANs 5, 8, and 10. The trunk between the Distribution_1 and Core_1 is configured to carry only VLAN 1 and VLAN 10.

Figure 6-2 Network Diagram for Trunk Configuration on Access_1, Distribution_1, and Core_1

An example of the Catalyst OS configuration for Distribution_1 follows:

Distribution_1 (enable)>clear trunk 1/1 2-1001
Distribution_1 (enable)>set trunk 1/1 desirable isl 10
Distribution_1 (enable)>clear trunk 2/1 2-1001
Distribution_1 (enable)>set trunk 2/1 on dot1q 5,8,10

An example of the Catalyst OS configuration for Core_1 follows:

Core_1 (enable)>clear trunk 1/1 2-1001
Core_1 (enable)>set trunk 1/1 10

An example of the Supervisor IOS configuration for Core_1 follows:

Core_1(config)#interface gigabitethernet 1/1
Core_1(config-if)#switchport encapsulation negotiate
Core_1(config-if)#switchport mode dynamic auto
Core_1(config-if)#switchport trunk allowed vlan remove 2-1001
Core_1(config-if)#switchport trunk allowed vlan add 10
Core_1 (config-if)#end
Core_1#copy running-config startup-config

An example of the Layer 2 IOS configuration for Access_1 follows:

Access_1 (config)#interface gigabitethernet 0/1
Access_1 (config-if)#switchport mode trunk
Access_1 (config-if)#switchport trunk encapsulation dot1q
Access_1 (config-if)#switchport trunk allowed vlan remove 2-1001
Access_1 (config-if)#switchport trunk allowed vlan add 5,8,10
Access_1 (config-if)#end
Access_1#copy running-config startup-config

provided courtesy of Cisco Press.

VLAN Trunk Protocol - VTP

sparky — Fri, 13 Feb 2009 13:59:00 +0000

Understanding How VTP Version 3 Works Interaction with VTP Version 1 and VTP Version 2 (VTP Version 3)

Introduction

VLAN Trunk Protocol (VTP) reduces administration in a switched network. When you configure a new VLAN on one VTP server, the VLAN is distributed through all switches in the domain. This reduces the need to configure the same VLAN everywhere. VTP is a Cisco-proprietary protocol that is available on most of the Cisco Catalyst series products.

Note: This document does not cover VTP Version 3. VTP Version 3 differs from VTP Version 1 (V1) and Version 2 (V2), and it is only available on Catalyst OS (CatOS) 8.1(1) or later. VTP Version 3 incorporates many changes from VTP V1 and V2. Make certain that you understand the differences between VTP Version 3 and earlier versions before you alter your network configuration. Refer to one of these sections of Configuring VTP for more information:

Understanding How VTP Version 3 Works
Interaction with VTP Version 1 and VTP Version 2 (VTP Version 3)

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software or hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Understand VTP

VTP Messages in Detail

VTP packets are sent in either Inter-Switch Link (ISL) frames or in IEEE 802.1Q (dot1q) frames. These packets are sent to the destination MAC address 01-00-0C-CC-CC-CC with a logical link control (LLC) code of Subnetwork Access Protocol (SNAP) (AAAA) and a type of 2003 (in the SNAP header). This is the format of a VTP packet that is encapsulated in ISL frames:

Of course, you can have a VTP packet inside 802.1Q frames. In that case, the ISL header and cyclic redundancy check (CRC) is replaced by dot1q tagging.

Now consider the detail of a VTP packet. The format of the VTP header can vary, based on the type of VTP message. But, all VTP packets contain these fields in the header:

VTP protocol version: 1, 2, or 3
VTP message types:
- Summary advertisements
- Subset advertisement
- Advertisement requests
- VTP join messages
Management domain length
Management domain name

Configuration Revision Number

The configuration revision number is a 32-bit number that indicates the level of revision for a VTP packet. Each VTP device tracks the VTP configuration revision number that is assigned to it. Most of the VTP packets contain the VTP configuration revision number of the sender.

This information is used in order to determine whether the received information is more recent than the current version. Each time that you make a VLAN change in a VTP device, the configuration revision is incremented by one. In order to reset the configuration revision of a switch, change the VTP domain name, and then change the name back to the original name.

Summary Advertisements

By default, Catalyst switches issue summary advertisements in five-minute increments. Summary advertisements inform adjacent Catalysts of the current VTP domain name and the configuration revision number.

When the switch receives a summary advertisement packet, the switch compares the VTP domain name to its own VTP domain name. If the name is different, the switch simply ignores the packet. If the name is the same, the switch then compares the configuration revision to its own revision. If its own configuration revision is higher or equal, the packet is ignored. If it is lower, an advertisement request is sent.

This list clarifies what the fields means in the summary advertisement packet:

The Followers field indicates that this packet is followed by a Subset Advertisement packet.
The Updater Identity is the IP address of the switch that is the last to have incremented the configuration revision.
The Update Timestamp is the date and time of the last increment of the configuration revision.
Message Digest 5 (MD5) carries the VTP password, if MD5 is configured and used to authenticate the validation of a VTP update.

Subset Advertisements

When you add, delete, or change a VLAN in a Catalyst, the server Catalyst where the changes are made increments the configuration revision and issues a summary advertisement. One or several subset advertisements follow the summary advertisement. A subset advertisement contains a list of VLAN information. If there are several VLANs, more than one subset advertisement can be required in order to advertise all the VLANs.

This formatted example shows that each VLAN information field contains information for a different VLAN. It is ordered so that lowered-valued ISL VLAN IDs occur first:

Most of the fields in this packet are easy to understand. These are two clarifications:

Code—The format for this is 0x02 for subset advertisement.
Sequence number—This is the sequence of the packet in the stream of packets that follow a summary advertisement. The sequence starts with 1.

Advertisement Requests

A switch needs a VTP advertisement request in these situations:

The switch has been reset.
The VTP domain name has been changed.
The switch has received a VTP summary advertisement with a higher configuration revision than its own.

Upon receipt of an advertisement request, a VTP device sends a summary advertisement. One or more subset advertisements follow the summary advertisement. This is an example:

Code—The format for this is 0x03 for an advertisement request.
Start-Value—This is used in cases in which there are several subset advertisements. If the first (n) subset advertisement has been received and the subsequent one (n+1) has not been received, the Catalyst only requests advertisements from the (n+1)th one.

Other VTP Options

VTP Modes

You can configure a switch to operate in any one of these VTP modes:

Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.
Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
Transparent—VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements, but transparent switches do forward VTP advertisements that they receive out their trunk ports in VTP Version 2.
Off (configurable only in CatOS switches)—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.

VTP V2

VTP V2 is not much different than VTP V1. The major difference is that VTP V2 introduces support for Token Ring VLANs. If you use Token Ring VLANs, you must enable VTP V2. Otherwise, there is no reason to use VTP V2.

VTP Password

If you configure a password for VTP, you must configure the password on all switches in the VTP domain. The password must be the same password on all those switches. The VTP password that you configure is translated by algorithm into a 16-byte word (MD5 value) that is carried in all summary-advertisement VTP packets.

VTP Pruning

VTP ensures that all switches in the VTP domain are aware of all VLANs. However, there are occasions when VTP can create unnecessary traffic. All unknown unicasts and broadcasts in a VLAN are flooded over the entire VLAN. All switches in the network receive all broadcasts, even in situations in which few users are connected in that VLAN. VTP pruning is a feature that you use in order to eliminate or prune this unnecessary traffic.

Broadcast traffic in a switched network without pruning

This figure shows a switched network without VTP pruning enabled. Port 1 on Switch A and Port 2 on Switch D are assigned to the Red VLAN. If a broadcast is sent from the host connected to Switch A, Switch A floods the broadcast and every switch in the network receives it, even though Switches C, E, and F have no ports in the Red VLAN.

Broadcast traffic in a switched network with pruning

This figure shows the same switched network with VTP pruning enabled. The broadcast traffic from Switch A is not forwarded to Switches C, E, and F because traffic for the Red VLAN has been pruned on the links shown (Port 5 on Switch B and Port 4 on Switch D).

When VTP pruning is enabled on a VTP server, pruning is enabled for the entire management domain. Making VLANs pruning-eligible or pruning-ineligible affects pruning eligibility for those VLANs on that trunk only (not on all switches in the VTP domain). VTP pruning takes effect several seconds after you enable it. VTP pruning does not prune traffic from VLANs that are pruning-ineligible. VLAN 1 and VLANs 1002 to 1005 are always pruning-ineligible; traffic from these VLANs cannot be pruned. Extended-range VLANs (VLAN IDs greater than 1005) are also pruning-ineligible.

Use VTP in a Network

By default, all switches are configured to be VTP servers. This configuration is suitable for small-scale networks in which the size of the VLAN information is small and the information is easily stored in all switches (in NVRAM). In a large network, the network administrator must make a judgment call at some point, when the NVRAM storage that is necessary is wasteful because it is duplicated on every switch. At this point, the network administrator must choose a few well-equipped switches and keep them as VTP servers. Everything else that participates in VTP can be turned into a client. The number of VTP servers should be chosen in order to provide the degree of redundancy that is desired in the network.

Notes:

If a switch is configured as a VTP server without a VTP domain name, you cannot configure a VLAN on the switch.
If a new Catalyst is attached in the border of two VTP domains, the new Catalyst keeps the domain name of the first switch that sends it a summary advertisement. The only way to attach this switch to another VTP domain is to manually set a different VTP domain name.
Dynamic Trunking Protocol (DTP) sends the VTP domain name in a DTP packet. Therefore, if you have two ends of a link that belong to different VTP domains, the trunk does not come up if you use DTP. In this special case, you must configure the trunk mode as on or nonegotiate, on both sides, in order to allow the trunk to come up without DTP negotiation agreement.
If the domain has a single VTP server and it crashes, the best and easiest way to restore the operation is to change any of the VTP clients in that domain to a VTP server. The configuration revision is still the same in the rest of the clients, even if the server crashes. Therefore, VTP works properly in the domain.

Conclusion

There are some disadvantages to the use of VTP. You must balance the ease of VTP administration against the inherent risk of a large STP domain and the potential instability and risks of STP. The greatest risk is an STP loop through the entire campus. When you use VTP, there are two things to which you must pay close attention:

Remember the configuration revision and how to reset it each time that you insert a new switch in your network so that you do not bring down the entire network.
Avoid as much as possible to have a VLAN that spans the entire network.

VLANs

sparky — Tue, 10 Feb 2009 09:46:00 +0000

Introduction

A Local Area Network (LAN) was originally defined as a network of computers located within the same area. Today, Local Area Networks are defined as a single broadcast domain. This means that if a user broadcasts information on his/her LAN, the broadcast will be received by every other user on the LAN. Broadcasts are prevented from leaving a LAN by using a router. The disadvantage of this method is routers usually take more time to process incoming data compared to a bridge or a switch. More importantly, the formation of broadcast domains depends on the physical connection of the devices in the network. Virtual Local Area Networks (VLAN's) were developed as an alternative solution to using routers to contain broadcast traffic.

In Section 2, we define VLAN's and examine the difference between a LAN and a VLAN. This is followed by a discussion on the advantages VLAN's introduce to a network in Section 3. Finally, we explain how VLAN's work based on the current draft standards in Section 4.

2.0 What are VLAN's?

In a traditional LAN, workstations are connected to each other by means of a hub or a repeater. These devices propagate any incoming data throughout the network. However, if two people attempt to send information at the same time, a collision will occur and all the transmitted data will be lost. Once the collision has occurred, it will continue to be propagated throughout the network by hubs and repeaters. The original information will therefore need to be resent after waiting for the collision to be resolved, thereby incurring a significant wastage of time and resources. To prevent collisions from traveling through all the workstations in the network, a bridge or a switch can be used. These devices will not forward collisions, but will allow broadcasts (to every user in the network) and multicasts (to a pre-specified group of users) to pass through. A router may be used to prevent broadcasts and multicasts from traveling through the network.

The workstations, hubs, and repeaters together form a LAN segment. A LAN segment is also known as a collision domain since collisions remain within the segment. The area within which broadcasts and multicasts are confined is called a broadcast domain or LAN. Thus a LAN can consist of one or more LAN segments. Defining broadcast and collision domains in a LAN depends on how the workstations, hubs, switches, and routers are physically connected together. This means that everyone on a LAN must be located in the same area (see Figure1).

Figure 1: Physical view of a LAN.

VLAN's allow a network manager to logically segment a LAN into different broadcast domains (see Figure2). Since this is a logical segmentation and not a physical one, workstations do not have to be physically located together. Users on different floors of the same building, or even in different buildings can now belong to the same LAN.

Physical View

Logical View

Figure 2: Physical and logical view of a VLAN.

VLAN's also allow broadcast domains to be defined without using routers. Bridging software is used instead to define which workstations are to be included in the broadcast domain. Routers would only have to be used to communicate between two VLAN's [ Hein et al].

3.0 Why use VLAN's?

VLAN's offer a number of advantages over traditional LAN's. They are:

1) Performance

In networks where traffic consists of a high percentage of broadcasts and multicasts, VLAN's can reduce the need to send such traffic to unnecessary destinations. For example, in a broadcast domain consisting of 10 users, if the broadcast traffic is intended only for 5 of the users, then placing those 5 users on a separate VLAN can reduce traffic [ Passmore et al (3Com report)].

Compared to switches, routers require more processing of incoming traffic. As the volume of traffic passing through the routers increases, so does the latency in the routers, which results in reduced performance. The use of VLAN's reduces the number of routers needed, since VLAN's create broadcast domains using switches instead of routers.

2) Formation of Virtual Workgroups

Nowadays, it is common to find cross-functional product development teams with members from different departments such as marketing, sales, accounting, and research. These workgroups are usually formed for a short period of time. During this period, communication between members of the workgroup will be high. To contain broadcasts and multicasts within the workgroup, a VLAN can be set up for them. With VLAN's it is easier to place members of a workgroup together. Without VLAN's, the only way this would be possible is to physically move all the members of the workgroup closer together.

However, virtual workgroups do not come without problems. Consider the situation where one user of the workgroup is on the fourth floor of a building, and the other workgroup members are on the second floor. Resources such as a printer would be located on the second floor, which would be inconvenient for the lone fourth floor user.

Another problem with setting up virtual workgroups is the implementation of centralized server farms, which are essentially collections of servers and major resources for operating a network at a central location. The advantages here are numerous, since it is more efficient and cost-effective to provide better security, uninterrupted power supply, consolidated backup, and a proper operating environment in a single area than if the major resources were scattered in a building. Centralized server farms can cause problems when setting up virtual workgroups if servers cannot be placed on more than one VLAN. In such a case, the server would be placed on a single VLAN and all other VLAN's trying to access the server would have to go through a router; this can reduce performance [Netreference Inc. article].

3) Simplified Administration

Seventy percent of network costs are a result of adds, moves, and changes of users in the network [ Buerger]. Every time a user is moved in a LAN, recabling, new station addressing, and reconfiguration of hubs and routers becomes necessary. Some of these tasks can be simplified with the use of VLAN's. If a user is moved within a VLAN, reconfiguration of routers is unnecessary. In addition, depending on the type of VLAN, other administrative work can be reduced or eliminated [ Cisco white paper]. However the full power of VLAN's will only really be felt when good management tools are created which can allow network managers to drag and drop users into different VLAN's or to set up aliases.

Despite this saving, VLAN's add a layer of administrative complexity, since it now becomes necessary to manage virtual workgroups [ Passmore et al (3Com report)].

4) Reduced Cost

VLAN's can be used to create broadcast domains which eliminate the need for expensive routers.

5) Security

Periodically, sensitive data may be broadcast on a network. In such cases, placing only those users who can have access to that data on a VLAN can reduce the chances of an outsider gaining access to the data. VLAN's can also be used to control broadcast domains, set up firewalls, restrict access, and inform the network manager of an intrusion [ Passmore et al (3Com report)].

4.0 How VLAN's work

When a LAN bridge receives data from a workstation, it tags the data with a VLAN identifier indicating the VLAN from which the data came. This is called explicit tagging. It is also possible to determine to which VLAN the data received belongs using implicit tagging. In implicit tagging the data is not tagged, but the VLAN from which the data came is determined based on other information like the port on which the data arrived. Tagging can be based on the port from which it came, the source Media Access Control (MAC) field, the source network address, or some other field or combination of fields. VLAN's are classified based on the method used. To be able to do the tagging of data using any of the methods, the bridge would have to keep an updated database containing a mapping between VLAN's and whichever field is used for tagging. For example, if tagging is by port, the database should indicate which ports belong to which VLAN. This database is called a filtering database. Bridges would have to be able to maintain this database and also to make sure that all the bridges on the LAN have the same information in each of their databases. The bridge determines where the data is to go next based on normal LAN operations. Once the bridge determines where the data is to go, it now needs to determine whether the VLAN identifier should be added to the data and sent. If the data is to go to a device that knows about VLAN implementation (VLAN-aware), the VLAN identifier is added to the data. If it is to go to a device that has no knowledge of VLAN implementation (VLAN-unaware), the bridge sends the data without the VLAN identifier.

In order to understand how VLAN's work, we need to look at the types of VLAN's, the types of connections between devices on VLAN's, the filtering database which is used to send traffic to the correct VLAN, and tagging, a process used to identify the VLAN originating the data.

VLAN Standard: IEEE 802.1Q Draft Standard

There has been a recent move towards building a set of standards for VLAN products. The Institute of Electrical and Electronic Engineers (IEEE) is currently working on a draft standard 802.1Q for VLAN's. Up to this point, products have been proprietary, implying that anyone wanting to install VLAN's would have to purchase all products from the same vendor. Once the standards have been written and vendors create products based on these standards, users will no longer be confined to purchasing products from a single vendor. The major vendors have supported these standards and are planning on releasing products based on them. It is anticipated that these standards will be ratified later this year.

4.1 Types of VLAN's

VLAN membership can be classified by port, MAC address, and protocol type.

1) Layer 1 VLAN: Membership by Port

Membership in a VLAN can be defined based on the ports that belong to the VLAN. For example, in a bridge with four ports, ports 1, 2, and 4 belong to VLAN 1 and port 3 belongs to VLAN 2 (see Figure3).

Port	VLAN
1	1
2	1
3	2
4	1

Figure3: Assignment of ports to different VLAN's.

The main disadvantage of this method is that it does not allow for user mobility. If a user moves to a different location away from the assigned bridge, the network manager must reconfigure the VLAN.

2) Layer 2 VLAN: Membership by MAC Address

Here, membership in a VLAN is based on the MAC address of the workstation. The switch tracks the MAC addresses which belong to each VLAN (see Figure4). Since MAC addresses form a part of the workstation's network interface card, when a workstation is moved, no reconfiguration is needed to allow the workstation to remain in the same VLAN. This is unlike Layer 1 VLAN's where membership tables must be reconfigured.

MAC Address	VLAN
1212354145121	1
2389234873743	2
3045834758445	2
5483573475843	1

Figure4: Assignment of MAC addresses to different VLAN's.

The main problem with this method is that VLAN membership must be assigned initially. In networks with thousands of users, this is no easy task. Also, in environments where notebook PC's are used, the MAC address is associated with the docking station and not with the notebook PC. Consequently, when a notebook PC is moved to a different docking station, its VLAN membership must be reconfigured.

3) Layer 2 VLAN: Membership by Protocol Type

VLAN membership for Layer 2 VLAN's can also be based on the protocol type field found in the Layer 2 header (see Figure5).

Protocol	VLAN
IP	1
IPX	2

Figure5: Assignment of protocols to different VLAN's.

4) Layer 3 VLAN: Membership by IP Subnet Address

Membership is based on the Layer 3 header. The network IP subnet address can be used to classify VLAN membership (see Figure 6).

IP Subnet	VLAN
23.2.24	1
26.21.35	2

Figure6: Assignment of IP subnet addresses to different VLAN's.

Although VLAN membership is based on Layer 3 information, this has nothing to do with network routing and should not be confused with router functions. In this method, IP addresses are used only as a mapping to determine membership in VLAN's. No other processing of IP addresses is done.

In Layer 3 VLAN's, users can move their workstations without reconfiguring their network addresses. The only problem is that it generally takes longer to forward packets using Layer 3 information than using MAC addresses.

5) Higher Layer VLAN's

It is also possible to define VLAN membership based on applications or service, or any combination thereof. For example, file transfer protocol (FTP) applications can be executed on one VLAN and telnet applications on another VLAN.

The 802.1Q draft standard defines Layer 1 and Layer 2 VLAN's only. Protocol type based VLAN's and higher layer VLAN's have been allowed for, but are not defined in this standard. As a result, these VLAN's will remain proprietary.

4.2 Types of Connections

Devices on a VLAN can be connected in three ways based on whether the connected devices are VLAN-aware or VLAN-unaware. Recall that a VLAN-aware device is one which understands VLAN memberships (i.e. which users belong to a VLAN) and VLAN formats.

1) Trunk Link

All the devices connected to a trunk link, including workstations, must be VLAN-aware. All frames on a trunk link must have a special header attached. These special frames are called tagged frames (see Figure7).

Figure7: Trunk link between two VLAN-aware bridges.

2) Access Link

An access link connects a VLAN-unaware device to the port of a VLAN-aware bridge. All frames on access links must be implicitly tagged (untagged) (see Figure8). The VLAN-unaware device can be a LAN segment with VLAN-unaware workstations or it can be a number of LAN segments containing VLAN-unaware devices (legacy LAN).

Figure 8: Access link between a VLAN-aware bridge and a VLAN-unaware device.

3) Hybrid Link

This is a combination of the previous two links. This is a link where both VLAN-aware and VLAN-unaware devices are attached (see Figure9). A hybrid link can have both tagged and untagged frames, but allthe frames for a specific VLAN must be either tagged or untagged.

Figure9: Hybrid link containing both VLAN-aware and VLAN-unaware devices.

It must also be noted that the network can have a combination of all three types of links.

4.3 Frame Processing

A bridge on receiving data determines to which VLAN the data belongs either by implicit or explicit tagging. In explicit tagging a tag header is added to the data. The bridge also keeps track of VLAN members in a filtering database which it uses to determine where the data is to be sent. Following is an explanation of the contents of the filtering database and the format and purpose of the tag header [802.1Q].

1) Filtering Database

Membership information for a VLAN is stored in a filtering database. The filtering database consists of the following types of entries:

i) Static Entries

Static information is added, modified, and deleted by management only. Entries are not automatically removed after some time (ageing), but must be explicitly removed by management. There are two types of static entries:

a) Static Filtering Entries: which specify for every port whether frames to be sent to a specific MAC address or group address and on a specific VLAN should be forwarded or discarded, or should follow the dynamic entry, and

b) Static Registration Entries: which specify whether frames to be sent to a specific VLAN are to be tagged or untagged and which ports are registered for that VLAN.

ii) Dynamic Entries

Dynamic entries are learned by the bridge and cannot be created or updated by management. The learning process observes the port from which a frame, with a given source address and VLAN ID (VID), is received, and updates the filtering database. The entry is updated only if all the following three conditions are satisfied:

a) this port allows learning,

b) the source address is a workstation address and not a group address, and

c) there is space available in the database.

Entries are removed from the database by the ageing out process where, after a certain amount of time specified by management (10 sec --- 1000000 sec), entries allow automatic reconfiguration of the filtering database if the topology of the network changes. There are three types of dynamic entries:

a) Dynamic Filtering Entries: which specify whether frames to be sent to a specific MAC address and on a certain VLAN should be forwarded or discarded.

b) Group Registration Entries: which indicate for each port whether frames to be sent to a group MAC address and on a certain VLAN should be filtered or discarded. These entries are added and deleted using Group Multicast Registration Protocol (GMRP). This allows multicasts to be sent on a single VLAN without affecting other VLAN's.

c) Dynamic Registration Entries: which specify which ports are registered for a specific VLAN. Entries are added and deleted using GARP VLAN Registration Protocol (GVRP), where GARP is the Generic Attribute Registration Protocol.

GVRP is used not only to update dynamic registration entries, but also to communicate the information to other VLAN-aware bridges.

In order for VLAN's to forward information to the correct destination, all the bridges in the VLAN should contain the same information in their respective filtering databases. GVRP allows both VLAN-aware workstations and bridges to issue and revoke VLAN memberships. VLAN-aware bridges register and propagate VLAN membership to all ports that are a part of the active topology of the VLAN. The active topology of a network is determined when the bridges are turned on or when a change in the state of the current topology is perceived.

The active topology is determined using a spanning tree algorithm which prevents the formation of loops in the network by disabling ports. Once an active topology for the network (which may contain several VLAN's) is obtained, the bridges determine an active topology for each VLAN. This may result in a different topology for each VLAN or a common one for several VLAN's. In either case, the VLAN topology will be a subset of the active topology of the network (see Figure 10).

Figure10: Active topology of network and VLAN A using spanning tree algorithm.

2) Tagging

When frames are sent across the network, there needs to be a way of indicating to which VLAN the frame belongs, so that the bridge will forward the frames only to those ports that belong to that VLAN, instead of to all output ports as would normally have been done. This information is added to the frame in the form of a tag header. In addition, the tag header:

i) allows user priority information to be specified,

ii) allows source routing control information to be specified, and

iii) indicates the format of MAC addresses.

Frames in which a tag header has been added are called tagged frames. Tagged frames convey the VLAN information across the network.

The tagged frames that are sent across hybrid and trunk links contain a tag header. There are two formats of the tag header:

i) Ethernet Frame Tag Header: The ethernet frame tag header (see Figure11) consists of a tag protocol identifier (TPID) and tag control information (TCI).

Figure11: Ethernet frame tag header.

ii) Token Ring and Fiber Distributed Data Interface (FDDI) tag header: The tag headers for both token ring and FDDI networks consist of a SNAP-encoded TPID and TCI.

Figure12: Token ring and FDDI tag header.

TPID is the tag protocol identifier which indicates that a tag header is following and TCI (see Figure 13) contains the user priority, canonical format indicator (CFI), and the VLAN ID.

Figure13: Tag control information (TCI).

User priority is a 3 bit field which allows priority information to be encoded in the frame. Eight levels of priority are allowed, where zero is the lowest priority and seven is the highest priority. How this field is used is described in the supplement 802.1p.

The CFI bit is used to indicate that all MAC addresses present in the MAC data field are in canonical format. This field is interpreted differently depending on whether it is an ethernet-encoded tag header or a SNAP-encoded tag header. In SNAP-encoded TPID the field indicates the presence or absence of the canonical format of addresses. In ethernet-encoded TPID, it indicates the presence of the Source-Routing Information (RIF) field after the length field. The RIF field indicates routing on ethernet frames.

The VID field is used to uniquely identify the VLAN to which the frame belongs. There can be a maximum of (2 ¹²- 1) VLAN's. Zero is used to indicate no VLAN ID, but that user priority information is present. This allows priority to be encoded in non-priority LAN's.

5.0 Summary

As we have seen there are significant advances in the field of networks in the form of VLAN's which allow the formation of virtual workgroups, better security, improved performance, simplified administration, and reduced costs. VLAN's are formed by the logical segmentation of a network and can be classified into Layer1, 2, 3 and higher layers. Only Layer 1 and 2 are specified in the draft standard 802.1Q. Tagging and the filtering database allow a bridge to determine the source and destination VLAN for received data. VLAN's if implemented effectively, show considerable promise in future networking solutions.

Article courtesy of Suba Varadarajan (varadarajan.5@osu.edu, 1997)

Configuring Switch Security

sparky — Tue, 27 Jan 2009 11:20:00 +0000

Understand the basics

In its most basic form, the Port Security feature remembers the Ethernet MAC address connected to the switch port and allows only that MAC address to communicate on that port. If any other MAC address tries to communicate through the port, port security will disable the port. Most of the time, network administrators configure the switch to send a SNMP trap to their network monitoring solution that the port's disabled for security reasons.

Of course, implementing any security solution always involves a trade-off—most often, you trade increased security for less convenience. When using port security, you can prevent devices from accessing the network, which increases security.

However, as you know, there's usually a downside. In this case, it's that the network administrator is the only one who can "unlock" the port, which can cause problems when there are legitimate reasons to change out devices.

Configure port security

Configuring the Port Security feature is relatively easy. In its simplest form, port security requires going to an already enabled switch port and entering the port-securityInterface Mode command. Here's an example:

Switch)# config t
Switch(config)# int fa0/18
Switch(config-if)# switchport port-security ?
  aging           Port-security aging commands
  mac-address     Secure mac address
  maximum         Max secure addresses
  violation       Security violation mode
  

Switch(config-if)# switchport port-security 
Switch(config-if)#^Z

By entering the most basic command to configure port security, we accepted the default settings of only allowing one MAC address, determining that MAC address from the first device that communicates on this switch port, and shutting down that switch port if another MAC address attempts to communicate via the port. But you don't have to accept the defaults.

Know your options

As you can see in the example, there are a number of other port security commands that you can configure. Here are some of your options:

switchport port-security maximum {max # of MAC addresses allowed}: You can use this option to allow more than the default number of MAC addresses, which is one. For example, if you had a 12-port hub connected to this switch port, you would want to allow 12 MAC addresses—one for each device. The maximum number of secure MAC addresses per port is 132.
switchport port-security violation {shutdown | restrict | protect}: This command tells the switch what to do when the number of MAC addresses on the port has exceeded the maximum. The default is to shut down the port. However, you can also choose to alert the network administrator (i.e., restrict) or only allow traffic from the secure port and drop packets from other MAC addresses (i.e., protect).
switchport port-security mac-address {MAC address}: You can use this option to manually define the MAC address allowed for this port rather than letting the port dynamically determine the MAC address.

Of course, you can also configure port security on a range of ports. Here's an example:

Switch)# config t
Switch(config)# int range fastEthernet 0/1 - 24  
Switch(config-if)# switchport port-security

However, you need to be very careful with this option if you enter this command on an uplink port that goes to more than one device. As soon as the second device sends a packet, the entire port will shut down.

View the status of port security

Once you've configured port security and the Ethernet device on that port has sent traffic, the switch will record the MAC address and secure the port using that address. To find out the status of port security on the switch, you can use the show port-security address and show port-security interface commands. Below are examples for each command's output:

Switch# show port-security address         
          Secure Mac Address Table
-------------------------------------------------------------------
Vlan    Mac Address       Type                Ports   Remaining Age
                                                         (mins)    
----    -----------       ----                -----   -------------
   1    0004.00d5.285d    SecureDynamic       Fa0/18       -
-------------------------------------------------------------------
Total Addresses in System (excluding one mac per port)     : 0
Max Addresses limit in System (excluding one mac per port) : 1024

Switch# show port-security interface fa0/18
Port Security                        : Enabled
Port Status                          : Secure-up
Violation Mode                       : Shutdown
Aging Time                           : 0 mins
Aging Type                           : Absolute
SecureStatic Address Aging           : Disabled
Maximum MAC Addresses                : 1
Total MAC Addresses                  : 1
Configured MAC Addresses             : 0
Sticky MAC Addresses                 : 0
Last Source Address                  : 0004.00d5.285d
Security Violation Count             : 0

Switch#

Article courtesy of Techrepublic.com

Features of the Cisco Catalyst Switch

sparky — Wed, 21 Jan 2009 10:01:00 +0000

The features of Cisco Catalyst Switches

Now that you know which switch features are used at which layer in a hierarchical network, you will learn about the Cisco switches that are applicable for each layer in the hierarchical network model. Today, you cannot simply select a Cisco switch by considering the size of a business. A small business with 12 employees might be integrated into the network of a large multinational enterprise and require all of the advanced LAN services available at the corporate head office. The following classification of Cisco switches within the hierarchical network model represents a starting point for your deliberations on which switch is best for a given application. The classification presented reflects how you might see the range of Cisco switches if you were a multinational enterprise. For example, the port densities of the Cisco 6500 switch only makes sense as an access layer switch where there are many hundreds of users in one area, such as the floor of a stock exchange. If you think of the needs of a medium-sized business, a switch that is shown as an access layer switch, the Cisco 3560 for example, could be used as a distribution layer switch if it met the criteria determined by the network designer for that application.

Cisco has seven switch product lines. Each product line offers different characteristics and features, allowing you to find the right switch to meet the functional requirements of your network. The Cisco switch product lines are:

Catalyst Express 500
Catalyst 2960
Catalyst 3560
Catalyst 3750
Catalyst 4500
Catalyst 4900
Catalyst 6500

Catalyst Express 500

The Catalyst Express 500 is Cisco's entry-layer switch. It offers the following:

Forwarding rates from 8.8 Gb/s to 24 Gb/s
Layer 2 port security
Web-based management
Converged data/IP communications support

This switch series is appropriate for access layer implementations where high port density is not required. The Cisco Catalyst Express 500 series switches are scaled for small business environments ranging from 20 to 250 employees. The Catalyst Express 500 series switches are available in different fixed configurations:

Fast Ethernet and Gigabit Ethernet connectivity
Up to 24 10/100 ports with optional PoE or 12 10/100/1000 ports

Catalyst Express 500 series switches do not allow management through the Cisco IOS CLI. They are managed using a built-in web management interface, the Cisco Network Assistant or the new Cisco Configuration Manager developed specifically for the Catalyst Express 500 series switches. The Catalyst Express does not support console access.

To learn more about the Cisco Express 500 series of switches, go to http://www.cisco.com/en/US/products/ps6545/index.html.

Catalyst 2960

The Catalyst 2960 series switches enable entry-layer enterprise, medium-sized, and branch office networks to provide enhanced LAN services. The Catalyst 2960 series switches are appropriate for access layer implementations where access to power and space is limited. The CCNA Exploration 3 LAN Switching and Wireless labs are based on the features of the Cisco 2960 switch.

The Catalyst 2960 series switches offers the following:

Forwarding rates from 16 Gb/s to 32 Gb/s
Multilayered switching
QoS features to support IP communications
Access control lists (ACLs)
Fast Ethernet and Gigabit Ethernet connectivity
Up to 48 10/100 ports or 10/100/1000 ports with additional dual purpose gigabit uplinks

The Catalyst 2960 series of switches do not support PoE.

The Catalyst 2960 series supports the Cisco IOS CLI, integrated web management interface, and Cisco Network Assistant. This switch series supports console and auxiliary access to the switch.

To learn more about the Catalyst 2960 series of switches, visit http://www.cisco.com/en/US/products/ps6406/index.html.

Catalyst 3560

The Cisco Catalyst 3560 series is a line of enterprise-class switches that include support for PoE, QoS, and advanced security features such as ACLs. These switches are ideal access layer switches for small enterprise LAN access or branch-office converged network environments.

The Cisco Catalyst 3560 Series supports forwarding rates of 32 Gb/s to 128 Gb/s (Catalyst 3560-E switch series).

The Catalyst 3560 series switches are available in different fixed configurations:

Fast Ethernet and Gigabit Ethernet connectivity
Up to 48 10/100/1000 ports, plus four small form-factor pluggable (SFP) ports
Optional 10 Gigabit Ethernet connectivity in the Catalyst 3560-E models
Optional Integrated PoE (Cisco pre-standard and IEEE 802.3af); up to 24 ports with 15.4 watts or 48 ports with 7.3 watts

To learn more about the Catalyst 3560 series of switches, visit http://www.cisco.com/en/US/products/hw/switches/ps5528/index.html.

Catalyst 3750

The Cisco Catalyst 3750 series of switches are ideal for access layer switches in midsize organizations and enterprise branch offices. This series offers forwarding rates from 32 Gb/s to 128 Gb/s (Catalyst 3750-E switch series). The Catalyst 3750 series supports Cisco StackWise technology. StackWise technology allows you to interconnect up to nine physical Catalyst 3750 switches into one logical switch using a high-performance (32 Gb/s), redundant, backplane connection.

The Catalyst 3750 series switches are available in different stackable fixed configurations:

Fast Ethernet and Gigabit Ethernet connectivity
Up to 48 10/100/1000 ports, plus four SFP ports
Optional 10 Gigabit Ethernet connectivity in the Catalyst 3750-E models
Optional Integrated PoE (Cisco pre-standard and IEEE 802.3af); up to 24 ports with 15.4 watts or 48 ports with 7.3 watts

To learn more about the Catalyst 3750 series of switches, visit http://www.cisco.com/en/US/products/hw/switches/ps5023/index.html.

Catalyst 4500

The Catalyst 4500 is the first midrange modular switching platform offering multilayer switching for enterprises, small- to medium-sized businesses, and service providers.

With forwarding rates up to 136 Gb/s, the Catalyst 4500 series is capable of managing traffic at the distribution layer. The modular capability of the Catalyst 4500 series allows for very high port densities through the addition of switch port line cards to its modular chassis. The Catalyst 4500 series offers multilayer QoS and sophisticated routing functions.

The Catalyst 4500 series switches are available in different modular configurations:

Modular 3, 6, 7, and 10 slot chassis offering different layers of scalability
High port density: up to 384 Fast Ethernet or Gigabit Ethernet ports available in copper or fiber with 10 Gigabit uplinks
PoE (Cisco pre-standard and IEEE 802.3af)
Dual, hot-swappable internal AC or DC power supplies
Advanced hardware-assisted IP routing capabilities

To learn more about the Catalyst 4500 series of switches, visit http://www.cisco.com/en/US/products/hw/switches/ps4324/index.html.

Catalyst 4900

The Catalyst 4900 series switches are designed and optimized for server switching by allowing very high forwarding rates. The Cisco Catalyst 4900 is not a typical access layer switch. It is a specialty access layer switch designed for data center deployments where many servers may exist in close proximity. This switch series supports dual, redundant power supplies and fans that can be swapped out while the switch is still running. This allows the switches to achieve higher availability, which is critical in data center deployments.

The Catalyst 4900 series switches support advanced QoS features, making them ideal candidates for the back-end IP telephony hardware. Catalyst 4900 series switches do not support the StackWise feature of the Catalyst 3750 series nor do they support PoE.

The Catalyst 4900 series switches are available in different fixed configurations:

Up to 48 10/100/1000 ports with four SFP ports or 48 10/100/1000 ports with two 10GbE ports
Dual, hot-swappable internal AC or DC power supplies
Hot-swappable fan trays

To learn more about the Catalyst 4900 series of switches, visit http://www.cisco.com/en/US/products/ps6021/index.html.

Catalyst 6500

The Catalyst 6500 series modular switch is optimized for secure, converged voice, video, and data networks. The Catalyst 6500 is capable of managing traffic at the distribution and core layers. The Catalyst 6500 series is the highest performing Cisco switch, supporting forwarding rates up to 720 Gb/s. The Catalyst 6500 is ideal for very large network environments found in enterprises, medium-sized businesses, and service providers.

The Catalyst 6500 series switches are available in different modular configurations:

Modular 3, 4, 6, 9, and 13 slot chassis
LAN/WAN service modules
PoE up to 420 IEEE 802.3af Class 3 (15.4W) PoE devices
Up to 1152 10/100 ports, 577 10/100/1000 ports, 410 SFP Gigabit Ethernet ports, or 64 10 Gigabit Ethernet ports
Dual, hot-swappable internal AC or DC power supplies
Advanced hardware-assisted IP routing capabilities

To learn more about the Catalyst 6500 series of switches, visit http://www.cisco.com/en/US/products/hw/switches/ps708/index.html.

The following tool can help identify the correct switch for an implementation: http://www.cisco.com/en/US/products/hw/switches/products_promotion0900aecd8050364f.html.

The following guide provides a detailed comparison of current switch offerings from Cisco: http://www.cisco.com/en/US/prod/switches/ps5718/ps708/networking_solutions_products_genericcontent0900aecd805f0955.pdf.

The Basics of the Cisco PIX Firewall

sparky — Tue, 20 Jan 2009 14:55:00 +0000

The Basics of the Cisco PIX Firewall

The Six Basic Commands

The six basic commands to configure a Cisco PIX firewall are well known: nameif, interface, ip address, global, nat, and route. The nameif, interface, and ip address commands are the necessary minimum to get the PIX to communicate with other devices.

`nameif`

The nameif command has two big jobs to perform. It names the interface and assigns a security level. The syntax of the command follows:

nameif hardware_id if_name security_level

The hardware_id is the type of hardware that is being used for the interface. Examples are Gigabit Ethernet, Ethernet, Token Ring, and FDDI. It is important to note that both Token Ring and FDDI have reached end-of-sale status at Cisco. The last date that the Token Ring interface was available for sale was August 25, 2001. The last date that the FDDI interface was available for sale was June 23, 2001.

The if_name is the name of the interface. The name can be up to 48 characters in length and can be uppercase or lowercase. Default names appear in the configuration of the PIX. By default, the E0 interface is named the outside interface and is considered the least secure interface. The E1 interface is named inside, by default, and is considered the most secure. If the PIX has more than two interfaces, the default names of the additional interfaces are intf2 for E2, intf3 for E3, and so on.

The third variable parameter is security_level. The security level is used to define how to configure the PIX to permit traffic to be passed. The inside interface has a default security level of 100. The outside interface has a default security level of 0. 100 is the maximum permitted, and 0 is the minimum. An interface with a higher security level number assigned is considered more secure. If the PIX has more than two interfaces, the default security level of the additional interfaces is 10 for E2 and 15 for E3; each additional interface security level increments by 5.

An interface with a higher security level (assigned to the interface) is considered to be more trusted than an interface with a lower security level. This is an important distinction to understand when configuring data flow. By default, with no configuration parameters input, no data can pass through the PIX. When utilizing the six basic commands that are discussed here, you may configure the PIX to pass data from a more trusted side of the PIX to a less trusted side of the PIX.

An example of a three-interface configuration using nameif might look like this:

pixfirewall# write terminal
Building configuration…
: Saved
:
PIX Version 6.0(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security 50
.
.
.

`interface`

The interface command is used to identify the network interface type, the hardware speed, and the duplex setting (if applicable); it also enables the interface. Network interface types are Ethernet, Gigabit Ethernet, Token Ring, and FDDI. The interface command can be used to shut down an interface, just as an administrator can do on a Cisco router. An interface that is shut down is one that is disabled and is passing no data due to the configuration. The interface command syntax is shown here:

Interface hardware_id [hardware_speed] [shutdown]

If an interface is shut down, configuring that interface and leaving off the variable shutdown will enable the interface. This is an example of configuring the interface command on a three-interface PIX using the auto option (which will set the Ethernet speed automatically) for hardware_speed:

interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto

`ip address`

Assigning an IP address to an interface is accomplished with the ip address command. Each interface that is to be used to pass data must be configured with an IP address. When configuring the ip address command, the IP address is bound to the interface name that was created with the nameif command:

ip address if_name ip_address [netmask]

When the nameif, interface, and ip address commands are configured, it is possible to learn the status of the interfaces. Issuing the show interface command will let you know whether the interfaced is up or down. If the interface is up, you may also test connectivity to the PIX. You may issue a ping command to find out whether the PIX is communicating with a neighbor device on the same network.

`route`

When passing data to a destination network that is not directly connected to the PIX, the destination network must be specified. The destination network is specified using the route command. The PIX is not a router, although it sometimes behaves in a routerlike fashion. The PIX cannot make the same kinds of dynamic routing decisions that a router makes; it must be configured statically.

Route if_name ip_address netmask gateway_ip [metric]

Here, if_name is the name of the interface that the data will pass through when exiting the PIX. The gateway_ip is the IP address of the device (usually a router) that is the next-hop device to the destination network.

It is common to use a default route to the untrusted side of the PIX (the outside interface). The following is an example of how the route commands might be configured if the outside interface were connected to the Internet and the inside interface were connected to your company intranet, which consists of three subnets. The inside interface is directly connected to the 10.2.0.0 255.255.0.0 subnet. The 10.3.0.0 and 10.4.0.0 subnets are reached via a router with a local interface of 10.2.1.4.

route outside 0.0.0.0 0.0.0.0 192.168.1.1 1
route inside 10.3.0.0 255.255.0.0 10.2.1.4 1
route inside 10.4.0.0 255.255.0.0 10.2.1.4 1

With the default route, any traffic that is permitted to pass through the PIX that has a destination network other than 10.2.0.0, 10.3.0.0, and 10.4.0.0 will be passed through the outside interface to 192.168.1.1 for routing.

`global` and `nat`

Now it's time to configure the PIX to allow data to pass through. One of the jobs that the PIX performs very well is address translation. The IP address that enters the PIX through a more trusted interface (this is referred to as a local address) is translated to a different IP address when it exits the PIX through a less trusted interface (this is referred to as the global address).

To pass this data, it is necessary to input some configuration parameters. One way to configure the PIX to permit this data is to use the global and nat statements.

The nat command enables network address translation. nat also defines the local IP addresses that are to be translated to the global IP addresses defined in the global statement. The syntax for the nat and global commands follows:

nat (if_name) nat_id local_ip [netmask]

Data enters the PIX via the interface defined with the if_name variable. The nat_id is an arbitrary, administrator-assigned number between zero and two billion (0 is reserved for a specific purpose, but that is a discussion for another article). The nat_id number used here must match the one used with the corresponding global command. The nat_id number is what binds the nat and global statements together. The local_ip is the more trusted local network that is to be translated to the address or addresses defined in the global command.

global (if_name) nat_id global_ip [-global_ip] [netmask global_mask]

Data exits the PIX via the interface defined with the if_name variable of the global command. The nat_id number used here must match the one used with the corresponding nat command. The global_ip defines the global IP address or global network number.

An example of a two-interface PIX configuration using each of the six basic commands follows:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
interface ethernet0 auto
interface ethernet1 auto
ip address outside 192.168.1.2 255.255.255.0
ip address inside 10.2.1.1 255.255.0.0
global (outside) 1 192.168.1.20-192.168.1.254
nat (inside) 1 10.0.0.0 255.0.0.0
route outside 0.0.0.0 0.0.0.0 192.168.1.1 1
route inside 10.3.0.0 255.255.0.0 10.2.1.4 1
route inside 10.4.0.0 255.255.0.0 10.2.1.4 1

Article is provided courtesy of Cisco Press.Date: Feb 15, 2002.

Multiprotocol Label Switching (MPLS)

sparky — Thu, 08 Jan 2009 12:20:00 +0000

Multiprotocol Label Switching (MPLS) is a standards-approved technology for speeding up network traffic flow and making it easier to manage. MPLS involves setting up a specific path for a given sequence of packets, identified by a label put in each packet, thus saving the time needed for a router to look up the address to the next node to forward the packet to. With reference to the OSI model, MPLS allows most packets to be forwarded at Layer 2 (switching) rather than at Layer 3 (routing). In addition to moving traffic faster overall, MPLS makes it easy to manage a network for quality of service (QoS). For these reasons, the technique is expected to be readily adopted as networks begin to carry more and different mixtures of traffic. (Definition courtesy of Whatis.com.)

MPLS is called multiprotocol because it works with the Internet Protocol (IP), Asynchronous Transport Mode (ATM), and frame relay network protocols. The claim to fame of MPLS is "any-to-any" connectivity. This statement generally implies a comparison to permanent virtual circuit (PVC)-based technologies such as frame relay and ATM, where each site has a physical circuit connecting it to the "cloud." Logical circuits are then configured on the physical circuits to create virtual circuits connecting sites together.

If you were to purchase a full mesh of virtual circuits connecting every site to every other site, you would essentially have the same any-to-any connectivity offered by MPLS. Under the covers, of course, it's quite different, because packets are label switched and traffic engineered instead of being circuit-switched and provisioned.

An MPLS-based network consists of routers and switches interconnected via transport facilities such as fiber links. Customers connect to the backbone (core) network through multiservice edge (MSE) routers. The backbone comprises the core routers that provide high-speed transport and connectivity between the MSE routers. An MSE router contains different types of line cards and physical interfaces to provide Layer 2 and Layer 3 services, including ATM, FR, Ethernet, and IP/MPLS VPNs.

In the incoming direction, line cards receive packets from external interfaces and forward them to the switching fabric. In the outgoing direction, line cards receive packets from the switching fabric and forward them to the outgoing interfaces. The switching fabric, the heart of the router, is used for switching packets between line cards. The IP/MPLS control-plane software, the brain of a router, resides in the control processor card. The phrase IP/MPLS control plane refers to the set of tasks performed by IP routing and MPLS signaling protocols. IP routing protocols are used to advertise network topology, exchange routing information, and calculate forwarding paths between routers within (intra) and between (inter) network routing domains. Examples of IP routing protocols include Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), and Border Gateway Protocol (BGP). MPLS signaling protocols are used to establish, maintain, and release label-switched paths (LSP). Examples of MPLS signaling protocols include BGP, Label Distribution Protocol (LDP), and Resource Reservation Protocol (RSVP). The IP control plane may also contain tunneling protocols such as Layer 2 Tunneling Protocol (L2TP) and Generic Routing Encapsulation (GRE).

Because redundant network elements add to the overall network cost, service providers typically employ different levels and types of fault tolerance in the edge and core network. For example, the core network is generally designed to protect against core router failures through mesh connectivity. This allows alternative paths to be quickly established and used in the face of a failure. In the core, additional routers and links are used to provide fault tolerance. In contrast, on the edge, often thousands of customers are connected through a single router, and the edge router usually represents a single point of failure. The edge router is what most service providers consider the most vulnerable point of their network after the core is protected. On the edge, instead of using additional routers and links as in the core, redundancy within the edge router via redundant control processor cards, redundant line cards, and redundant links (such as SONET/SDH Automatic Protection Switching [APS]) are commonly used to provide fault tolerance.

ref: http://searchnetworking.techtarget.com/generic/0,295582,sid7_gci1225222,00.html#basics

Broadband Remote Access Server

sparky — Thu, 08 Jan 2009 12:15:00 +0000

A broadband remote access server (BRAS or BBRAS) routes traffic to and from the digital subscriber line access multiplexers (DSLAM) on an Internet service provider's (ISP) network.

The BRAS sits at the core of an ISP's network, and aggregates user sessions from the access network. It is at the BRAS that an ISP can inject policy management and IP Quality of Service (QoS).

The specific tasks include:

Aggregates the output from DSLAMs
Provides user PPP sessions over IP or ATM sessions
Enforces quality of service (QoS) policies
Routes traffic into an Internet service provider’s backbone network

A DSLAM collects data traffic from multiple subscribers into a centralized point so that it can be uploaded to the router over a Frame Relay, ATM, or Ethernet connection.

The router provides the logical termination for PPP sessions. These may be PPP over Ethernet (PPPoE) or PPP over ATM (PPPoA) encapsulated sessions. By acting as the PPP termination point, the BRAS is responsible for assigning session parameters such as IP addresses to the clients. The BRAS is also the first IP hop from the client to the Internet.

The BRAS is also the interface to authentication, authorization and accounting systems (see RADIUS)

Cisco Express Forwarding

sparky — Thu, 08 Jan 2009 11:47:00 +0000

Cisco Express Forwarding - (CEF)

CEF is mainly used to increase packet switching speed, reducing the overhead and delays introduced by other routing techniques, increasing overall performance. CEF consists of two key components: The Forwarding Information Base (FIB) and adjacencies.

The FIB is similar to the routing table generated by multiple routing protocols, maintaining only the next-hop address for a particular IP-route.

The adjacency maintains layer 2 or switching information linked to a particular FIB entry, avoiding the need for an ARP request for each table lookup. There are five types of adjacencies:

Null adjacency: Handles packets destined to a NULL interface. Packets with FIB entries pointing to NULL adjacencies will normally be dropped.
Punt adjacency: Deals with packets that require special handling or can not be switched by CEF. Such packets are forwarded to the next switching layer (generally fast switching) where they can be forwarded correctly.
Glean adjacency: Handles packets destined for currently attached hosts, but without layer 2 information.
Discard adjacency: FIB entries pointing to this type of adjacency will be discarded.
Drop adjacency: Packets pointing to this entry are dropped, but the prefix will be checked.

In order to take full advantage of CEF, it is recommended to use distributed CEF (dCEF), where there is a FIB table on each of the line cards. This avoids the need for querying the main processor or routing table in order to get the next-hop information, performing the fast switching on the line card itself.

CEF currently supports Ethernet, Frame Relay, ATM, PPP, FDDI, Tunnels and HDLC.

Function

#sh ip cef ?

#sh ip cef [source ip] [dest ip] - this cmd will display the next hop information required to get from source to destination.

Firewall Switch Modules

sparky — Thu, 11 Dec 2008 15:25:00 +0000

Firewall Services Module

FWSM is a firewall module integrated by Cisco into his Catalyst 6500 Switches and 7600 Series Routers. Installed inside a Cisco Catalyst 6500 Series Switch or Cisco 7600 Internet Router, the FWSM allows any port on the device to operate as a firewall port and integrates firewall security inside the network infrastructure. The FWSM is based on Cisco PIX technology and uses the same time-tested Cisco PIX Operating System, a secure, real-time operating system. The Cisco FWSM enables organizations to manage multiple firewalls from the same management platform. Features: Resource manager helps organizations limit the resources allocated to any security context at any time thus ensuring that one security context does not interfere with another. The transparent firewall feature configures the FWSM to act as a Layer 2 bridging firewall resulting in minimal changes to network topology.