Defining QOS (Quality of Service)

Global Knowledge Course Director and Lab Topology Architect Joey DeWiele, a specialist in Unified Communications, defines QOS.

Presence Defined

Global Knowledge Course Director and Lab Topology Architect Joey DeWiele, a specialist in Unified Communications, explains presence.

DHCP Implementation Processes

In this post we will revisit an old friend that is used quite often in all of our modern networks, Dynamic Host Configuration Protocol (DHCP). The DHCP process allows a server to automatically provision IPv4 addresses, along with other important configurations, to clients as they boot up. The following processes take place when DHCP is implemented.

DHCP Discovery

The client broadcasts messages on the physical subnet asking for IP configuration information and to discover available DHCP servers. If required, the network administrators can configure a local router to forward DHCP packets to a DHCP server located on a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet with the broadcast destination of 255.255.255.255, or the specific subnet broadcast address.

A DHCP client can also request its last-known IP address. If the client remains connected to a network for which this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address. Continue reading ‘DHCP Implementation Processes’

Quality of Service Part 13 – MQC Pop Quiz

The past 12 entries of this blog series have explored QoS theory and how to configure QoS on Cisco routers. By popular demand, I have created a pop quiz on how to configure QoS on a Cisco router using Modular QoS Command Line Interface (MQC) queuing mechanisms.

Here is how the pop quiz will work. The question will be posed in this entry, number 13 in the QoS series. You can post your answers in the comments section below this text. The answer to the question will be posted in entry number 14 of this QoS series.

Here is the pop quiz question – Good Luck!

Author: Paul Stryer

Continue reading ‘Quality of Service Part 13 – MQC Pop Quiz’

IPS Packet Flow through an In-line Sensor

Occasionally I will be asked a question when I teach the Cisco IPS class of what goes on “under the covers” of the IPS appliance between the point where an IP packet arrives at an interface and where it exits the module or appliance. As an attempt to explain that, I have formalized, by way of a PowerPoint diagram, a whiteboard example which illustrates the core components below:

Let’s step through the key elements of packet analysis in the sensor. First, when the packet arrives at the input interface (part of an inline pair), it is subject to what is referred to as the Normalizer Engine. This component ensures that the IP and TCP header check-sums are correct, along with other header fields such as the IP fragmentation fields and TCP flags. Virtual packet reassembly is done here to prevent fragmentation exploits.

Next, the IPS Signature Engines are processed in parallel. It is here that the IP, TCP and application headers can be analyzed via pattern matching algorithms and, optionally, deep packet inspection can be undertaken using the Application Interface Controller (AIC) engine. If there are no matches, the packet is allowed to exit the other interface in the inline pair. With a match however, the signature configuration is examined for the action(s) to be taken.

Before the sensor actually performs these actions, any configured Event Action Overrides and/or Event Action Filters must be evaluated. With overrides, the sensor calculates an overall Risk Rating based on the severity of the alert, the user-defined value of the destination target, the fidelity (or trustworthiness) of the signature, and the relevance of the attack on the target operating system. If the minimum risk rating in the override is met, then additional actions are added.

The Event Action Filter acts in a “reverse” fashion, subtracting actions from a matched signature to “exempt”, for example, a vulnerability scanner from being blocked through the sensor. The criteria for a filter are more complex than those for the override (which is solely based on Risk Rating) and are a subject for a future blog article. Once both the configured override(s) and filter(s) have been evaluated, the alert is recorded in the Event Store, and, if no deny actions remain, the packet is permitted to flow.

If a deny action exists for the matched signature, not only can the offending packet be dropped, but subsequent packets can also be stopped. This latter function is accomplished via a configured deny attacker setting.

At the bottom of the block diagram is the Command/Control interface, used for both provisioning and monitoring the sensor. Since the Event Store is limited to only 30 Megabytes of space, the use of real-time monitoring software or hardware (e.g. Cisco MARS) is required.

Author: Doug McKillip

References

OSPF Part 12: Stub Areas

Last time, we had just finished configuring Area 1 as an OSPF stub area.

At this point, the best paths from R5’s perspective are:

  • Subnet A via R3 (cost = 3)
  • Subnet B via R3 (cost = 3)
  • Subnet C via R4 (cost = 3)
  • Subnet D via R4 (cost = 3)
  • RIP and EIGRP clouds via defaults from R3 and R4 (cost = 1)

Now let’s suppose that R5 wants to get a packet to the RIP cloud. Since R5 is receiving the default route from both R3 and R4, if the metrics are the same (which they would be unless we change them), R5 will load-share traffic for the RIP cloud between R3 and R4. In other words, half of the packets bound for the RIP cloud will take the sub-optimal path via R4. Likewise, since R5 will load-share packets for the EIGRP cloud, half of those packets would take the sub-optimal path via R3. The bottom line is that as a result of hiding information from R5, routing is no longer optimal. The possibility of sub-optimal routing exists whenever summarization is used and there are multiple paths (and OSPF stub areas are a type of summarization).

Continue reading ‘OSPF Part 12: Stub Areas’

Revisiting an Old Friend: DHCP

In this post we will revisit an old friend that is used quite often in all of our modern networks, Dynamic Host Configuration Protocol (DHCP). The DHCP process allows a server to automatically provision IPv4 addresses, along with other important configurations, to clients as they boot up.

There are two principle advantages to using a DHCP server in your network.

  1. DHCP makes it easier to administer an IP network. Without the DHCP functionality, administrators would have to manually assign and track IP addresses, which is a process that is inherently labor intensive and, unfortunately, error-prone.
  2. DHCP allows clients to temporarily use IP addresses and thus make better use of IP address space. For example, DSL customers of an ISP only need an IP address when they are currently online.

DHCP uses a client-server architecture. The client sends a broadcast request for configuration information. The DHCP server receives the request and responds with configuration information from its configuration database. DHCP automates network-parameter assignment to network devices from one or more fault-tolerant DHCP servers. Even in small networks, DHCP is useful because it can make it easy to add new machines to the network.

When a DHCP-configured client, such as a computer or any other network-aware device, connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses, along with other information about client configuration parameters. These additional parameters could include information such as the network default gateway, domain name, the DNS servers, and additional servers such as time servers. On receiving a valid request, the server assigns the computer an IP address with a lease, which is a length of time the allocation is valid. The query from the client is typically initiated immediately after booting and must be completed before the client can initiate IP-based communication with other hosts.

Continue reading ‘Revisiting an Old Friend: DHCP’

Why Ethernet is Like a Polite Dinner Party

Ethernet is a local area network (LAN) technology, with networks traditionally operating within a single building and connecting devices in close proximity. At most, Ethernet devices could have only a few hundred meters of cable between them, making it impractical to connect geographically dispersed locations. However, modern advancements have increased these distances considerably, allowing Ethernet networks to span tens of kilometers.

In networking, the term protocol refers to a set of rules that govern communications. Protocols are to computers what language is to humans. Since this blog is written in English, to understand it you must be able to read English. Similarly, for two devices on a network to successfully communicate, they must both understand the same protocols.

The term Ethernet refers to the family of local-area network (LAN) protocols covered by the IEEE 802.3 standard that defines what is commonly known as the CSMA/CD protocol. Four data rates are currently defined for operation over optical fiber and twisted-pair cables:

  • 10 Mbps—10Base-T Ethernet
  • 100 Mbps—Fast Ethernet
  • 1000 Mbps
  • 10,000Mbps—Gigabit Ethernet

Ethernet is currently used for approximately 85% of the world’s LAN-connected PCs and workstations. Ethernet is the major LAN technology because of the following characteristics:

  • Is easy to understand, implement, manage, and maintain
  • Allows low-cost network implementations
  • Provides extensive topological flexibility for network installation
  • Guarantees successful interconnection and operation of standards-compliant products, regardless of manufacturer

Continue reading ‘Why Ethernet is Like a Polite Dinner Party’

Examining the New IEEE 802.11N LAN Network Standard

The latest upgrade to the family of IEEE 802.11 standards is identified as IEEE 802.11n. Users of this new process will notice two improvements with this improved wireless technology. They will find that significantly greater speeds and ranges can be achieved over the existing standards.

Specifically, 802.11g products, which have a theoretical maximum throughput speed of 54Mbit/sec, typically providing real-world speeds of 22Mbit/sec to 24Mbit/sec. In contrast, IEEE 802.11n networks are providing real-world speeds of 100Mbs to 140Mbs.

The achievable range of IEEE802.11n is harder to quantify because it is affected by many variables, such as physical barriers that could block the signal. However, testing shows that 802.11n equipment typically delivers more than twice the range of 802.11g equipment at any given throughput speed.

The wireless networking topology in a company facility is usually unique to the physical plant and often fills specific niches, such as providing networking in conference rooms, lunch rooms, or in temporary or under-construction office space. In the past, the lack of full deployment of wireless is understandable, given the fact that wired Ethernet provides greater reliability and speeds. In addition, the use of Layer-2 Ethernet switches provides a segmented collision-domain network. On the other hand, wireless-LANs usually provide slower speeds and a shared bandwidth.

The new 802.11n technology is expected to solve the throughput problem for business users, opening the way to the more effective use of far more applications such as wireless voice over IP, and more effective video conferencing sessions.

The question I am most often asked by my students is “How is 802.11n different from the current generations of Wi-Fi?”

Continue reading ‘Examining the New IEEE 802.11N LAN Network Standard’

OSPF Part 11 – Summarization Options

Continuing with our discussion of OSPF summarization options, refer to the figure below…

When we left off, we had reduced the number of Type-5 LSAs being injected into the OSPF cloud from two hundred to two, a summary route from each ASBR. But what if the prefixes that lie within the RIP or EIGRP clouds cannot be easily summarized (a situation which occurs all too often in real life)? In that case, instead of one large summary block, we could configure the ASBRs with multiple smaller summary blocks, by using multiple OSPF “summary-address” commands. The resulting Type-5 LSAs would then flood through Area 0 and into Area 1, but this is better than having every router know about each individual external prefix.

Notice that to reach any external prefix, R5 must send the packet towards Area 0. We can take advantage of this by configuring Area 1 as an OSPF “stub” area.  To do this, we use the OSPF “area stub” command on all routers connected to the area (including any ABRs). If we do, each ABR will inject a default route into Area 1, and no Type-5 LSAs are injected.

Continue reading ‘OSPF Part 11 – Summarization Options’

Next Page »