vlan

Virtual LAN Security Best Practices

Independent security research firm @stake [9] recently conducted a Security Review [1] of the virtual LAN (VLAN) technology on the Cisco Catalyst 2950, Catalyst 3550, Catalyst 4500, and Catalyst 6500 series switches. Although no intrinsic security weaknesses emerged from this review, it has been pointed out that an improper or inadequate switch configuration can be the source of undesired behavior and possible security breaches.

Over the past years, Cisco Systems has been advocating best-practices guidelines for secure network configuration in several documents. The SAFE Blueprint [2] or the Best Practices for Catalyst 4500, 5000, and 6500 Series Switches [3] are examples of such documents. However, there has been no single document that collects all of the VLAN-related best practices for easier perusal by customers and field engineers.

The purpose of this paper is to present in a comprehensive way all of the recommendations that Cisco engineers have accumulated to aid with the proper configuration of VLANs on Cisco switches. At the same time, through direct-to-the-point descriptions, the main results of the @stake testing will be explained and the security threats demystified.

Basic Security

Any attempt to create a secure switched network starts from basic security principles. And in particular, basic rules such as the ones highlighted in the SAFE best practices [2] are the cornerstone of any design of secure switched networks.

If a user does not want one of his or her devices to be tampered with, physical access to the device must be strictly controlled. Furthermore, it is important for any network administrator to use all the proven security tools available on Cisco platforms: from the very basic configuration of system passwords, the use of IP permit filters, and login banners, all the way to more advanced tools such as RADIUS, TACACS+, Kerberos, SSH, SNMPv3, IDS, and so forth. (More details are provided in [3].)

Only after all the basic security components are in place, is it possible to turn attention to more sophisticated security details. In the following sections, VLAN-related issues will be explained.

Virtual LANs

A Layer 2 (L2) switch is a device capable of grouping subsets of its ports into virtual broadcast domains isolated from each other. These domains are commonly known as virtual LANs (VLANs).

The concept of VLAN is akin to other concepts in the networking world where traffic is identified by the use of a tag or label. Identification is crucial for a L2 device to be able to isolate ports and properly forward the traffic received. As we will see later, lack of identification is sometimes a cause of insecurity and needs to be avoided.

If any packet in a device is tightly coupled to an appropriate VLAN tag, it is always possible to reliably discriminate traffic into separate and independent domains. This is the basic premise of VLAN-based switching architectures.

In particular, Cisco devices work in accordance with popular VLAN tagging technologies like ISL or 802.1Q across physical links (sometimes referred to as trunks) and employ advanced tagging techniques to preserve the VLAN information internally and use it for the purpose of traffic forwarding.

The simple observation that can be made at this point is that if a packet's VLAN identification cannot be altered after transmission from its source and is consistently preserved from end to end, then VLAN-based security is no less reliable than physical security.

Further on this topic in the following sections.

Control Plane

Malicious users often seek to gain access to the management console of a networking device, because if they are successful they can easily alter the network configuration to their advantage.

In a VLAN-based switch, in addition to having a direct connection to an out-of-band port, the management CPU can use one or more VLANs for in-band management purposes. It also uses one or more VLANs to exchange protocol traffic with other networking devices.

As basic physical security guidelines require networking equipment to be in a controlled (locked) space, VLAN-based security's primary rule is to confine in-band management and protocol traffic into a controlled environment. This can be achieved with the following tools and best practices:

•Traffic and protocol ACLs or filters.

•QoS marking and prioritization (control protocols are differentiated by means of appropriate class-of-service or DSCP values).

•Selective deactivation of L2 protocols on untrusted ports (for example, disabling DTP on access ports).

•Configuration of inband management port(s) only in dedicated VLAN(s).

•Abstention from using VLAN 1 to carry any data traffic.

.


Precautions for the Use of VLAN 1

The reason VLAN 1 became a special VLAN is that L2 devices needed to have a default VLAN to assign to their ports, including their management port(s). In addition to that, many L2 protocols such as CDP, PAgP, and VTP needed to be sent on a specific VLAN on trunk links. For all these purposes VLAN 1 was chosen.

As a consequence, VLAN 1 may sometimes end up unwisely spanning the entire network if not appropriately pruned and, if its diameter is large enough, the risk of instability can increase significantly. Besides the practice of using a potentially omnipresent VLAN for management purposes puts trusted devices to higher risk of security attacks from untrusted devices that by misconfiguration or pure accident gain access to VLAN 1 and try to exploit this unexpected security hole.

To redeem VLAN 1 from its bad reputation, a simple common-sense security principle can be used: as a generic security rule the network administrator should prune any VLAN, and in particular VLAN 1, from all the ports where that VLAN is not strictly needed.

Therefore, with regard to VLAN 1, the above rule simply translates into the recommendations to:

•Not use VLAN 1 for inband management traffic and pick a different, specially dedicated VLAN that keeps management traffic separate from user data and protocol traffic.

•Prune VLAN 1 from all the trunks and from all the access ports that don't require it (including not connected and shutdown ports).

Similarly, the above rule applied to the management VLAN reads:

•Don't configure the management VLAN on any trunk or access port that doesn't require it (including not connected and shutdown ports).

•For foolproof security, when feasible, prefer out-of-band management to inband management. (Refer to [3] for a more detailed description of a out-of-band management infrastructure.)

As a general design rule it is desirable to "prune" unnecessary traffic from particular VLANs. For example, it is often desirable to apply VLAN ACLs and/or IP filters to the traffic carried in the management VLAN to prevent all telnet connections and allow only SSH sessions. Or it may be desirable to apply QoS ACLs to rate limit the maximum amount of ping traffic allowed.

If VLANs other than VLAN 1 or the management VLAN represent a security concern, then automatic or manual pruning should be applied as well. In particular, configuring VTP in transparent or off mode and doing manual pruning of VLANs is commonly considered the most effective method to exert a more strict level of control over a VLAN-based network.




"It is an Equal failing to Trust Everybody, and to Trust Nobody" --- English Proverb

After proper handling of VLAN 1 has been decided upon and implemented, the next logical step is to turn one's attention to other equally important best practices commonly used in secure environments. The generic security principle applied here is: connect untrusted devices to untrusted ports, trusted devices to trusted ports, and disable all the remaining ports. What this means can be easily expanded into this list of common recommendations:

•If a port is connected to a "foreign" device, don't try to speak any language with it: it could be turned to somebody else's advantage and used against you. So on that port make sure to disable CDP, DTP, PAgP, UDLD, and any other unnecessary protocol, and to enable portfast/BPDU guard on it. After all, why risk a potentially dangerous communication with an untrustworthy neighbor?

•Enable the rootguard feature to prevent a directly or indirectly connected STP-capable device to affect the location of the root bridge.

•Configure the VTP domains appropriately or turn off VTP altogether if you want to limit or prevent possible undesirable protocol interactions with regard to network-wide VLAN configuration. This precaution can limit or prevent the risk of an administrator error propagating to the entire network and the risk of a new switch with a higher VTP revision overwriting by accident the entire domain's VLAN configuration.

•By default only those ports which are known to be `trusted' should be treated as such and all other ports should be configured as `untrusted'. This prevents attached devices from manipulating QoS values inappropriately.

•Disable unused ports and put them in an unused VLAN. By not granting connectivity or by placing a device into a VLAN not in use, unauthorized access can be thwarted through fundamental physical and logical barriers.


Why Worry About Layer 2 Security in the First Place?

The OSI stack was conceived so that different layers are able to function independently (with only the knowledge of their mutual interfaces). This allows for flexibility in that developments for a given layer of the protocol stack do not impact other layers so long as the standard interface between the layers is maintained.

Unfortunately this also means that if one layer is hacked, communication may be compromised without the other layers being aware of the problem (as shown in Figure 1).

Figure 1

OSI Stack Structure


In this architecture, security is only as strong as its weakest link.

The Data Link layer is as vulnerable as any other layer and can be subjected to a variety of attacks which the switch must be configured to protect against.

What Are the Possible Attacks in a VLAN-Based Network?

The majority of attacks at L2 exploit the inability of a device to track the attacker who can therefore perform undetected malicious actions on the forwarding path to alter it and then exploit the change.

These are the most talked-about L2 attacks and incidentally also the ones that @stake documented in its findings [1]:

•MAC Flooding Attack

•802.1Q and ISL Tagging Attack

•Double-Encapsulated 802.1Q/Nested VLAN Attack

•ARP Attacks

•Private VLAN Attack

•Multicast Brute Force Attack

•Spanning-Tree Attack

•Random Frame Stress Attack

A description of each of these threats follows.

MAC Flooding Attack

This is not properly a network "attack" but more a limitation of the way all switches and bridges work. They possess a finite hardware learning table to store the source addresses of all received packets: when this table becomes full, the traffic that is directed to addresses that cannot be learned anymore will be permanently flooded. Packet flooding however is constrained within the VLAN of origin, therefore no VLAN hopping is permitted (as @ stake's report shows).

This corner case behavior can be exploited by a malicious user that wants to turn the switch he or she is connected to into a dumb pseudo-hub and sniff all the flooded traffic. Several programs are available to perform this task: for example macof, part of the dsniff suite [4]. This weakness can then be exploited to perform an actual attack, like the ARP poisoning attack (see ARP Attacks for more details on the subject).

On non intelligent switches this problem arises because a sender's L2 identity is not checked, therefore the sender is allowed to impersonate an unlimited number of devices simply by counterfeiting packets.

Cisco's switches support a variety of features whose only goal is to identify and control the identities of connected devices. The security principle on which they are based is very simple: authentication and accountability are critical for all untrusted devices.

In particular, Port Security, 802.1x, and Dynamic VLANs are three features that can be used to constrain the connectivity of a device based on its user's login ID and based on the device's own MAC layer identification.

With Port Security, for instance, preventing any MAC flooding attack becomes as simple as limiting the number of MAC addresses that can be used by a single port: the identification of the traffic of a device is thereby directly tied to its port of origin.

802.1Q and ISL Tagging Attack

Tagging attacks are malicious schemes that allow a user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port were configured as DTP auto and were to receive a fake DTP packet, it might become a trunk port and it might start accepting traffic destined for any VLAN. Therefore, a malicious user could start communicating with other VLANs through that compromised port.

Sometimes, even when simply receiving regular packets, a switch port may behave like a full-fledged trunk port (for example, accept packets for VLANs different from the native), even if it is not supposed to. This is commonly referred to as "VLAN leaking" (see [5] for a report on a similar issue).

While the first attack can be prevented very easily by setting DTP to off on all non trusted ports (again the principle of trust at work...), the second attack can usually be addressed by following simple configuration guidelines (such as the one suggested in the next section) or with software upgrades. Fortunately, Cisco Catalyst 2950, Catalyst 3550, Catalyst 4000, and Catalyst 6000 series switches don't need any such upgrade, since their software and hardware have been designed to always enforce proper traffic classification and isolation on all their ports (as shown by @ stake in [1]).

Why then is the native VLAN mentioned in the report [5]? The answer is provided in the next section...

Double-Encapsulated 802.1Q/Nested VLAN Attack

While internal to a switch, VLAN numbers and identification are carried in a special extended format that allows the forwarding path to maintain VLAN isolation from end to end without any loss of information. Instead, outside of a switch, the tagging rules are dictated by standards such as ISL or 802.1Q.

ISL is a Cisco proprietary technology and is in a sense a compact form of the extended packet header used inside the device: since every packet always gets a tag, there is no risk of identity loss and therefore of security weaknesses.

On the other hand, the IEEE committee that defined 802.1Q decided that because of backward compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not associated explicitly to any tag on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q capable port.

This capability is desirable because it allows 802.1Q capable ports to talk to old 802.3 ports directly by sending and receiving untagged traffic. However, in all other cases, it may be very detrimental because packets associated with the native VLAN lose their tags, for example, their identity enforcement, as well as their Class of Service (802.1p bits) when transmitted over an 802.1Q link.

For these sole reasons—loss of means of identification and loss of classification—the use of the native VLAN should be avoided. There is a more subtle reason, though. Figure 2 shows why.

Figure 2

Double Encapsulation Attack


When double-encapsulated 802.1Q packets are injected into the network from a device whose VLAN happens to be the native VLAN of a trunk, the VLAN identification of those packets cannot be preserved from end to end since the 802.1Q trunk would always modify the packets by stripping their outer tag. After the external tag is removed, the internal tag permanently becomes the packet's only VLAN identifier. Therefore, by double-encapsulating packets with two different tags, traffic can be made to hop across VLANs.

This scenario is to be considered a misconfiguration, since the 802.1Q standard does not necessarily force the users to use the native VLAN in these cases. As a matter of fact, the proper configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose. Protocols like STP, DTP, and UDLD (check out [3]) should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packets.

ARP Attacks

The ARP protocol [6] is quite an old technology. The ARP RFC is from a time when everyone in a network was supposed to be "friendly" and therefore there was no security built into the ARP function. As a consequence, anyone can claim to be the owner of any IP address they like. To be more precise, anyone can claim that his or her MAC address is associated to any IP address within a specific subnet. This is possible because ARP requests or replies carry the information about the L2 identity (MAC address) and the L3 identity (IP address) of a device and there is no verification mechanism of the correctness of these identities.

Again, this is another case where lack of a precise and reliable means of identification of a device leads to a serious security vulnerability. Also, this is a perfect example of why by compromising a lower level in the OSI stack it's possible to directly affect an upper level without the upper layer being aware of the problem. (ARP is a unique specimen of protocol living and breathing in the L2 world but logically residing at the boundary between the Data Link and the Network layer in the OSI stack.)

The ARP attacks that @stake performed were targeted to fool a switch into forwarding packets to a device in a different VLAN by sending ARP packets containing appropriately forged identities. However, in all Cisco devices VLANs are orthogonal to and therefore independent from MAC addresses: so by changing a device's identity in an ARP packet, it's not possible to affect the way it communicates with other devices across VLANs. As a matter of fact, as the report states, any VLAN hopping attempt was thwarted.

On the other hand, within the same VLAN, the so-called ARP poisoning or ARP spoofing attacks [7] are a very effective way to fool end stations or routers into learning counterfeited device identities: this can allow a malicious user to pose as intermediary and perform a Man-In-the-Middle (MiM) attack.

In this case, a picture is worth more than a thousand words of explanation (see Figure 3).

Figure 3

ARP Poisoning Attack


The MiM attack is performed by impersonating another device (for example, the default gateway) in the ARP packets sent to the attacked device: these packets are not verified by the receiver and therefore they "poison" its ARP table with forged information.

This type of attack can be prevented either by blocking the direct communication at L2 between the attacker and the attacked device or by embedding more intelligence into the network so that it can check the forwarded ARP packets for identity correctness. The former countermeasure can be achieved with Cisco Catalyst Private VLANs or Private VLAN Edge features. The latter can be achieved by using a new feature called ARP Inspection, available first in CatOS 7.5 on the Cisco Catalyst 6500 Supervisor Engine II and a little later also in the Cisco IOS Software for the Cisco Catalyst switches.

Private VLAN Attack

"Private VLAN attack" is actually a misnomer because it corresponds not to a vulnerability but rather to the expected behavior of the feature. Private VLANs is a L2 feature and therefore it is supposed to isolate traffic only at L2. On the other hand, a router is a Layer 3 (L3) device and when it's attached to a Private VLAN promiscuous port it is supposed to forward L3 traffic received on that port to whatever destination it is meant to, even if it's in the same subnet as the source (@stake refers to this behavior as Layer 2 Proxy).

Therefore, it is absolutely normal for two hosts in an Isolated VLAN to fail to communicate with each other through direct L2 communication and instead to succeed to talk to each other by using the router as a packet relay.

Figure 4 depicts the aforementioned behavior.

Figure 4

L2 Proxy


As with regular routed traffic, packets relayed through L2 Proxy can be filtered, if desired, through the configuration of an appropriate ACL on the forwarding device.

Here is a simple example of output Cisco IOS ACL to block the relayed traffic:

deny subnet/mask subnet/mask

permit any subnet/mask

deny any any

More information on Private VLANs can be found in this paper [8].

Multicast Brute Force Attack

This attack tries to exploit switches' potential vulnerabilities (read: bugs) against a storm of L2 multicast frames. @stake's test was designed to ascertain what happens when a L2 switch receives lots of L2 multicast frames in rapid succession. The correct behavior should be to constrain the traffic to its VLAN of origin, the failure behavior would be to leak frames to other VLANs.

In @stake's results, this type of attack proved ineffective against Cisco Catalyst switches because they correctly contained all the frames within their appropriate broadcast domain (no surprise here: after all, in all Catalyst switches broadcasts are just special cases of multicasts).

Spanning-Tree Attack

Another attack that tries to leverage a possible switch weakness (for example, bug) is the STP attack. All of the Cisco Catalyst switches tested by @stake support this protocol. By default, STP is turned on and every port on the switch both speaks and listens for STP messages. @stake tried to see if Cisco PVST (Per VLAN Spanning Tree) would fail open across1 multiple VLANs under specific conditions. The attack consisted in sniffing for STP frames on the wire to get the ID of the port STP was transmitting on. Next, the attacker would begin sending out STP Configuration/Topology Change Acknowledgement BPDUs announcing that he was the new root bridge with a much lower priority.

During this procedure broadcast traffic was injected by the testers to discover any possible VLAN leaks, but none were found. This is an indication of the robustness of STP's implementations on Cisco switches.

Random Frame Stress Attack

This last test can have many incarnations but in general it consists in a brute force attack that randomly varies several fields of a packet while keeping only the source and destination addresses constant. After repetitive testing by @stake's engineers, no packets were found to have successfully hopped VLANs.

Private VLANs can be used in this context to better isolate hosts at L2 and shield them from unwanted malicious traffic from untrustworthy devices. Communities of mutually-trusting hosts can be created so as to partition a L2 network into subdomains where only friendly devices are allowed to communicate with each other. For more information on Private VLANs please refer to this paper [8].

Conclusion

The security of VLAN technology has proven to be far more reliable than its detractors had hoped for and only user misconfiguration or improper use of features have been pointed out as ways to undermine its robustness.

The most serious mistake that a user can make is to underestimate the importance of the Data Link layer, and of VLANs in particular, in the sophisticated architecture of switched networks. It should not be forgotten that the OSI stack is only as robust as its weakest link, and that therefore an equal amount of attention should be paid to any of its layers so as to make sure that its entire structure is sound.

Any good networking design based on Cisco Catalyst switches should incorporate the best practice guidelines described in this paper as an effective way to protect a network's L2 security architecture from dangerous vulnerabilities.

Although some of the security concepts discussed in the previous sections are very generic, this document is solely intended for a network of Cisco Catalyst switches, as other switch vendors' implementations vary greatly and thus some are in fact more susceptible to the various attacks described in this paper.

References

1. Research Report: Secure Use of VLANs: An @stake Security Assessment—August 2002,

http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/stake_wp.pdf

2. SAFE: A Security Blueprint for Enterprise Networks, http://www.cisco.com/go/safe/

3. Best Practices for Catalyst 4500, 5000, and 6500 Series Switch Configuration and Management,

http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml

4. dsniff, by Dug Song, http://monkey.org/~dugsong/dsniff

5. VLAN Security Test Report, July 2000, http://www.sans.org/newlook/resources/IDFAQ/vlan.htm

6. An Ethernet Address Resolution Protocol, RFC 826, http://www.ietf.org/rfc/rfc0826.txt

7. ARP spoofing attack:

http://www.sans.org/newlook/resources/IDFAQ/switched_network.htm

8. @stake, http://www.atstake.com/

Acronyms and Definitions

802.1Q

IEEE specification that defines a standard VLAN tagging scheme.

BPDU

Bridge Protocol Data Unit
Messages exchanged by switches that run the Spanning Tree Protocol.

CDP

Cisco Discovery Protocol
Cisco proprietary protocol to discover a network topology made up of compatible devices.

DTP

Dynamic Trunking Protocol
Cisco proprietary protocol to dynamically negotiate trunking parameters (like status and format).

IEEE

Institute of Electrical and Electronics Engineers

ISL

Inter-Switch Link
Cisco proprietary VLAN tagging format.

Native VLAN

VLAN that is not associated explicitly to any tag on an 802.1Q link.

OSI

Open Systems Interconnect
Networking Reference Model.

PAgP

Port Aggregation Protocol
Cisco proprietary protocol to dynamically negotiate channeling parameters (like number of ports).

STP

Spanning-Tree Protocol
Bridge protocol defined in the IEEE 802.1D standard.

UDLD

UniDirectional Link Detection
Cisco proprietary protocol to verify the bidirectionality of a physical link.

VLAN

Virtual Local-Area Network
Virtual broadcast domain comprising one or more switch ports.

VTP

VLAN Trunking Protocol
Cisco proprietary protocol to distribute VLAN information within a predefined domain.

OSPF distribute-list example (Block Lists)

lated routers under Dynamips / Dynagen / GNS3. Network diagram was exported from the running GNS3 model.


[edit] Base device configurations
[edit] R0 (172.16.0.1)
version 12.4
!
hostname R0
!
ip cef
no ip domain lookup
!
interface Loopback0
ip address 172.16.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.1.0.1 255.255.255.252
duplex auto
speed auto
!
end
[edit] R1 (172.16.0.2)
version 12.4
!
hostname R2
!
ip cef
no ip domain lookup
!
interface Loopback0
ip address 172.16.0.2 255.255.255.255
!
interface FastEthernet0/0
ip address 10.1.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.2.0.1 255.255.255.252
duplex auto
speed auto
!

end
[edit] R3 (172.16.0.3)
version 12.4
!
hostname R3
!
ip cef
no ip domain lookup
!
interface Loopback0
ip address 172.16.0.3 255.255.255.255
!
interface Loopback1
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.2.0.2 255.255.255.252
duplex auto
speed auto
!
end
[edit] OSPF distribute-list example (Block Lists)
[edit] Base OSPF Configuration, without block lists
[edit] R0 (172.16.0.1)
router ospf 1
router-id 172.16.0.1
log-adjacency-changes
network 10.1.0.0 0.0.0.3 area 0
network 172.16.0.1 0.0.0.0 area 0
!
[edit] R1 (172.16.0.2)
router ospf 1
router-id 172.16.0.2
log-adjacency-changes
network 10.1.0.0 0.0.0.3 area 0
network 10.2.0.0 0.0.0.3 area 0
network 172.16.0.2 0.0.0.0 area 0
!
[edit] R2 (172.16.0.3)
router ospf 1
router-id 172.16.0.3
redistribute connected subnets metric-type 1
log-adjacency-changes
network 10.2.0.0 0.0.0.3 area 0
network 172.16.0.3 0.0.0.0 area 0
!
Router R2 is redistributing the loopback adapter 192.168.1.0 into OSPF in order to generate an LSA Type 5 (area-filters must be used for LSA type 3s). The route makes it from router R2, to R1, to R0. See the routing output below, important information highlighted.
[edit] OSPF Standard routing - no distribute-list
[edit] R0 show ip route example – OSPF Standard routing
R0#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/32 is subnetted, 3 subnets
C 172.16.0.1 is directly connected, Loopback0
O 172.16.0.2 [110/2] via 10.1.0.2, 00:00:00, FastEthernet0/0
O 172.16.0.3 [110/3] via 10.1.0.2, 00:00:00, FastEthernet0/0
10.0.0.0/30 is subnetted, 2 subnets
O 10.2.0.0 [110/2] via 10.1.0.2, 00:00:00, FastEthernet0/0
C 10.1.0.0 is directly connected, FastEthernet0/0
192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/3] via 10.1.0.2, 00:00:00, FastEthernet0/0
[edit] R0 show ospf database – OSPF Standard routing
R0#sh ip ospf database
OSPF Router with ID (172.16.0.1) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
172.16.0.1 172.16.0.1 1284 0x80000004 0x008449 2
172.16.0.2 172.16.0.2 1346 0x80000002 0x00A4FB 3
172.16.0.3 172.16.0.3 419 0x80000006 0x00D6E8 2

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.1.0.1 172.16.0.1 1350 0x80000001 0x00E70F
10.2.0.2 172.16.0.3 1347 0x80000001 0x00D917

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
192.168.1.0 172.16.0.3 411 0x80000001 0x00F009 0
[edit] R1 show ip route example – OSPF Standard Config
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/32 is subnetted, 3 subnets
O 172.16.0.1 [110/2] via 10.1.0.1, 00:01:32, FastEthernet0/0
C 172.16.0.2 is directly connected, Loopback1
O 172.16.0.3 [110/2] via 10.2.0.2, 00:01:32, FastEthernet1/0
10.0.0.0/30 is subnetted, 2 subnets
C 10.2.0.0 is directly connected, FastEthernet1/0
C 10.1.0.0 is directly connected, FastEthernet0/0
192.168.1.0/30 is subnetted, 1 subnets
O E1 192.168.1.0 [110/21] via 10.2.0.2, 00:01:32, FastEthernet1/0
[edit] R1 show ip ospf database example – OSPF Standard Config
R1# sh ip ospf database

OSPF Router with ID (172.16.0.2) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
172.16.0.1 172.16.0.1 984 0x80000004 0x008449 2
172.16.0.2 172.16.0.2 1044 0x80000002 0x00A4FB 3
172.16.0.3 172.16.0.3 117 0x80000006 0x00D6E8 2

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.1.0.1 172.16.0.1 1050 0x80000001 0x00E70F
10.2.0.2 172.16.0.3 1045 0x80000001 0x00D917

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
192.168.1.0 172.16.0.3 109 0x80000001 0x00F009 0

We can see in the above examples, R2 generates a route and it propagates to R1. All routers along the path have this entry in their OSPF Configuration.
[edit] Adding the Distribute-list (Block List) to OSPF
In OSPF, the distribute-command should be defined as only a mechanism as to whether or not the specific router the distribute-list is configured on accepts a route for insertion into it’s own OSPF table. One of the key points to remember about OSPF is that it’s about global database consistency. Every device must have the same view of the entire topology of the network. Every router knows how to get everywhere else. This functionality is different than EIGRP, as it will be shown below. The distribute-list command on OSPF only tells OSPF which routes it can put in the FIB.
[edit] R1 configuration
router ospf 1
router-id 172.16.0.2
log-adjacency-changes
network 10.1.0.0 0.0.0.3 area 0
network 10.2.0.0 0.0.0.3 area 0
network 172.16.0.2 0.0.0.0 area 0
distribute-list 50 in FastEthernet1/0
!
access-list 50 deny 192.168.1.0 0.0.0.255
access-list 50 permit any
!
The only difference here is that an access-list is applied to the distribute-list statements.
[edit] R1 show ip route example – OSPF Distribute-list applied
We can see in the output below that R1 does not actually have 192.168.1.0/24 in it’s IP routing table. The distribute-list command on R1 blocks this route.
R1# sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/32 is subnetted, 3 subnets
O 172.16.0.1 [110/2] via 10.1.0.1, 00:00:16, FastEthernet0/0
C 172.16.0.2 is directly connected, Loopback1
O 172.16.0.3 [110/2] via 10.2.0.2, 00:00:16, FastEthernet1/0
10.0.0.0/30 is subnetted, 2 subnets
C 10.2.0.0 is directly connected, FastEthernet1/0
C 10.1.0.0 is directly connected, FastEthernet0/0
*******192.168.1.0/24 is MISSING*****
[edit] R1 show ip ospf database example – OSPF Distribute-list applied
The distribute-list command only removes the route from the OSPF Table – it does not stop that route from being advertised out to other OSPF Neighbors. This is for database consistencies sake.
R1#sh ip ospf database

OSPF Router with ID (172.16.0.2) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
172.16.0.1 172.16.0.1 1164 0x80000004 0x008449 2
172.16.0.2 172.16.0.2 1224 0x80000002 0x00A4FB 3
172.16.0.3 172.16.0.3 297 0x80000006 0x00D6E8 2

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.1.0.1 172.16.0.1 1230 0x80000001 0x00E70F
10.2.0.2 172.16.0.3 1225 0x80000001 0x00D917

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
192.168.1.0 172.16.0.3 289 0x80000001 0x00F009 0
[edit] R1 debug ip ospf spf/tree
Debugging OSPF spf and tree events shows below that LSAs are still generated for 192.168.1.0/24 even though a distribute-list is applied, and that route is still added to the database. Router R1 specifically just chooses not to route for it.
*Mar 1 02:54:36.799: OSPF: Started Building Type 5 External Routes
*Mar 1 02:54:36.803: OSPF: Start processing Type 5 External LSA 192.168.1.0, mask 255.255.255.252, adv 172.16.0.3, age 1905, seq 0x80000001, metric 20, metric-type 1
*Mar 1 02:54:36.803: Add better path to LSA ID 192.168.1.0, gateway 10.2.0.2, dist 21
*Mar 1 02:54:36.803: Add path: next-
R1#hop 10.2.0.2, interface FastEthernet1/0
*Mar 1 02:54:36.803: network update dest_addr 192.168.1.0 mask 255.255.255.252 gateway 10.2.0.2
*Mar 1 02:54:36.807: OSPF: insert route list LS ID 192.168.1.0, type 5, adv rtr 172.16.0.3
[edit] R0 show ip route example – OSPF distribute-list applied
We can see here below that 192.168.1.0 is added to the routing table, with the next-hop IP of R1. You may expect that this route to not enter the OSPF Table, but remember, distribute-list only changes the FIB (forwarding information base) table on the local router it is configured on.
R0#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/32 is subnetted, 3 subnets
C 172.16.0.1 is directly connected, Loopback0
O 172.16.0.2 [110/2] via 10.1.0.2, 00:03:58, FastEthernet0/0
O 172.16.0.3 [110/3] via 10.1.0.2, 00:03:58, FastEthernet0/0
10.0.0.0/30 is subnetted, 2 subnets
O 10.2.0.0 [110/2] via 10.1.0.2, 00:03:58, FastEthernet0/0
C 10.1.0.0 is directly connected, FastEthernet0/0
192.168.1.0/30 is subnetted, 1 subnets
O E1 192.168.1.0 [110/22] via 10.1.0.2, 00:03:58, FastEthernet0/0
[edit] R0 – show ip ospf database example – OSPF Distribute-list applied
The output below shows another type-5 LSA from R2 which generates the route. OSPF on R0 will add this LSA to it’s database because it must keep the database consistent.
R0#show ip ospf database

OSPF Router with ID (172.16.0.1) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
172.16.0.1 172.16.0.1 1135 0x80000004 0x008449 2
172.16.0.2 172.16.0.2 1197 0x80000002 0x00A4FB 3
172.16.0.3 172.16.0.3 270 0x80000006 0x00D6E8 2

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
10.1.0.1 172.16.0.1 1202 0x80000001 0x00E70F
10.2.0.2 172.16.0.3 1198 0x80000001 0x00D917

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
192.168.1.0 172.16.0.3 262 0x80000001 0x00F009 0
[edit] EIGRP distribute-list configuration examples
[edit] Device Configurations
[edit] R0 (172.16.0.1)
router eigrp 1
network 10.1.0.0 0.0.0.3
network 172.16.0.1 0.0.0.0
auto-summary
!
[edit] R1 (172.16.0.2)
router eigrp 1
network 10.1.0.0 0.0.0.3
network 10.2.0.0 0.0.0.3
network 172.16.0.2 0.0.0.0
auto-summary
!
[edit] R2 (172.16.0.3)
router eigrp 1
redistribute connected
network 10.2.0.0 0.0.0.3
network 172.16.0.3 0.0.0.0
auto-summary
!
[edit] EIGRP - Default, standard routing (No distribute-list)
[edit] R1 – show ip route – EIGRP default standard routing
In the below example, we can see that the route from R2 makes it into EIGRP as an EIGRP external route. This is routing as usual and is expected.
R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:01:43, Null0
C 172.16.0.2/32 is directly connected, Loopback1
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.2.0.0/30 is directly connected, FastEthernet1/0
D 10.0.0.0/8 is a summary, 00:02:07, Null0
C 10.1.0.0/30 is directly connected, FastEthernet0/0
192.168.1.0/30 is subnetted, 1 subnets
D EX 192.168.1.0 [170/156160] via 10.2.0.2, 00:01:31, FastEthernet1/0
[edit] R1 – show ip eigrp topology – EIGRP standard routing
This route is added into the EIGRP topology table with the below metrics, as expected.
R1#sh ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.0.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.2.0.0/30, 1 successors, FD is 28160
via Connected, FastEthernet1/0
P 10.0.0.0/8, 1 successors, FD is 28160
via Summary (28160/0), Null0
P 10.1.0.0/30, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 192.168.1.0/30, 1 successors, FD is 156160
via 10.2.0.2 (156160/128256), FastEthernet1/0
P 172.16.0.0/16, 1 successors, FD is 128256
via Summary (128256/0), Null0
P 172.16.0.2/32, 1 successors, FD is 128256
via Connected, Loopback1
[edit] R0 - show ip route - EIGRP Standard Routing
The route makes it from R1 to R0, with a next-hop of R1. This is routing as expected.
R0#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:02:28, Null0
C 172.16.0.1/32 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.2.0.0/30 [90/30720] via 10.1.0.2, 00:02:35, FastEthernet0/0
D 10.0.0.0/8 is a summary, 00:02:44, Null0
C 10.1.0.0/30 is directly connected, FastEthernet0/0
192.168.1.0/30 is subnetted, 1 subnets
D EX 192.168.1.0 [170/158720] via 10.1.0.2, 00:01:53, FastEthernet0/0
[edit] R0 – show ip eigrp topology – EIGRP standard routing
The EIGRP route also makes it into the EIGRP topology of router R0, as expected.
R0#sh ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.0.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.2.0.0/30, 1 successors, FD is 30720
via 10.1.0.2 (30720/28160), FastEthernet0/0
P 10.0.0.0/8, 1 successors, FD is 28160
via Summary (28160/0), Null0
P 10.1.0.0/30, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 192.168.1.0/30, 1 successors, FD is 158720
via 10.1.0.2 (158720/156160), FastEthernet0/0
P 172.16.0.0/16, 1 successors, FD is 128256
via Summary (128256/0), Null0
P 172.16.0.1/32, 1 successors, FD is 128256
via Connected, Loopback0
[edit] EIGRP Distribution list configuration
In the below example, a distribute-list is applied to an interface using EIGRP. In EIGRP, a distribute-list will block route entries from entering the topology table. OSPF and EIGRP maintain their routing tables and make routing decisions differently. OSPF has a single database for the entire network, and each router has the same view of the network. EIGRP maintains a single view for each router. EIGRP operates in a ‘routing by rumor’ method, in which it only learns routes that it’s direct neighbors tell it. This is why it is referred to as a ‘hybrid’ routing protocol, in that it routes by rumors yet still supports link state advertisements and trigged updates.
[edit] R0 Config (172.16.0.3)
router eigrp 1
network 10.1.0.0 0.0.0.3
network 10.2.0.0 0.0.0.3
network 172.16.0.2 0.0.0.0
distribute-list 50 in FastEthernet1/0
auto-summary
!
access-list 50 deny 192.168.1.0 0.0.0.255
access-list 50 permit any
!
[edit] R1 – show ip route – EIGRP Distribute-list applied
R1 does not have 192.168.1.0/24 in it’s routing table anymore since we removed it from the running configuration. We can also see that there’s an EIGRP adjacency change when we apply the configuration, showing that it is truly a routing-by-rumor hybrid protocol and the neighbors topology has changed.
*Mar 1 03:11:13.651: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.2.0.2 (FastEthernet1/0) is resync: route configuration changed

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:07:56, Null0
C 172.16.0.2/32 is directly connected, Loopback1
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.2.0.0/30 is directly connected, FastEthernet1/0
D 10.0.0.0/8 is a summary, 00:08:20, Null0
C 10.1.0.0/30 is directly connected, FastEthernet0/0
**** 192.168.1.0/24 is NOT HERE as per distribute-list ****
[edit] R1 – Show ip eigrp topology – EIGRP distribute-list applied
Unsurprisingly, the distribute-list command has rejected the EIGRP route advertised from R2 and it does not make it into the EIGRP topology table.
R1#sh ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.0.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.2.0.0/30, 1 successors, FD is 28160
via Connected, FastEthernet1/0
P 10.0.0.0/8, 1 successors, FD is 28160
via Summary (28160/0), Null0
P 10.1.0.0/30, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 172.16.0.0/16, 1 successors, FD is 128256
via Summary (128256/0), Null0
P 172.16.0.2/32, 1 successors, FD is 128256
via Connected, Loopback1
[edit] R0 – show ip route – EIGRP distribute-list applied
When we get to R0, we can see that 192.168.1.0/24 is also not here --- Since EIGRP routes by rumor and not by a shared topology view, it has no idea that 192.168.1.0/24 is connected to R1, since R1 has rejected the route and topology entry with a distribute-list. This is the biggest difference between OSPF and EIGRP – Distribute-lists on EIGRP do exactly what they are intended to do, while OSPF will not give results.
R0#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:08:23, Null0
C 172.16.0.1/32 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.2.0.0/30 [90/30720] via 10.1.0.2, 00:08:29, FastEthernet0/0
D 10.0.0.0/8 is a summary, 00:08:38, Null0
C 10.1.0.0/30 is directly connected, FastEthernet0/0
[edit] R0 – show ip eigrp topology – EIGRP distribute-list applied
As mentioned prior, EIGRP does not have a topology entry for 192.168.1.0/24 – R0 never hears about the topology entry, since R1 rejects it outright.
R0#sh ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.0.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.2.0.0/30, 1 successors, FD is 30720
via 10.1.0.2 (30720/28160), FastEthernet0/0
P 10.0.0.0/8, 1 successors, FD is 28160
via Summary (28160/0), Null0
P 10.1.0.0/30, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 172.16.0.0/16, 1 successors, FD is 128256
via Summary (128256/0), Null0
P 172.16.0.1/32, 1 successors, FD is 128256
via Connected, Loopback0
[edit] Conclusion
In the examples listed above, we can display the routing protocol differences between EIGRP and OSPF when distribute-lists are used. OSPF distribute lists only change routing decisions on which routes from the OSPF database to add to the RIB and FIB (Forwarding and Routing information bases), or the routing table, on the specific router, but continues to advertise LSAs to other OSPF routers. EIGRP distribute-lists reject the topology and routes advertised from neighbors due to it’s route-by-rumor design, and as such, those routes are not advertised to any other EIGRP neighbors.
References: Cisco IOS 12.4(18), IP Plus on Cisco 3640 series chassis. GNS3, version 0.4 https://gns3.net, based on open-source Dynagen and Dynamips.
i,
Can anyone help me understand prefix lists a little better ?
As can be seen from the output below, I have tried to configure a distribute list within eigrp with the aim of filtering just the route 172.16.1.0/24 .

Using > ip prefix-list test seq 5 deny 172.16.1.0/24

router eigrp 1
network 10.0.24.0 0.0.7.255
network 172.16.0.0
distribute-list prefix test out
no auto-summary

However when I go to R2 the list has filtered all routes 172.16.1.0, 172.16.2.0, 172.16.3.0,172.16.4.0 etc

Is it not possible to filter just one route within a classful network with a prefix list or am I missing something ?

Thanks in advance. Phil.

full router config below :

R2#show run
Building configuration...
Current configuration : 1850 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
no aaa new-model
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
!
!
no ip domain lookup
ip host r1 10.0.24.1
ip host sw1 10.0.24.3
!
multilink bundle-name authenticated
!
!
!
!
!
username phil
archive
log config
hidekeys
!
!
!
!
!
!
!
interface Loopback1
ip address 172.16.1.2 255.255.255.0
!
interface Loopback2
ip address 172.16.2.2 255.255.255.0
!
interface Loopback3
ip address 172.16.3.2 255.255.255.0
!
interface Loopback4
ip address 172.16.4.2 255.255.255.0
!
interface Loopback5
ip address 172.16.5.2 255.255.255.0
!
interface Loopback6
ip address 172.16.6.2 255.255.255.0
!
interface Loopback7
ip address 172.16.7.2 255.255.255.0
!
interface Loopback8
ip address 172.16.8.2 255.255.255.0
!
interface Loopback9
ip address 172.16.9.2 255.255.255.0
!
interface Loopback10
ip address 172.16.10.2 255.255.255.0
!
interface Loopback11
ip address 172.16.11.2 255.255.255.0
!
interface Loopback12
ip address 172.16.12.2 255.255.255.0
!
interface Loopback13
no ip address
!
interface Loopback14
no ip address
!
interface Loopback15
no ip address
!
interface FastEthernet0/0
ip address 10.0.24.2 255.255.255.248
duplex auto
speed auto
!
interface Serial0/0
no ip address
no fair-queue
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
router eigrp 1
network 10.0.24.0 0.0.7.255
network 172.16.0.0
distribute-list prefix test out
no auto-summary
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
ip prefix-list test seq 5 deny 172.16.1.0/24
!
!
!
!
control-plane
!
!
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
!
end
R2#

Prefix list in EIGRP redistribution
Zone:
Network Routers
Right now, R1 prefers R3 for everything. I would like to change this, so R1 prefers R2 for 172.16.1.1. But goes through R3 for everything else. Can this be done with a prefix list on R2 only?

ie, config to add to R2:

ip prefix-list mylist seq 5 permit 172.16.1.1/32
access-list 1 permit any
!
route-map mymap permit 10
match ip address prefix-list mylist
set metric 100000 100 255 1 1500
!
route-map mymap permit 20
match ip address 1
set metric 10 100 255 1 1500


labospfeigrp.jpg (109 KB) (File Type Details)
b

EIGRP Support for Route Map Filtering

EIGRP Support for Route Map Filtering
________________________________________
First Published: May 17, 2004
Last Updated: September 28, 2007
The EIGRP Support for Route Map Filtering feature enables Enhanced Interior Gateway Routing Protocol (EIGRP) to interoperate with other protocols by filtering inbound and outbound traffic based on complex route map options. In addition to the existing route map facility, several extended filtering options are introduced to provide EIGRP-specific match choices.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for EIGRP Support for Route Map Filtering" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
• Information About EIGRP Support for Route Map Filtering
• How to Configure EIGRP Support for Route Map Filtering
• Configuration Examples for EIGRP Support for Route Map Filtering
• Additional References
• Command Reference
• Feature Information for EIGRP Support for Route Map Filtering
Information About EIGRP Support for Route Map Filtering
To implement EIGRP route map filtering, you should understand the following concept:
• EIGRP Route Map Support
EIGRP Route Map Support
EIGRP support for route map filtering enables EIGRP to interoperate with other protocols by filtering inbound and outbound traffic based on route map options. Additional EIGRP-specific match choices are introduced to allow flexibility in fine-tuning EIGRP network operations.
EIGRP now supports the route map filtering capability that exists for other routing protocols to filter routes being redistributed into their protocol. For more details about understanding and configuring route maps, see the Enabling Policy Routing section of the "Configuring IP Routing Protocol-Independent Features" chapter of the Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4T.
New match options allow EIGRP to filter internal and external routes based on source protocols, to match a metric against a range, and to match on an external protocol metric.
EIGRP can be configured to filter traffic using a route map and the redistribute or distribute-list commands. Using a route map with the redistribute command allows routes that are redistributed from the routing table to be filtered with a route map before being admitted into an EIGRP topology table. Routes that are dynamically received from, or advertised to, EIGRP peers can be filtered by adding a route map option to the distribute-list command.
A route map may be configured with both the redistribute and the distribute-list commands in the same routing process. When a route map is used with a distribute-list command that is configured for inbound or outbound filtering, route packets that are learned from or advertised to EIGRP peers can be processed with the route map to provide better control of route selection during the route exchange process. Redistribution serves as a mechanism to import routes into the EIGRP topology table from a routing table. A route map configured with the redistribute command adds flexibility to the redistribution capability and results in a more specific redistributed route selection.
In summary, demands for EIGRP to interoperate with other protocols and flexibility in fine-tuning network operation necessitate the capability to filter traffic using a route map.
How to Configure EIGRP Support for Route Map Filtering
This section contains the following tasks:
• Configuring EIGRP Metrics Using a Route Map (required)
• Verifying EIGRP Metrics (optional)
Configuring EIGRP Metrics Using a Route Map
Perform this task configure EIGRP metrics using a route map. In the Detailed Steps below, the EIGRP metrics used for filtering are configured within a route map. The first match clause defines EIGRP routes that contain an external protocol metric between 400 and 600 inclusive;the second match clause defines EIGRP external routes that match a source protocol of BGP and the autonomous system 45000. When the two match clauses are true, a tag value of the destination routing protocol is set to 5. This route map can be used with the distribute-list command, see the "Configuring EIGRP Metrics Using a Route Map: Examples" section for an example configuration.
SUMMARY STEPS
1. enable
2. configure terminal
3. route-map map-tag [permit | deny] [sequence-number]
4. match metric {metric-value | external metric-value} [+- deviation-number]
5. match source-protocol source-protocol [autonomous-system-number]
6. set tag source-protocol [autonomous-system-number]
7. exit
8. router eigrp as-number
9. network ip-address
10. distribute-list route-map map-tag in
DETAILED STEPS
Command or Action Purpose
Step 1 enable
Example:
Router> enable Enables privileged EXEC mode.
• Enter your password if prompted.

Step 2 configure terminal
Example:
Router# configure terminal Enters global configuration mode.
Step 3 route-map map-tag [permit | deny] [sequence-number]
Example:
Router(config)# route-map metric_range Enters route-map configuration mode.
Step 4 match metric {metric-value | external metric-value} [+- deviation-number]
Example:
Router(config-route-map)# match metric external 500 +- 100 Specifies a match clause that redistributes EIGRP routes that match an internal or external protocol metric.
• metric-value—Internal protocol metric, which can be an EIGRP five-part metric. The range is from 1 to 4294967295.
• external—External protocol metric. The range is from 1 to 4294967295.
• +- deviation-number—(Optional) Represents a standard deviation. The deviation can be any number. There is no default.
• In this example, EIGRP routes that contain an external protocol metric between 400 and 600 inclusive are redistributed.
Note When you specify a metric deviation with the + and - keywords, the router will match any metric that falls inclusively in that range.
Note The external protocol metric is not the same as the EIGRP assigned route metric which is a figure computed from EIGRP vectorized metric components (delay, bandwidth, reliability, load, and MTU).
Step 5 match source-protocol source-protocol [autonomous-system-number]
Example:
Router(config-route-map)# match source-protocol bgp 45000 Specifies a match clause that redistributes EIGRP external routes that match a source protocol.
• source-protocol—Protocol to match. The valid keywords are bgp, connected, eigrp, isis, ospf, rip, and static. There is no default.
• autonomous-system-number—(Optional) Autonomous system number. The autonomous-system-number argument is not applicable to the connected, static, and rip keywords. The range is from 1 to 65535. There is no default.
• In this example, EIGRP external routes that match a source protocol of BGP and the autonomous system 45000.
Step 6 set tag tag-value
Example:
Router(config-route-map)# set tag 5 Sets a tag value of the destination routing protocol when all the match criteria of a route map are met.
• In this example, the tag value of the destination routing protocol is set to 5.
Step 7 exit
Example:
Router(config-route-map)# exit Exits configuration mode to the next highest mode in the CLI mode hierarchy.
Step 8 router eigrp as-number
Example:
Router(config)# router eigrp 1 Configures the EIGRP routing process.
Step 9 network ip-address
Example:
Router(config-router)# network 172.16.0.0 Specifies a network for the EIGRP routing process.
Step 10 distribute-list route-map map-tag in
Example:
Router(config)# distribute-list route-map metric_range in Filters networks received in updates.
• This example uses a route map to filter the networks. The route map named "metric_range" was identifed in Step 3 above.
Verifying EIGRP Metrics
To verify that both the EIGRP metric and the external protocol metrics have been configured, perform the following step.
SUMMARY STEPS
1. enable
2. show ip eigrp topology [autonomous-system-number | ip-address [mask]] [active | all-links | detail-links | pending | summary | zero-successors]
DETAILED STEPS
________________________________________
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Router# enable

Step 2 show ip eigrp topology [autonomous-system-number | ip-address [mask]] [active | all-links | detail-links | pending | summary | zero-successors]
Use this command to display the internal EIGRP metrics for a specified IP address, for example:
Router# show ip eigrp topology 172.16.1.0/24

IP-EIGRP (AS 45000): Topology entry for 172.16.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856
Routing Descriptor Blocks:
0.0.0.0 (Serial4/0), from Connected, Send flag is 0x0
Composite metric is (2169856/0), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0

In the following example, the external EIGRP metrics for a specified IP address are displayed:
Router# show ip eigrp topology 192.168.1.0/24

IP-EIGRP (AS 45000): Topology entry for 192.168.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856
Routing Descriptor Blocks:
0.0.0.0 (Serial4/0), from Connected, Send flag is 0x0
Composite metric is (2169856/0), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 10.89.245.1
AS number of route is 0
External protocol is Connected, external metric is 0
Administrator tag is 0 (0x00000000)
________________________________________
Configuration Examples for EIGRP Support for Route Map Filtering
This section contains the following configuration example:
• Configuring EIGRP Metrics Using a Route Map: Examples
Configuring EIGRP Metrics Using a Route Map: Examples
The following example shows how to configure a route map to match an EIGRP external protocol metric route with an allowable deviation of 100, a source protocol of BGP, and an autonomous system 45000. When the two match clauses are true, the tag value of the destination routing protocol is set to 5. The route map is used to distribute incoming packets for an EIGRP process.
route-map metric_range
match metric external 500 +- 100
match source-protocol bgp 45000
set tag 5
!
router eigrp 1
network 172.16.0.0
distribute-list route-map metric_range in

The following example shows how to configure a route map to match EIGRP routes with a metric of 110, 200, or an inclusive range of 700 to 800. When the match clause is true, the tag value of the destination routing protocol is set to 10. The route map is used to redistribute EIGRP packets.
route-map metric_eigrp
match metric 110 200 750 +- 50
set tag 10
!
router eigrp 1
network 172.21.1.0/24
redistribute eigrp route-map metric_eigrp
Additional References
The following sections provide references related to the EIGRP Support for Route Map Filtering feature.
Related Documents
Related Topic Document Title
IP routing protocols overview and configuration Cisco IOS IP Configuration Guide, Part 2: IP Routing Protocols, Release 12.3
IP routing commands including syntax, usage guidelines, and examples • Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols, Release 12.3T
• Cisco IOS IP Routing Protocols Command Reference, Release 12.2SR
• Cisco IOS IP Routing Protocols Command Reference, Release 12.2SX


Technical Assistance
Description Link
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.
To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. http://www.cisco.com/techsupport


Command Reference
This section documents only commands that are new or modified.
• match metric (IP)
• match source-protocol
• show ip eigrp topology
match metric (IP)
To redistribute routes with the specified metric, use the match metric command in route-map configuration mode. To remove the entry for the redistributed route from the routing table, use the no form of this command.
match metric {metric-value | external metric-value} [+- deviation-number]
no match metric {metric-value | external metric-value} [+- deviation-number]
Syntax Description
metric-value Internal route metric, which can be an Enhanced Interior Gateway Routing Protocol (EIGRP) five-part metric. The range is from 1 to 4294967295.
external External protocol associated with a route and interpreted by a source protocol.
+- deviation-number (Optional) A standard deviation number that will offset the number configured for the metric-value argument. The deviation-number argument can be any number. There is no default.
Note When you specify a deviation of the metric with the + and - keywords, the router will match any metric that falls inclusively in that range.

Command Default
No filtering is performed on a metric value.
Command Modes
Route-map configuration
Command History
Release Modification
11.2 This command was introduced.
12.3(8)T The external and +- keywords and deviation-number argument were added.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines
Use the route-map global configuration command and the match and set route-map configuration commands to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.
The match route-map configuration command has multiple formats. The match commands can be given in any order, and all match commands must "pass" to cause the route to be redistributed according to the set actions given with the set commands. The no forms of the match commands remove the specified match criteria.
A route map can have several parts. Any route that does not match at least one match clause relating to a route-map command will be ignored; that is, the route will not be advertised for outbound route maps and will not be accepted for inbound route maps. If you want to modify only some data, you must configure a second route map section with an explicit match specified.

________________________________________
Note An external protocol route metric is not the same as the EIGRP assigned route metric which is a figure computed using EIGRP vectorized metric components (delay, bandwidth, reliability, load, and MTU).
________________________________________
Examples
In the following example, routes with the metric 5 will be redistributed:
route-map name
match metric 5

In the following example, any metric that falls inclusively in the range from 400 to 600 is matched:
route-map name
match metric 500 +- 100

The following example shows how to configure a route map to match an EIGRP external protocol metric route with an allowable deviation of 100, a source protocol of BGP, and an autonomous system 45000. When the two match clauses are true, the tag value of the destination routing protocol is set to 5. The route map is used to distribute incoming packets for an EIGRP process.
route-map metric_range
match metric external 500 +- 100
match source-protocol bgp 45000
set tag 5
!
router eigrp 45000
network 172.16.0.0
distribute-list route-map metric_range in
Related Commands
Command Description
match as-path Matches a BGP autonomous system path access list.
match community Matches a BGP community.
match interface (IP) Distributes any routes that have their next hop out one of the interfaces specified.
match ip address Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, and performs policy routing on packets.
match ip next-hop Redistributes any routes that have a next hop router address passed by one of the access lists specified.
match ip route-source Redistributes routes that have been advertised by routers and access servers at the address specified by the access lists.
match route-type (IP) Redistributes routes of the specified type.
match tag Redistributes routes in the routing table that match the specified tags.
route-map (IP) Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing.
set as-path Modifies an autonomous system path for BGP routes.
set automatic-tag Automatically computes the tag value.
set community Sets the BGP communities attribute.
set level (IP) Indicates where to import routes.
set local-preference Specifies a preference value for the autonomous system path.
set metric (BGP, OSPF, RIP) Sets the metric value for a routing protocol.
set metric-type Sets the metric type for the destination routing protocol.
set next-hop Specifies the address of the next hop.
set tag (IP) Sets a tag value of the destination routing protocol.

match source-protocol
To match Enhanced Interior Gateway Routing Protocol (EIGRP) external routes based on a source protocol and autonomous system number, use the match source-protocol command in route-map configuration mode. To remove the protocol to be matched, use the no form of this command.
match source-protocol source-protocol [autonomous-system-number]
no match source-protocol source-protocol [autonomous-system-number]
Syntax Description
source-protocol Protocol to match. The valid keywords are bgp, connected, eigrp, isis, ospf, rip, and static. There is no default.
autonomous-system-number (Optional) Autonomous system number. This argument is not applicable to the connected, static, and rip keywords. The range is from 1 to 65535. There is no default.

Command Default
EIGRP external routes are not matched on a source protocol and autonomous system number.
Command Modes
Route-map configuration
Command History
Release Modification
12.3(8)T This command was introduced.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines
This command may not be useful with a redistribution operation that employs route maps because redistribution usually requires the configuration of a source protocol and an autonomous system value in order to redistribute. In many cases, it is more useful to configure a route map that includes matching the route type based on the source protocol and autonomous system using the distribute-list command for EIGRP.
Examples
The following example shows how to configure a route map to match a source protocol of BGP and an autonomous system 45000. When the match clause is true, the tag value of the destination routing protocol is set to 5. The route map is used to distribute incoming packets for an EIGRP process.
route-map metric_source
match source-protocol bgp 45000
set tag 5
!
router eigrp 45000
network 172.16.0.0
distribute-list route-map metric_source in
Related Commands
Command Description
distribute-list Filters networks received in updates.
match as-path Matches a BGP autonomous system path access list.
match community Matches a BGP community.
match interface (IP) Distributes any routes that have their next hop out one of the interfaces specified.
match ip address Distributes any routes that have a destination network number address that is permitted by a standard or extended access list, and performs policy routing on packets.
match ip next-hop Redistributes any routes that have a next hop router address passed by one of the access lists specified.
match ip route-source Redistributes routes that have been advertised by routers and access servers at the address specified by the access lists.
match route-type (IP) Redistributes routes of the specified type.
match tag Redistributes routes in the routing table that match the specified tags.
route-map (IP) Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing.
set as-path Modifies an autonomous system path for BGP routes.
set automatic-tag Automatically computes the tag value.
set community Sets the BGP communities attribute.
set level (IP) Indicates where to import routes.
set local-preference Specifies a preference value for the autonomous system path.
set metric (BGP, OSPF, RIP) Sets the metric value for a routing protocol.
set metric-type Sets the metric type for the destination routing protocol.
set next-hop Specifies the address of the next hop.
set tag (IP) Sets a tag value of the destination routing protocol.
set weight Specifies the BGP weight for the routing table.

show ip eigrp topology
To display entries in the Enhanced Interior Gateway Routing Protocol (EIGRP) topology table, use the show ip eigrp topology command in privileged EXEC mode.
show ip eigrp topology [autonomous-system-number | ip-address [mask] | name [interfaces]] [active | all-links | pending | summary | zero-successors]
Syntax Description
autonomous-system-number (Optional) Autonomous system number.
ip-address (Optional) IP address. When specified with a mask, a detailed description of the entry is provided.
mask (Optional) Subnet mask. The mask is entered as a slash mark followed by the prefix length.
name (Optional) EIGRP-IPv4 topology table name. This name is the topology identifier and shows the topology-related information for Multi-Topology Routing (MTR).
interfaces (Optional) Displays information about interfaces, on which EIGRP is configured, in a topology.
active (Optional) Displays only active entries in the EIGRP topology table.
all-links (Optional) Displays all entries in the EIGRP topology table.
pending (Optional) Displays all entries in the EIGRP topology table that are waiting for an update from a neighbor or are waiting to reply to a neighbor.
summary (Optional) Displays a summary of the EIGRP topology table.
zero-successors (Optional) Displays available routes in the EIGRP topology table.

Command Default
If this command is used without any keywords or arguments, then only routes that are feasible successors are displayed.
Command Modes
Privileged EXEC
Command History
Release Modification
10.0 This command was introduced.
12.3(8)T This command was enhanced to display internal and external EIGRP routes.
12.2(33)SRA This command was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SRB The name argument and interfaces keyword were added to support MTR.
12.2(33)SXH This command was integrated into Cisco IOS Release 12.2(33)SXH.

Usage Guidelines
The show ip eigrp topology command can be used without any keywords or arguments. If this command is used without any keywords or arguments, then only routes that are feasible successors are displayed. The show ip eigrp topology command can be used to determine Diffusing Update Algorithm (DUAL) states and to debug possible DUAL problems. The show ip eigrp topology name command option indicates that the output displayed will be for a named service topology for MTR.
Examples
The following is sample output from the show ip eigrp topology command:
Router# show ip eigrp topology

IP-EIGRP Topology Table for process 77

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status

P 10.16.90.0 255.255.255.0, 2 successors, FD is 0
via 10.16.80.28 (46251776/46226176), Ethernet0
via 10.16.81.28 (46251776/46226176), Ethernet1
via 10.16.80.31 (46277376/46251776), Serial0
P 10.16.81.0 255.255.255.0, 1 successors, FD is 307200
via Connected, Ethernet1
via 10.16.81.28 (307200/281600), Ethernet1
via 10.16.80.28 (307200/281600), Ethernet0
via 10.16.80.31 (332800/307200), Serial0

In the following examples, EIGRP metrics for specified internal and external routes are displayed:
Router# show ip eigrp topology 10.2.1.0/24

IP-EIGRP (AS 1): Topology entry for 10.2.1.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600 Routing Descriptor
Blocks:
0.0.0.0 (Ethernet0/0), from Connected, Send flag is 0x0 Composite metric is (281600/0),
Route is Internal !This is the internal route.
Vector metric: Minimum bandwidth is 10000 Kbit
Total delay is 1000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0

Router# show ip eigrp topology 10.4.80.0/20

IP-EIGRP (AS 1): Topology entry for 10.4.80.0/20

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
Routing Descriptor Blocks:
10.2.1.1 (Ethernet0/0), from 10.2.1.1, Send flag is 0x0
Composite metric is (409600/128256), Route is External !This is the external route.
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 10.89.245.1
AS number of route is 0
External protocol is Connected, external metric is 0
Administrator tag is 0 (0x00000000)

Table 1 describes the significant fields shown in the displays.
Table 1 show ip eigrp topology Field Descriptions
Field Description
Codes State of this topology table entry. Passive and Active refer to the EIGRP state with respect to this destination; Update, Query, and Reply refer to the type of packet that is being sent.
P - Passive No EIGRP computations are being performed for this destination.
A - Active EIGRP computations are being performed for this destination.
U - Update Indicates that an update packet was sent to this destination.
Q - Query Indicates that a query packet was sent to this destination.
R - Reply Indicates that a reply packet was sent to this destination.
r - Reply status Flag that is set after the software has sent a query and is waiting for a reply.
10.16.90.0 Destination IP network number.
255.255.255.0 Destination subnet mask.
successors Number of successors. This number corresponds to the number of next hops in the IP routing table. If "successors" is capitalized, then the route or next hop is in a transition state.
FD Feasible distance. The feasible distance is the best metric to reach the destination or the best metric that was known when the route went active. This value is used in the feasibility condition check. If the reported distance of the router (the metric after the slash) is less than the feasible distance, the feasibility condition is met and that path is a feasible successor. Once the software determines it has a feasible successor, it need not send a query for that destination.
via IP address of the peer that told the software about this destination. The first n of these entries, where n is the number of successors, is the current successors. The remaining entries on the list are feasible successors.
(46251776/46226176) The first number is the EIGRP metric that represents the cost to the destination. The second number is the EIGRP metric that this peer advertised.
Ethernet0 Interface from which this information was learned.
Serial0 Interface from which this information was learned.

Feature Information for EIGRP Support for Route Map Filtering
Table 2 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

________________________________________
Note Table 2 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
________________________________________
Table 2 Feature Information for EIGRP Support for Route Map Filtering
Feature Name Releases Feature Information
EIGRP Support for Route Map Filtering 12.2(33)SRA
12.2(33)SXH
12.3(8)T The EIGRP Support for Route Map Filtering feature enables EIGRP to interoperate with other protocols by filtering inbound and outbound traffic based on complex route map options. In addition to the existing route map facility, several extended filtering options are introduced to provide EIGRP-specific match choices.
The following commands were introduced or modified by this feature: match metric (IP), match source-protocol, show ip eigrp topology.

like it

Facebook - Bill Singh - Brand New Album Download from 5abimusic
posted by Tigerstyle Micky at 5abi Music - 3 days ago
Bloom Records Proudly Presents their second brand new album FACEBOOK BY BILL SINGH ..After a long time BILL SINGH is back again with his Brand New Album FACEBOOK with 8 mind blowing and smashing tracks ...

Legends Of 84 (Legends Of khalistan) New Shaheedi Album
posted by Tigerstyle Micky at 5abi Music - 3 days ago
New Shaheedi Album Named -Legends Of 84(Legends Of khalistan) This Mixtape is Dedicated To All Shaheeds Of Sikh movement ,Who Give Secrifices Before and After 1984.........More Information Will Be Given ...

Yaar Anmulle - Sharry Maan Download New Album from 5abi Music
posted by Tigerstyle Micky at 5abi Music - 4 days ago
Yaar Anmulle - Sharry Maan *= TrackList =-* 01 Yaar Anmulle 02 Kalakaar 03 Ilets 04 Khand Mishri 05 Chandigarh Da Chaska 06 Kudiyan Te Bussan 07 Dil Dekhe Yaaran De 08 Dhiyan 09 Suhe Bullan De Naal 10 ...

Intoxicating Hits Ft. Gippy Grewal , Jazzy B , Kaka Bhaniwala , Punjabi MC , Bhinda Aujla , More
posted by Tigerstyle Micky at 5abi Music - 4 days ago
Intoxicating Hits Ft. Gippy Grewal , Jazzy B , Kaka Bhaniwala , Punjabi MC , Bhinda Aujla , More *= TrackList =-* * * *01 Bohemia & Gippy Grewal Sharabi 02 Sona Family Glassy 03 Jazzy B Glassy 04 Swami...

Unbreakable - DJ Sanj Download New Album
posted by Tigerstyle Micky at 5abi Music - 4 days ago
Unbreakable - DJ Sanj *= TrackList =-* 1 Satwinder Birdi Mitran Di Jaan 2 Dolly Sidhu Satwinder Birdi Talaak 3 Miss Pooja Neriyan (DesiFlex Remix) 4 Master Saleem Teray Hussan Dey Maare (Hiphop Remix...

Satinder Sartaj’ s Marriage with Gauri in Taj Hotel
posted by Tigerstyle Micky at 5abi Music - 4 days ago
[image: Short Story- Arranged Marriage]Satinder Sartaj got married to his long time love interest Gauri today on 9 December, 2010 in a private ceremony at Hotel Taj, Chandigarh. The long awaited and much...

ਸਤਿੰਦਰ ਸਰਤਾਜ ਵਿਆਹ ਦੇ ਬੰਧਨ ‘ਚ ਬੱਝੇ
posted by Tigerstyle Micky at 5abi Music - 4 days ago
ਮੋਹਾਲੀ, 9 ਦਸੰਬਰ (ਨਿਆਮੀਆਂ)- ਪੰਜਾਬ ਦੇ ਪ੍ਰਸਿੱਧ ਗਾਇਕ ਸਤਿੰਦਰ ਸਰਤਾਜ ਅੱਜ ਗ੍ਰਹਿਸਤ ਜੀਵਨ ਵਿਚ ਪ੍ਰਵੇਸ਼ ਕਰ ਗਏ। ਪੰਜਾਬ ਯੂਨੀਵਰਸਿਟੀ ਚੰਡੀਗੜ੍ਹ ਦੀ ਵਿਦਿਆਰਥਣ ਨਿਰਭੈ ਕੌਰ ਉਰਫ ਗੌਰੀ ਜੋ ਕਿ ਉਥੇ ਪੀ. ਐੱਚ. ਡੀ. ਕਰ ਰਹੀ ਹੈ, ਦੇ ਨਾਲ ਸਤਿੰਦ...

Kamal Heer Facebook Official Video
posted by Tigerstyle Micky at 5abi Music - 4 days ago
plasmarecords December 16, 2010 Show Booking 0181-2282121 Or 098766-02821.This a brand new video of my song called Facebook. I sang this song in Punjabi Virsa 2010 in Canada and theUS. Due to popular ...

Sip Sip-Inderjit Nikku & Gagz Mehta (official video)
posted by Tigerstyle Micky at 5abi Music - 4 days ago
channelgagz December 14, 2010 Track : SIP SIP Singer : GAGZ MEHTA & INDERJIT NIKKU muzic : AMERY MC Lyrix : SAHIB SEKHON Video : CHANNEL GAGZ Company : T-SERIES Costumes : STREAK

G-Deep-O’Billo latest album full download
posted by Tigerstyle Micky at 5abi Music - 1 week ago
G-deep is Coming your way with his new Album “O-billo”.Album is Set to Release this month with two big Videos “nach le” and ‘O billo’.In Nach le,G-deep featuring havoc for a Hip Hop Punjabi track.So ...

Brand New Punjabi Song Heart Beat By Geeta Zaildar ( Feat Roach Killa )
posted by Tigerstyle Micky at 5abi Music - 1 week ago
DOWNLOAD THIS VIDEO HERE . Song: Heart Beat Artist: Geeta Zaildar Music: Aman Hayer Album: Close 2 Me Label: Speed Records Video : Rimpy Prince

Karran Jesbir ft. Honey Singh - Chandigarh (Full Video)
posted by Tigerstyle Micky at 5abi Music - 1 week ago
DOWNLOAD THIS VIDEO HERE . Check out the Full Video, the second video coming of the album, "Zanjeer - The Game Changer" for the track "Chandigarh". The Song has been highly appreciated all over the ...

Yaar Anmulle Feat. Sharry Mann Promo video [Teaser 15 sec]
posted by Tigerstyle Micky at 5abi Music - 1 week ago
DOWNLOAD THIS VIDEO IN MP4 Speed Records Presents Yaar Anmulle Sharry Mann Official Video Teaser 15 sec cc1ae200

Humble the Poet - Beautiful Mistake (Films by AK)
posted by Tigerstyle Micky at 5abi Music - 1 week ago
DOWNLOAD THIS VIDEO http://www.thepoetproject.com http://www.facebook.com/humblethepoet Films by AK ======LYRICS===== we living in the 21st century where potentially mentally we are conquered and...

Juggy D - PUNJABI ROCKSTAR (OFFICIAL VIDEO)
posted by Tigerstyle Micky at 5abi Music - 1 week ago
DOWNLOAD THIS VIDEO HERE . Juggy D International Presents - Punjabi Roackstar by: Juggy D. Music By: MENTOR BEATS Video by: BEE2 - The Sound Pipe

Yaar Anmule Lyrics in punjabi
posted by Tigerstyle Micky at 5abi Music - 1 week ago
*----Thanks to 5abi Music----*

Desi Jatt - Gippy Grewal New HQ Official Video
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Check out the latest video by Gippy Grewal coming off the brand new album titled 'Desi Rockstar' which is out now; with music from Aman Hayer! The Video is directed by Rimpy Prince. DOWNLOAD FULL H...

Music Master - Ft.Jazzy B, Gippy Grewal, Mikka, Raj Brar , More New Album
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Music Master - Ft.Jazzy B, Gippy Grewal, Mikka, Raj Brar , More *= TrackList =-* * * 01 Jazzy B Naag 2 02 Gippy Grewal Hathyaar Ft. Roach Killa 03 Amrinder Gill & Sukhwinder singh Ik Kudi P...

52 NON-STOP-The Dancing Queen Miss Pooja Download full album
posted by Tigerstyle Micky at 5abi Music - 1 week ago
----Tracklists---- Right click on song and select " save target as " 01 Akh(MrJatt.Com) 02 Channa Sachchi Muchi(MrJatt.Com) 03 Raati Supne Ch(MrJatt.Com) 04 Haan Karde(MrJatt.Com) 05 Chandigarh(MrJatt.Co...

Jimmy Shergill ‘s Dharti-upcoming movie
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Soon after Mel Karade Rabba was released, there was news about Jimmy Shergill turning into a producer and making a Punjabi/Bi-lingual film soon. The wait is over… Navaniat Singh, the director of Smash Hi...

Geeta Zaildar Teams up with Roach Killa on 'Heart Beat' New Album
posted by Tigerstyle Micky at 5abi Music - 1 week ago
*Geeta Zaildar* has collaborated with producer Aman Hayer on his album *Close 2 Me*. Bringing some modern day edge to the album, Geeta has now teamed up with *Roach Killa* on his single "*Heart Beat*." R...

GIPPY GREWAL DESI JATT PROMO OF DESI ROCKSTAR ALBUM
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Album : Desi Rockstar Director/Editor/DOP/Colourist: Baljit Singh Deo Production Manager: Baljinder Sanghera Gippy Grewal Video from "Desi Rockstar" Here are some stills from the video and will be release...

HONEY SINGH FT DILJIT DOSANJH THE SANJH 2011 SOON..
posted by Tigerstyle Micky at 5abi Music - 1 week ago
*Singer : Diljit Dosanjh Ft. Honey Singh* Music : Honey Singh Album Name : The Sanjh Relese in : 2011 More News Up Soon

BAI AMARJIT & HONEY SINGH COMING WITH NEW ALBUM IN 2011
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Singer : Bai Amarjit Ft. Honey Singh Music : Honey Singh Album Name : Not Announced Relese Date : Not Announced Proms & More News Update Soon

PREET HARPAL MIKA DILJIT DOSANJH & MORE FT. HONEY SINGH
posted by Tigerstyle Micky at 5abi Music - 1 week ago
*Singer : Preet Harpal , Mika , Diljit Dosanjh & More Ft. Honey Singh Music : Honey Singh Album Name : Not Announced Relese Date : December 2010 More News & Promo Come Up Soon*

Raj Brar Ft. Honey Singh Coming With New Album in 2011
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Singer : Raj Brar Ft. Honey Singh Music : Honey Singh Album Name : Not Sure Relese Date : Coming in 2011

Honey Singh Feat. Balli Riar - Never Done Before New Album Coming Soon
posted by Tigerstyle Micky at 5abi Music - 1 week ago
* * *Singer : Balli Riar Ft. Honey Singh Music : Honey Singh Album Name : Never Done Before Relese Date : December 2010 Proms & More News Update Soon*

Honey Singh's upcoming 5 albums in 2011
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Great news for Honey Singh's Fans............ He is coming in 2011 with some big Artists & New Young Singers......... Here is some info about his upcoming projects....... Honey Singh Feat. Diljit Dosa...

Close 2 Me - Geeta Zaildar Download Full Album
posted by Tigerstyle Micky at 5abi Music - 1 week ago
----Tracklist---- 01 Love You 02 Sair 03 Darro 04 Aao Nachiye 05 Stay Close To Me 06 Sumander 07 Ranjhe 08 Heartbeat (Feat Roach Killa) [ 128 kbps ] http://www.mediafire.com/?4i189j96dg9h2v8 [ 320 kbps ...

Kangna - Ft.Nikku , Lehmber , Feroz Khan , Surinder Shinda New Album
posted by Tigerstyle Micky at 5abi Music - 1 week ago
----Tracklist---- Aman Riar Dekhin Kithe() Balvir Boparai Ni Das Kithon() Balvir Boparai Uhne Puchheya Jadon() Feroz Khan Sohneya Dil Nahi Lagda() Gagz Mehta & Inderjit Nikku Sip Sip() Lehmber Hussainpur...

JADOO – SUKSHINDER SHINDA DOWNLOAD NEW ALBUM
posted by Tigerstyle Micky at 5abi Music - 1 week ago
----Tracklist---- *Right click on track and select save target as * 01 La LaLa 02 Samne 03 Jadoo 04 Maujan Lut Mitra 05 Mere Dil Teh( 06 Mere Munde Nu 07 Jatt London 08 Akh Labdi 09 Bas Kar Bas Kar 10 Addr...

Saroor - Amrit Saab Download New Album
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Album Name : Saroor Album Artists : Amrit Saab Music : Amrit Saab Lyrics : Amrit Saab Audio Release : Nov. 2010 Cassettes and CD's on : T-Series ----Tracklist---- 01 Amrit Saab Mehfil() 02 Amrit Saab Sakk...

Juggy D - Punjabi Rockstar Download mp3 full song
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Juggy D is back with a promo for his upcoming album *Punjabi Rockstar*. Juggy D started his career under the wing of producer Rishi Rich. Juggy was the Punjabi sound on the 2 Point 9 tunes, juxtaposing Ja...

JADOO – SUKSHINDER SHINDA PROMO CD NEW ALBUM
posted by Tigerstyle Micky at 5abi Music - 1 week ago
Album Name : Jadoo Album Artists : Sukshinder Shinda Release:02 December 2010 Cassettes and CD’s on : ℗ 2010 Moviebox ———– Promo CD ———– Ripped By : *PunjabWap.Com* ——————– 1-La La-La (PunjabWap.Com) 2-...
ADDMANAGE
What is Followin