Course Introduction

A Router can be configured to permit or deny routing table updates to other Routers in a couple of ways, such as passive interface for example, which is used to block updates going out an interface only. However, if you want to block routing updates coming into the Router as well as going out then distribution lists are the answer. Unlike passive interface which blocks all updates leaving an interface, if configured correctly, you can filter your routing information, and block specific networks from the routing table.

This gives you greater control over your network especially where bandwidth is limited, or processing power is low. Remember that Routers can potentially maintain quite large routing tables however, processing power is critical. So to help block or allow certain routing updates we can use distribution lists. Another enhancement we can take advantage of is route-maps discussed later where we implement what is known as policy routing.

Network congestion can be minimised and controlled to a certain extent by causing a Router to avoid a particular path and use a more optimum path. Think of diversions in traffic to move motorists away from a blocked road for example, and you have the idea. The intention is to keep traffic moving whilst making use of the best route. Later we will cover very briefly the concept of QoS (Quality of Service) another method we can employ to improve network congestion.

Access Control Lists (ACLs)

An Access control list is a configuration script that controls whether a Router permits or denies packets to pass based on criteria found in the packet header. It uses rules in this list to match traffic types against in a logical sequence. This allows the Router to specifically exclude or allow information through the network. By default ACLs are not enabled on the Router.

To make an ACL work the Router extracts the information from each packet received in the header of the packet. The information extracted is:

• Source IP Address
• Destination IP address
• Message type (Only for Ext ACL)
• Source Port (Only for Ext ACL)
• Destination (Only for Ext ACL)

Source and destination IP addresses are taken from the originating IP address and the end point IP address not the next hop IP addresses.

Message type is the type of packet that is being transported, either IP/TCP, IGMP, UDP or FTP style packets. Each type of packet is dealt with separately only if specified.

Source and Destination port-

When a host requests information from a server or another host, it sends that request with a PORT number attached this tells the receiving host where to send the information once it gets back. Computers use multiple host addresses to contain multiple connections to servers or other hosts. For example a computer may maintain multiple web pages at the same time in separate tabs. Each one that opens will open a separate host number on both the local computer and the web server. But in the whole process the computer’s IP address remains the same for the whole process. Because there are so many potential host numbers available it can be difficult to control them all. The solution is to use a deny statement on the ACL to maintain control on the hosts you don't want accessing your network.

Permit or deny statements. These act by either allowing the information through the interface or stopping the information from moving on through the Router.

Implicit deny

There is an implied statement which is that any entry that does not match the list is denied access through the Router. The Router then drops the information/packet.

Standard ACLs

Any traffic that matched this address range would be allowed through to any destination.

Standard Numbered

Or on the other hand, to deny that network use the following.

Standard Named:

And to deny that network use the following.

Numbered Assignment

Named Assignment

Extended ACLs

Extended Numbered

Or on the other hand, to deny that network use the following

Extended Named

And to deny

Numbered Assignment

Extended Assignment

Distribution Lists

Normal Interface Distribution Lists: Use the distribute-list command in conjunction with an access list to pick and choose which routing updates a Router will send or receive. By referencing an access list, the distribute-list creates an effective route filter. The access list is a set of rules that precisely controls what routes a Router will be allowed to send or receive in a routing update. The distribute-list command is available for all IP routing protocols and can be applied to either inbound or outbound routing updates. The syntax for configuring a route filter is as follows:

Command

So what is the difference in terms of configuration between global and interface?

GLOBAL

INTERFACE

FILTER from OSPF into EIGRP

Inbound Filtering

1. The Router extracts the routing update
2. The Router checks if there is a distribution list configured for the interface
3. If so the Router will apply the ACL rule against the networks in the update
4. If not, the Router will check for a global distriubtion list
5. If one is present, the Router will apply the ACL rule accordingly against the networks in the update

Outbound Filtering

1. The Router prepares the routing update
2. The Router checks if there is a distribution list configured for the interface
3. If so the Router will apply the ACL rule accordingly against the networks in the update
4. If not the Router will check for a global distribution list
5. If so the Router it will apply the ACL rule accordingly against the networks in the update

Distribution lists impact with OSPF

• match interface
• match ip address
• match ip next-hop
• match ip route-source
• match metric
• match route-type
• match tag

This feature can be useful during redistribution if the user tags prefixes when they get redistributed on ASBRs and later uses the tag to filter the prefixes from being installed in the routing table on other Routers.

Filtering Based on Route Tag

Filtering Based on Route Type

Filtering Based on Route Source

OSPF Filtering: Inter-area verses intra-area

• Within an Area
• Between an Area

OSPF Inter-Area Filtering

Note: Appending le 32 to the first prefix list entry ensures that any more-specific routes within 192.0.2.0/24 are denied as well (as opposed to only the exact /24 route).

Next we reference it as an area filter within OSPF configuration. The area filter-list statement below tells the Router to apply our prefix list to routes being distributed out of area 10. (Don't forget to re-establish neighbor adjacencies afterward so that the new policy takes effect.)

We can verify that R3 is still receiving the 192.0.2.0/24 route from R1, but is not distributing it out of the local area into the backbone (area 0):

OSPF Intra-Area Filtering

Now assume that we need to move the filtering point closer toward the source of the route; specifically, we want to advertise 192.0.2.0/24 from R1 to R2, but not to R3. To accomplish this, we'll need to implement intra-area filtering using the distribute-list command under OSPF configuration.

Intra-area filtering can reference an ACL, prefix list, or route-map; for simplicity's sake, we'll reuse the same prefix-list Deny_Test_Route that was implemented in the prior example. We'll implement inbound filtering on R3 for area 10 since we want to prevent R3 from receiving the route:

We can verify that R2 is still recieving the 192.0.2.0/24 route from R1 but R3 is not:

Note that distribute-lists do not work for outbound OSPF filtering (even though the CLI may accept the command) as OSPF is a link-state protocol and thus all Routers within an area must flood all LSAs. Although unidirectional LSA database filtering can be enabled with the database-filter parameter, it is not appropriate in this scenario (and is typically best avoided altogether).

Configure Route Maps

Recall that ACLs permit or deny traffic based upon matches in a list. These statements are checked in sequential order one line at a time until a match is found. If no match is found it is important to remember that there is an implicit deny statement at the end. If you need to edit the ACL you must first remove the entire list, you cannot delete a statement or try to change the order of the statements without starting from scratch. That is why it is a good idea to prepare your ACLs in notepad first and if you need to make any changes, you can prefix all the ACL statements with no in notepad to remove them, rewrite the modified ACL underneath and then copy and paste into the Router.

Route Maps

The route-map command is used to configure policy routing, which is often a complicated task. Although policy routing can be used to control traffic within an autonomous system (AS), it is typically used to control routing between autonomous systems. For that reason, policy routing is used extensively with exterior gateway protocols (EGPs), such as Border Gateway Protocol (BGP).

Route maps operate similar to access lists, by examining one line at a time until a match is found. Route maps are different from numbered access lists because they can be modified without changing the entire list. Each route map statement is given a number. If a sequence number is not specified, the first route map condition will automatically be numbered as ten (10). The second condition will automatically be numbered as 20, and so on. The optional sequence number can be used to indicate the position that a new route map is to have in the list of route maps already configured with the same name.

After entering the route-map command, enter match and set commands in the route-map configuration mode. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria. They are the conditions that should be tested to determine whether to take action. The set commands specify the set actions. They are the actions to be performed if the match criteria are met.

Router(config)# access-list 5 deny 10.1.1.0 0.0.0.255
Router(config)# access-list 5 permit any
Router(config)# route-map <route_map_name> {permit|deny} [sequence_number]
Router(config-route-map)# match ip address <ACL_number>
Router(config-route-map)# set ip next-hop <next_hop_host_IP>
Router(config-route-map)# set interface <interface_name> alternate set method for P-P links


On the inbound interface apply the policy route-map.

Policing and shaping introduction

There are two methods to limit the amount of traffic originating from an interface: policing and shaping. When an interface is policed outbound, traffic exceeding the configured threshold is dropped (or remarked to a lower class of service). Shaping, on the other hand, buffers excess (burst) traffic to transmit during non-burst periods. Shaping has the potential to make more efficient use of bandwidth at the cost of additional overhead on the router.

All this is just dandy, but doesn't mean much until you see its effects on real traffic. Consider the following lab topology:

We'll be using Iperf on the client (192.168.10.2) to generate TCP traffic to the server (192.168.20.2). In the middle is R1, a Cisco 3725. Its F0/1 interface will be configured for policing or shaping outbound to the server.

IPERF

Iperf is able to test the bandwidth available across a link by generating TCP or UDP streams and benchmarking the throughput of each. To illustrate the effects of policing and shaping, we'll configure Iperf to generate four TCP streams, which we can monitor individually. To get a feel for how Iperf works, let's do a dry run before applying any QoS policies. Below is the output from Iperf on the client end after running unrestricted across a 100 Mbit link:

Client$ iperf -c 192.168.20.2 -t 30 -P 4
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 192.168.10.2 port 1908 connected with 192.168.20.2 port 5001
[1900] local 192.168.10.2 port 1909 connected with 192.168.20.2 port 5001
[1884] local 192.168.10.2 port 1910 connected with 192.168.20.2 port 5001
[1868] local 192.168.10.2 port 1911 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[1900] 0.0-30.0 sec 84.6 MBytes 23.6 Mbits/sec
[1884] 0.0-30.0 sec 84.6 MBytes 23.6 Mbits/sec
[1868] 0.0-30.0 sec 84.6 MBytes 23.6 Mbits/sec
[1916] 0.0-30.0 sec 84.6 MBytes 23.6 Mbits/sec
[SUM] 0.0-30.0 sec 338 MBytes 94.5 Mbits/sec


iperf is run with several options:

• -c - Toggles client mode, with the IP address of the server to contact
• -t - The time to run, in seconds
• -P - The number of parallel connections to establish

We can see that iperf is able to effectively saturate the link at around 95 Mbps (94.5 to be precise), with each stream consuming a roughly equal share of the available bandwidth.

Policing

Our first test will measure the throughput from the client to the server when R1 has been configured to police traffic to 1 Mbit. To do this we'll need to create the appropriate QoS policy and apply it outbound to F0/1. Here's how it looks in the running config.

policy-map Police
class class-default
police cir 1000000
!
interface FastEthernet0/1
service-policy output Police


We can then inspect our applied policy with show policy-map interface. F0/1 is being policed to 1 Mbit with a 31250 bytes burst:

R1# show policy-map interface FastEthernet0/1
Service-policy output: Police
Class-map: class-default (match-any)
2070 packets, 2998927 bytes
5 minute offered rate 83000 bps, drop rate 0 bps
Match: any
police:
cir 1000000 bps, bc 31250 bytes
conformed 1394 packets, 1992832 bytes; actions:
transmit
exceeded 673 packets, 1005594 bytes; actions:
drop
conformed 57000 bps, exceed 30000 bps


Repeating the same iperf test now yields very different results:

Client$ iperf -c 192.168.20.2 -t 30 -P 4
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 192.168.10.2 port 1922 connected with 192.168.20.2 port 5001
[1900] local 192.168.10.2 port 1923 connected with 192.168.20.2 port 5001
[1884] local 192.168.10.2 port 1924 connected with 192.168.20.2 port 5001
[1868] local 192.168.10.2 port 1925 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[1884] 0.0-30.2 sec 520 KBytes 141 Kbits/sec
[1916] 0.0-30.6 sec 1.13 MBytes 311 Kbits/sec
[1900] 0.0-30.5 sec 536 KBytes 144 Kbits/sec
[1868] 0.0-30.5 sec 920 KBytes 247 Kbits/sec
[SUM] 0.0-30.6 sec 3.06 MBytes 841 Kbits/sec


Notice that although we've allowed for up to 1 Mbps of traffic, Iperf has only achieved 841 Kbps. Also notice that, unlike our prior test, each flow does not receive an equal proportion of the available bandwidth. This is because policing (as configured) does not recognize individual flows; it merely drops packets whenever they threaten to exceed the configured threshold.

Using Wireshark's IO graphing feature on a capture obtained at the server, we can observe the apparently random nature of the flows. The black line measures the aggregate throughput, and the colored lines each represent an individual TCP flow.

Shaping

In contrast to policing, we'll see that shaping handles traffic in a very organized, predictable manner. First we'll need to configure a QoS policy on R1 to shape traffic to 1 Mbit. When applying the Shape policy outbound on F0/1, be sure to remove the Police policy first with no service-policy output Police

policy-map Shape
class class-default
shape average 1000000
!
interface FastEthernet0/1
service-policy output Shape


Immediately after starting our Iperf test a third time we can see that shaping is taking place:

R1# show policy-map interface FastEthernet0/1
Service-policy output: Shape
Class-map: class-default (match-any)
783 packets, 1050468 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
1000000/1000000 6250 25000 25000 25 3125
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 69 554 715690 491 708722 yes


This last test concludes with very consistent results:

Client$ iperf -c 192.168.20.2 -t 30 -P 4
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 192.168.10.2 port 1931 connected with 192.168.20.2 port 5001
[1900] local 192.168.10.2 port 1932 connected with 192.168.20.2 port 5001
[1884] local 192.168.10.2 port 1933 connected with 192.168.20.2 port 5001
[1868] local 192.168.10.2 port 1934 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[1916] 0.0-30.4 sec 896 KBytes 242 Kbits/sec
[1868] 0.0-30.5 sec 896 KBytes 241 Kbits/sec
[1884] 0.0-30.5 sec 896 KBytes 241 Kbits/sec
[1900] 0.0-30.5 sec 896 KBytes 241 Kbits/sec
[SUM] 0.0-30.5 sec 3.50 MBytes 962 Kbits/sec


With shaping applied, Iperf is able to squeeze 962 Kbps out of the 1 Mbps link, a 14% gain over policing. However, keep in mind that the gain measured here is incidental and very subject to change under more real-world conditions. Also notice that each stream receives a fair share of bandwidth. This even distribution is best illustrated graphically through an IO graph of a second capture:

Cisco Auto QoS

Introduction

Quality of service (QoS) is the overall performance of a telephony or computer network, particularly the performance seen by the users of the network.

To quantitatively measure quality of service, several related aspects of the network service are often considered, such as error rates, bit rate, throughput, transmission delay, availability, jitter, etc.

Quality of service is particularly important for the transport of traffic with special requirements. In particular, much technology has been developed to allow computer networks to become as useful as telephone networks for audio conversations, as well as supporting new applications with even stricter service demands.

To assist in controlling network congestion we can also use things such as Quality of Service statements. These control how much traffic of a particular type is allowed through the network at a given time.

For example, a node has been operating for a while and the users have discovered that there is a way to stream YouTube though the network. This is having negative effects on the network performance and is interrupting VoIP calls. By limiting the Quality of service for YouTube you can directly control the flow of data to and from that website. By adding QOS it will still allow users to stream YouTube video without affecting the VoIP traffic across the network.

Quality of service statements, become important when you are tunnelling multiple service types multiple times through a single bearer.

Other devices can also be used in network optimisation; they can be server cache devices that contain regularly hosted information in location such as RIVERBED.

Configuration

To configure autoQoS for a Cisco IP phone, perform this task:

Site To Site VPN

Here are a few notes I have to remind me how to configure VPNs, IPSec, and things to keep in my toolkit about routing protocols.

Encryption

• Symmetric Keys - use the same key
• Asymmetric Keys - use a different key (Public/Private)

IPSec

• AH (Authenticating Header) data origin, data integrity, anti-replay - runs in either tunnel/transport mode
• ESP (Encapsulating Security Payload) confidentially runs in either tunnel/transport mode
• IKE (Internet Key Exchange) comprised two phases, coming up

IKE Operation

1. Interesting Traffic detected for encryption (typically from an ACL)
2. IKE Phase 1 (IKE SA negotiation)
3. IKE Phase 2 (IPSec SA negotiation)
4. Data Transfer (encrypted)
5. Tunnel Termination - we'z done!

Let's break it down a bit more.

IKE Phase 1 (Main mode or Aggressive Mode)

• Initiator seeks ISAKMP (Internet Security Association and Key Management Protocol) Policy match at each end
• Exchange public keys securely using DH (Diffie Helman)
• Authenticate each other using encrypted form of IP address
• IKE SA established

IKE Phase 2 (Quick Mode Only)

• Initiator proposes parameters for IPSec SA
• Proof of liveliness (initiator receives and acknowledges - aw!)

Data can now be exchanged.

QM_IDLE is good

Other states include:

• MM_NO_STATE - indicates a fundamental problem with IKE Phase 1 (most likely, a mismatch)
• MM_KEY_EXCH - indicates a misconfiguration of the peer's IP address or shared key

Routing

Split Horizon

Meaning: Cannot advertise via the same interface it was learned on.

Poison Reverse

Meaning: Can advertise with a metric of unreachable when that network goes down.

RIPv2

• Multicast to 224.0.0.9
• Sends entire table every 30 seconds
• 25 routes max table
• Hop count 15
• Supports clear text and MD5 authentication
• Uses equal-cost load balancing

EIGRP

• Multicast to 224.0.0.10
• Sends entire only when adjacency is formed, then updates after that on change
• Uses equal-cost by default
• Unequal-cost can be applied with the variance command

OSPF

• Multicast to 224.0.0.5 - All SPF Routers
• Multicast to 224.0.0.6 - All DR Routers
• Uses Router-id - Required! but if not set, uses this order
• Uses highest IP of any loopback
• Uses highest IP of any active interface

The Router Lookup Process

There are 4 steps:

1. If multiple routes to the destination, use the longest prefix
2. If multiple routes to the destination and also same prefix, use the lowest AD (Administrative Distance)
3. If multiple routes to the destination and same prefix and same AD, use the lowest metric
4. If multiple routes to the destination and same prefix and same AD and lowest metric, then load balance

Adminstrative Distances

Default Metrics for Route Redistribution

• RIP – hop count (default-metric 2)
• EIGRP – 5 values to set (default-metric [bandwidth, delay, reliability, load, mtu]
• OSPF – has a default seed metric (20) you can change
• BGP – no need, will use the metric of the ASBR

OSPF Troubleshooting

• OSPF priority is 1 by default
• OSPF priority of 0 will eliminate that router from the election on that segment
• OSPF priority of Highest = DR, or if necessary Highest Router-id

1. Check Neighbor Adjacency

• Verify that links on routers are layer 2 operational
• Verify layer 3 connectivity between routers
• Verify that the interfaces on both routers are enabled for OSPF
• Verify that the OSPF area and other required parameters match on both ends
• Verify that the interfaces on both routers are not configured as passive

2. Check Routing Table

• Verify OSPF neighbor is advertising correct networks
• Verify there is a routing protocol with a lower AD (more trustworthy)

3. Check Path Selection

• Verify the OSPF cost on both interfaces (show ip ospf interface)

OSPF Network Types

• Ethernet – defaults to broadcast network, DR/BDR elected
• Serial – defaults to NBMA – manual neighbor statements needed

Stub

Prevents LSA 5 and replaces E2 routes with a default route 0*IA 0.0.0.0/0

Totally Stubby

All external and inter-area routes are replaced with a single default route.

There are 2 External route types:

• E1
• E2 (default)