Wonders of Telecom: CCIE

Showing posts with label CCIE. Show all posts

Wednesday, April 6, 2011

The mission is completed !!!

I got the email from CISCO few days ago, saying

"Congratulations on successfully completing the CCIE Certification - Service Provider certification requirements."

CCIE Service Provider # 28419

I never though that it will sound so good :)

Thanks for your support and all my friends who is pushing me to this great moment.
Ramses, Edwin, Yaniv, Shmuel, Itai, Alex, Chen, Amir, Moshe....

Now i will concentrate on my next mission , CCDE.

Starting from CCDA -> CCDP -> CCDE.

I think it will work.
CCDA completed till July 2011
CCDP completed till Dec 2011
CCDE completed till DEC 2012

Saturday, May 15, 2010

New date for EXAM...

Scheduled today a day for next attempt, 7/1/2011. Hopefully this time is the "number" attempt. Starting in June to work hard.

Wednesday, April 21, 2010

Starting new preparation. Day One. Reading...

Ok, since my last (not the first) attempt wasn't so good , I am planing to read a few book from CISCO recommendation list and post the summary here.

I will start with: Advanced MPLS Design and Implementation:

Chapter 1:
MPLS is an improved method for forwarding packets through a network using information contained in labels attached to IP packets. The labels are inserted between the Layer 3 header and the Layer 2 header in the case of frame-based Layer 2 technologies, and they are contained in the virtual path identifier (VPI) and virtual channel identifier (VCI) fields in the case of cell-based technologies such as ATM.

Benefits of MPLS - VPN's (solves the issues with IPsec (have a very high overhead and are slow and not scalable)), Traffic Engineering, QoS, Integration IP and ATM, simplify the deployment of IPv6,

Wednesday, April 7, 2010

Understand Reverse-Path Forwarding (RPF)

Reverse-Path Forwarding (RPF) is an algorithm used for forwarding multicast datagram's.
It functions as follows:

• If a router receives a datagram on an interface that it uses to send unicast packets to the source, the packet has arrived on the RPF interface.

(then)

• If the packet arrives on the RPF interface, a router forwards the packet out the interfaces that are present in the outgoing interface list of a multicast routing table entry.

(else)

• If the packet does not arrive on the RPF interface, the packet is silently discarded to prevent loops.

PIM uses both source trees and RP-rooted shared trees to forward datagram's; the RPF check is performed differently for each.

• If a PIM router has source-tree state (that is, an (S,G) entry is present in the multicast routing table), the router performs the RPF check against the IP address of the source of the multicast packet.

• If a PIM router has shared tree state (and no explicit source-tree state), it performs the RPF check on the RP's address (which is known when members join the group).

Sparse-mode PIM uses the RPF lookup function to determine where it needs to send Joins and Prunes. (S,G) Joins (which are source-tree states) are sent toward the source.
(*,G) Joins (which are shared-tree states) are sent toward the RP.

DVMRP and dense-mode PIM use only source trees and use RPF as described above.

Core Knowledge Question (OEQ) material to read for CCIE SP

Tuesday, April 6, 2010

Brussels, Belgium here i come .....

Ok, final 3 days before my exam. Is not my first attempt and i hope it is a last one!!!
Today arrived to Brussels for my attempt in CCIE SP, went to Cisco offices to talk and meet the proctor but on reception very nice lady told me "it is impossible - he is in middle of the test , what did you think to your self?". Strange, in US (RTP) it was very different, proctor is nice and he come to you outside to give you a little briefing about the exam, but no, here is different.
Anyway, i turn around and come back to hotel to read more before this f$%&@# OEQ question.
New stuff added from my previous trying, it is evil OEQ (Core Knowledge Questions - cisco way to call it - common...).

"

04 Jan 2010

Core Knowledge Questions on Remaining CCIE Lab Exams

Effective January 4, 2010, CCIE Service Provider, Storage and Wireless lab exams will begin with a brief Core Knowledge section consisting of four, computer-delivered short-answer questions. The Core Knowledge section was added to CCIE Routing and Switching, Security and Voice earlier in the year. Candidates will type in their answers, which typically require five words or less. Questions will cover topics included on the current lab exam blueprint. Candidates are allowed a maximum of 30 minutes to complete the questions and may not use the Cisco documentation which is available for the remainder of the lab. Well-prepared candidates should be able to answer the questions in 15 minutes or less and move immediately to the next section. No extra time is being added to the eight-hour exam. All candidates must pass the Core Knowledge section in order to achieve CCIE certification.

"
Except OEQ for the lab itself i think i am ready but you never can know what to expect.
This is the beauty of this CCIE.
I study almost 1.5 years to feel that way, it is not coming easy i can tell you.
So to the practical stuff:
LAB: did all the possible labs that available on the market today: Internetwork Expert, IPExpert, CCbootcamp and a lot of mini labs from Antonio Soares ( I think personally this guy did amazing job, including configurations and different videos on his site - please visit to learn - http://ccie18473.net/ ).
After my first attempt i understood that this labs are far far away from the reality, but it is a good way to start and touch every thing that you need ( basically everything that you see on the blueprint :) ).
Now to the OEQ, Now i have a three days before my exam and i am going to read all my notes writen during this year.
It is not simple as that but i am going to focus on this now.
Going to read....

Friday, January 1, 2010

Undocumented Cisco Commands

http://www.elemental.net/~lf/undoc/

Tuesday, December 29, 2009

Show ISIS DIS on a LAN segment

PE2#sh run int fa0/0
interface FastEthernet0/0
ip address 50.50.50.1 255.255.255.0
ip router isis
speed 10
full-duplex
isis priority 120
end

PE2#sh clns interface fa0/0
FastEthernet0/0 is up, line protocol is up
Checksums enabled, MTU 1497, Encapsulation SAP
ERPDUs enabled, min. interval 10 msec.
RDPDUs enabled, min. interval 100 msec., Addr Mask enabled
Congestion Experienced bit set at 4 packets
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 46 seconds
Routing Protocol: IS-IS
    Circuit Type: level-1-2
    Interface number 0×2, local circuit ID 0×1
    Level-1 Metric: 10, Priority: 120, Circuit ID: PE2.01
    DR ID: PE2.01
    Level-1 IPv6 Metric: 10
    Number of active level-1 adjacencies: 1
    Next IS-IS LAN Level-1 Hello in 1 seconds
PE2#

P1#sh run int fa0/0
interface FastEthernet0/0
ip address 50.50.50.3 255.255.255.0
ip router isis ! default priority is 64
speed 10
full-duplex
end

P1#sh clns interface fa0/0
FastEthernet0/0 is up, line protocol is up
Checksums enabled, MTU 1497, Encapsulation SAP
ERPDUs enabled, min. interval 10 msec.
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 17 seconds
Routing Protocol: IS-IS
    Circuit Type: level-1-2
    Interface number 0×2, local circuit ID 0×1
    Level-1 Metric: 10, Priority: 64, Circuit ID: PE2.01
    DR ID: PE2.01
    Level-1 IPv6 Metric: 10
    Number of active level-1 adjacencies: 1
    Level-2 Metric: 10, Priority: 64, Circuit ID: PE1.01
    DR ID: PE1.01
    Level-2 IPv6 Metric: 10
    Number of active level-2 adjacencies: 1
    Next IS-IS LAN Level-1 Hello in 1 seconds
    Next IS-IS LAN Level-2 Hello in 6 seconds
P1#

Wednesday, December 23, 2009

Poor Man’s VPLS

By Petr Lapukhov, CCIE #16379

Let’s say you get a bunch of inexpensive (but a bit outdated) routers (36XX or 72Xx) and some really nice (maybe not so cheap) Cisco switches (e.g. 3550/3560) and you would like to provide a VPLS-like service to your customers. Since VPLS is a service available only on more powerful Cisco platforms, we have to figure a way to simulate Multipoint Ethernet L2 VPN over a packet switching network (PSN) using only “convenient” point-to-point L2 VPN services.
Let model a situation where we have a number of routers connected over (PSN), with an ethernet switch connected to router at every location:
VPLS with L2TPV3

What we can do, is connect ethernet ports using pseudowires to form a virtual ring topology over PSN. That is, refeferring to our picture, xconnect routers’ ethernet ports counter-clockwise, say xconnect E0/0 of R3 with E0/1 of R4, then E0/0 of R4 with E0/1 of R5 and finally E0/0 of R5 with E0/1 of R3. Effectively, we will form an ethernet ring, partially connected over convenient switches, and partially using L2VPN pseudowires. Router configurations look pretty much similar, for example at R3 we would have something like this

R3:
pseudowire-class PW_CLASS
 encapsulation l2tpv3
 ip local interface Loopback0
!
interface Loopback0
 ip address 150.1.3.3 255.255.255.255

!
! Xconnecting E0/0 of R3 with E0/1 of R4
!
interface Ethernet0/0
 no ip address
 xconnect 150.1.4.4 34 encapsulation l2tpv3 pw-class PW_CLASS

!
! Xconnecting E0/1 of R3 with E0/0 of R5
!
interface Ethernet0/1
 no ip address
 xconnect 150.1.5.5 35 pw-class PW_CLASS

!
! Frame-Relay is used to connect to other routers (PSN network)
!
interface Serial1/0
 no ip address
 encapsulation frame-relay
!
interface Serial1/0.34 point-to-point
 ip address 150.1.34.3 255.255.255.0
 frame-relay interface-dlci 304
!
interface Serial1/0.35 point-to-point
 ip address 150.1.35.3 255.255.255.0
 frame-relay interface-dlci 305 

!
! OSPF is used as a sample IGP
!
router ospf 1
 router-id 150.1.3.3
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

Speaking honestly, it’s not “classic” VPLS in true sense:
Firstly, STP should be running over ring topology, in order to block redundant ports. One can use star topology and disable STP, but this will introduce a single point of failure into the network. Classic VPLS does not run STP over packet core, only a full-mesh of pseudowires.
Secondly, there is no MAC-address learning for pseudowires, since they are point-to-point in essense. MAC addresses are learned by switches, and this impose a usual scalability restriction (though cisco switches may allow you to scale to a few thousands of MAC addresses in their tables).
However, this is funny and simple example of how you can use a simple concept to come up with a more complicated solution.

Catalyst QoS: The 3550 Explained

By Petr Lapukhov, CCIE #16379

QoS features available on Catalyst switch platforms have specific limitations, dictated by the hardware design of modern L3 switches, which is heavily optimized to handle packets at very high rates. Catalyst switch QoS is implemented using TCAM (Ternary Content Addressable Tables) – fast hardware lookup tables – to store all QoS configurations and settings. We start out Catalyst QoS overview with the old, long time available in the CCIE lab, the Catalyst 3550 model.

To begin with, the Catalyst 3550 sees the world as consisting of IP and non-IP (e.g. ARP, IPv6, IPX) packets – the distinction being made based on the Ethertype value in incoming Ethernet frame. This peculiarity is due to the fact that 3550 is a Layer 3 switch, designed to route IP packets in addition to the regular L2 switching. The feature has some impact on QoS classification options of 3550 as we shall see later.
The Catalyst 3550 QoS model is based on Diff-Serv architecture, where each packet is classified and marked, to encode the class value. Packets are given a per-hop treatment at every network node, based on their class (marking). With Diff-Serv architecture, classification and admission control are performed at network (Diff-Serv domain) edges, while network core is used to implement the QoS procedures based on packet classes.
The Catalyst 3550 is capable of performing either Diff-Serv boundary device functions (classification, marking & admission control) or Diff-Serv interior device functions (e.g. queueing & scheduling). Catalyst 3550 understands the following types of marking: 802.1p priority bits (available on trunk ports only) and IP ToS byte (IP packets only) – the latter could be interpreted as either DSCP (64 values) or IP Precedence (8 values). While IP Precedence and DSCP values are naturally applicable to IP packets, CoS is the only possible “transit” (inter-switch) marking available to non-IP packets (in the sense 3550 interprets them).
One may ask, why is the difference between IP Precedence and DSCP when the former seems to be a subset of DSCP classes space? Actually it is true – IP Precedence value x numerically maps directly to CSx under DSCP nomenclature. However, the semantics of IPP and DSCP are different. If we interpret packets under the “Precedence” model (which is old, military based QoS model – Internet begun as a military project, remember?) we should treat it differently then if we were interpreting it under the CSx class of Diff-Serv model. This is why IP Precedence and DSCP marking are usually considered separately.
To finish with marking, keep in mind, that IP packet may come in with both CoS (taken from dot1q/ISL header) and DSCP/IP Precedence values set. Therefore, a Catalyst switch needs a way to handle both markings at the same time. (We’ll discuss this feature in more details later). (Side-note: QoS features on 3550 switch are enabled with the global mls qos command. As soon as you entered this command, all classification settings are set to their default values, and in effect all packets traversing the switch will have their CoS and DSCP values set to zero)
Now, the QoS flowchart for the 3550 Catalyst switch looks as follows:
Stage 1 (Ingress): Classify, Police & Mark.
The goal of this stage is to mark a packet – deduce an internal DSCP value for whatever type of packet (IP or non-IP) has arrived. (Note that we may consider “drop action” as a special kind of “marking” too). Internal DSCP is “unified” marking scheme used inside the switch to perform any QoS-related processing. To deduce the internal DSCP value for non-IP packets (e.g. IPv6), which could only be marked using the CoS field, a special configurable (switch-global) CoS to DSCP translation table is used. This table is applied whether we use CoS to classify an incoming packet, be it IP or non-IP – more on that later.
For IP packets, the new internal DSCP value replaces the original DSCP field in a packet. For non-IP packets, new CoS value is calculated for packets from the internal DSCP using a configurable DSCP to CoS table (which is global to a switch). The latter table is also used on the scheduling stage, to determine egress Queue-ID.
Specifically, to classify non-IP packets a Catalyst switch may either:
a) Trust the CoS value from incoming frame on a trunk link (keep the CoS value encoded in a frame). This option is only applicable to trunk links. (You may consider voice VLAN dot1p option as a rudimentary trunk also).
b) Use the default CoS value assigned to a port. This action is used when no CoS value is present in incoming packet and you configure to trust CoS .You may use this option on either access or trunk links (e.g. 802.1q native VLAN). The default “CoS default” value is zero. You may set it with mls qos cos interface-level command.
A few words on “CoS override mode”. When you configure mls qos cos X override under interface, all packets entering the interfaces are assigned this CoS value, irrespective of any other QoS settings (e.g. trust states). Use this command to quickly assign a “precedence” level to all packets entering an interfaces.
c) Classify and assign CoS value based on QoS ACLs. You may configure and apply QoS ACL (actually, it’s just a regular ACL) using an ingress policy-map on 3550 switch. Packets matching the ACL are then either trusted, assigned CoS value manually, and/or policed. For non-IP packets you may only use MAC extended access-lists for classification. Note that due to 3550 “blindness” you may only use MAC ACLs to classify only the non-IP packets – MAC ACLs won’t work with the IP packets!
After the CoS value has been deduced for non-IP packet, it is then translated into internal DSCP value by using the configurable CoS to DSCP table. Here is an example:

!
!  CoS -> DSCP mapping table, define 8 DSCP values here (CoS 0..7)
!
mls qos map cos-dscp 16 8 16 24 32 46 48 56

!
!  MAC access-list to match ARP (non IP) packets 
!
mac access-list extended ARP
 permit any any 0x806 0x0
!
class-map ARP
 match access-group name ARP

!
! Assign CoS 3 to ARP packets and police 
!
policy-map CLASSIFY
 class ARP
  set cos 3

!
! Attach service-policy ingress
!
interface FastEthernet 0/4
 mls qos trust cos
 service-policy input CLASSIFY
 mls qos cos 1

More classification options are available for IP packets. First, as mentioned above, an IP packet may arrive encapsulated in Ethernet frame with dot1q or ISL header. That means we may obtain the current marking either from CoS or IP Precedence/DSCP bits. Here is a full list:
a) Trust CoS value for an incoming packet. The CoS to DSCP translation table is then used to deduce the internal DSCP value. You may optionally configure special DSCP pass-through mode with the mls qos trust cos pass-through dscp command. When this mode is active, internal DSCP value is deduced from the CoS field, and all QoS operations are based on it. However, the original DSCP value in packet is not getting overwritten with the new DSCP deduced from CoS field. This feature also works backwards: you may trust DSCP value for an IP packet (discussed later) and leave CoS value untouched, passing it transparently.
b) Use the default CoS value assigned to a port. This option only works if you configure to trust CoS and CoS value is not present in the incoming packet.
c) Trust IP Precedence. Takes the IP Precedence field from the IP packet header, and convert it to internal DSCP value using the configurable IP Precedence to DSCP mapping table. This is pretty straightforward.
d) Trust DSCP value. The DSCP value from an IP packet header is retained and used as internal DSCP. As mentioned above, you may disable CoS rewrite according to DSCP to CoS tables by issuing global-mode command mls qos trust dscp pass-through cos.
d) Use QoS ACLs for classification. You may use standard or extended IP access-list to match incoming packets by applying them with MQC class-maps and policy-maps. Matched packets could be trusted, marked and/or policed. Note that due to TCAM capacity limits you may not be able to fit arbitrary large QoS ACL into hardware.
e) IP packets that did not fall under any of the previous classification options are assigned the DSCP value of zero (best-effort traffic).

!
!  IP extended ACL to match ICMP traffic 
!
ip access-list extended ICMP
 permit icmp any any
!
class-map ICMP
 match access-group ICMP

!
!  TCP traffic 
!
ip access-list extended TCP
 permit tcp any any
!
class-map TCP
 match access-group TCP

policy-map CLASSIFY
 !
 ! Classification combined with policing
 !
 class ICMP
  set ip dscp 26
  police 64000 8000
 class TCP
  trust ip-precedence

!
! Attach service-policy ingress
!
interface FastEthernet 0/4
 mls qos trust dscp
 service-policy input CLASSIFY
 mls qos cos 1

Ingress Policing
Catalyst 3550 switches allow to apply ingress policing to various traffic classes, using DSCP values or IP/MAC ACLs to classify traffic (the latter option is the only one available to non-IP packets). Policing could be combined with marking, by using the MQC policy-maps syntax (set command). You may apply up to 8 ingress policers on any port and up to 8 egress policers. Note, that egress policers support only DSCP-based classification. On GigabitEtherner interfaces number of ingress policers is bigger, but still limited to 128.
A policer in Catalyst 3550 is defined by its average rate, burst size and exceed action. The larger is the burst size, the more tolerable is policer to accident traffic rate “spikes”. No formula exists for optimal burst size – it’s usually calculated basic on empirical results. However, a common recommendation is to configure the burst size to no less than AverageRate*1,5s bytes, since this parameter is suitable for heavy TCP traffic flows (avoids excessive drops and TCP slow-start behavior). Due to the fact that policers are implemented in hardware, you may find that IOS rounds up your burst size to a value more suited for ASIC based implementation.
Exceed actions include drop and markdown (policed DSCP transmit). When you apply a markdown action under a policer, a special global configurable table is used to map an internal DSCP to it’s policed equivalent. E.g. you may want to police down exceeding user traffic from CS0 (e.g. best-effort) to CS1 (e.g. Scavenger). Default markdown settings are to keep DSCP values the same.
Policer could be of two types – individual or aggregate. Individual policer is configured under a class-map assigned under a policy map, and applies only to a single traffic class. Aggregate policers are defined globally, using special command syntax, and shared among multiple classes, configured under a policy map attached to an interface. That is, traffic under all classes configured to share an aggregate policer is policed under the same policer settings. Note that you can’t share an aggregate policer among different ports.

!
! Global markdown configuration
!
mls qos map policed-dscp 0 46 to 1
!
ip access-list extended ICMP_4
 permit icmp any host 150.15.4.4
!
ip access-list extended ICMP_44
 permit icmp any host 150.15.44.44
!
class-map ICMP_4
 match access-group name ICMP_4
!
class-map ICMP_44
 match access-group name ICMP_44
!
!
!
mls qos aggregate-policer AGG1 16000 8000 exceed-action policed-dscp

!
!  Set the default DSCP to 0, remark to CS1 on exceed 
!
policy-map INGRESS_R3
 class ICMP_4
  set ip dscp 0
  police aggregate AGG1
 class ICMP_44
 set ip dscp 0
 police aggregate AGG1

Per-Port Per-VLAN (PPPV) classification
The classification options we considered so far are “port-wise” – i.e. they apply to all traffic arriving on a port, whether it is trunk or access link. However, 3550 switches have special feature called per-por per-VLAN classification, which allows applying a QoS ACL classification method on a per-VLAN basic to a specific port.
PPPV requires a very strict syntax for its configuration. Failing to obey the order of operations will result in non-working and rejected configuration. First, you need to define a class-map to match traffic “inside” a VLAN. This class-map could be based on an IP/MAC ACL or simply match a range of DSCP values. For example:

class-map VOICE_BEARER
 match ip dscp ef

Next you create a second, “parent” class-map, that matches a specific VLAN or VLAN range. The first entry under this class-map must be a match vlan statement. The second (and the last entry) should be match class-map entry, that matches traffic “inside” a VLAN or VLAN range:

class-map match-all VLAN_34_VOICE
 match vlan 34
 match class-map VOICE_BEARER

You then assign the “parent” classes to a policy-map. Note that all classes under this policy-map must contain match vlan as their first entry, and match class-map as their second entry.

class-map SCAVENGER
 match ip dscp 1
!
class-map VLAN_43_SCAVENGER
 match vlan 43
 match class-map SCAVENGER

!
!   Per VLAN policy-map 
!
policy-map PER_VLAN_POLICY
 class VLAN_34_VOICE
  police 128000 32000 exceed policed-dscp
class VLAN_43_SCAVENGER
  police 64000 16000 exceed drop

interface FastEthernet 0/3
 service-policy input PER_VLAN_POLICY

Stage 2 (Egress): Police, Queue & Schedule
Packets arrive on egress with internal DSCP value assigned. Note that security ACL are matched against the original DSCP value, not the one imposed by classification process – this is due to the fact that QoS and Security ACLS are looked up through TCAM in parallel. Therefore VLAN access-map may block your packet based on it’s DSCP original value, no the one assigned by QoS ACLs. So now that packet has arrived to output port, 3550 performs the following:
a) Police traffic stream, based on DSCP value solely. No other classification option exists for egress policers. Note that you are allowed to mix ingress and egress policers on the same interface.

class-map SCAVENGER
 match ip dscp 1
!
policy-map POLICE_SCAVENGER
 class SCAVENGER
  police 64000 8000
!
interface FastEthernet 0/3
 service-policy output POLICE_SCAVENGER

b) Assign a packet to an output queue. 3550 defines 4 output queues (IDs from 1 to 4) for each interface, and packets are assigned to a queue using CoS to Queue-ID interface-level mapping table. Since packet handling is based on internal DSCP value, this value should be mapped to a CoS value, using yet another mapping table (this time global), called DSCP to CoS mapping table (there exists a default mapping, of course). Therefore, to assign a packet to an output queue, two lookups are made: DSCP->CoS & CoS->Queue-ID.

!
! DSCP->CoS global mapping table
!
mls qos map dscp-cos 56 4
!
interface FastEthernet 0/3
!
! CoS to Queue-ID mappings
!
 wrr-queue cos-map 1 0 1
 wrr-queue cos-map 2 2
 wrr-queue cos-map 3 3 6 7
 wrr-queue cos-map 4 5

Next, a check is performed to see if a selected queue has enough buffer space to accommodate another packet. If no space is available, packet is dropped. Buffer space is allocated to queues in the following manner:
For FastEthernet ports, you may configure up to 8 global levels – each level has a numeric value assigned, representing the number of packets allowed on a queue. You may then assign a level to a queue-id on per-interface basis. This limits the per-port flexibility, but is more optimized for hardware handling. The default assignment of levels to queue-ids is 1-4 to 1-4.

mls qos min-reserve 1 170
!
interface FastEthernet 0/3
 wrr-queue min-reserve 1 4
 wrr-queue min-reserve 2 3
 wrr-queue min-reserve 3 2
 wrr-queue min-reserve 4 1

For GigabitEthernet interface, you may configure the queue sizes directly under the interface configuration mode – no global levels need to be referenced. Simply specify how you want to divide the buffer pool of the gigabit port among the queues, by assigning each queue a relative weight value (not an absolute count of packets in queue!).

interface GigabitEthernet 0/1
  wrr-queue queue-limit 20 20 20 40

Packet drop procedure is not as simple as it may seems like. First, for FastEthernet interfaces you are only limited to a simple tail-drop, where the last packet not fitting in a queue is dropped. However, 3550 makes this simple algorithm more flexible – you are allowed to configure to start dropping packets before the queue is actually full. For every queue, it is possible to assign two thresholds – in percents of queue size. If the current queue size exceeds the threshold, new packets are dropped. Why two thresholds? To introduce yet another mapping table! Yes, you can map internal DSCP values to queue-size thresholds – within the interfaces scope – for all queue-ids simultaneously.
This way, you may configure to start dropping “unimportant” packets sooner, say when queue is 80% full, and drop important packets only when the queue is absolutely 100% full (remember you have 64 DSCP classes and just 4 queues – you cant guarantee a queue to every class!). This differentiated drop behavior is actually required per the Diff-Serv model, allowing implementing of different drop precedence for different classes.

interface FastEthernet 0/3
 !
 ! wrr-queue threshold queue-id thresh1% thresh2%
 !
 wrr-queue threshold 1 80 100
 wrr-queue threshold 2 80 100
 wrr-queue threshold 3 50 100
 !
 ! wrr-queue dscp-map threshold-id dscp1, … , dscp8 
 !
 wrr-queue dscp-map 2 46 56 48
 wrr-queue dscp-map 1 0 8 16 24 34

By default, all DSCP values are mapped to threshold 1 and the threshold value is set to 100% of queue size.
For GigabitEthernet intrefaces (uplinks), you may use the same tail-drop procedure, or configure more advanced WRED (Weighted Random Early Detection) as drop policy. Describing WRED in details is beyond the scope of this document, but in short, it allows starting packet drops randomly, before the queue size reaches the configured threshold. This random behavior is specifically designed to overcome TCP over congestion and synchronization problems on loaded links. As with the tail-drop behavior, you may configure two WRED thresholds for each queue, and then map DSCP values to each threshold on per-interface basis. Packet drop probability increases as the queue size reaches the configured threshold.

interface GigabitEthernet 0/1
!
! wrr-queue random max-thresh queue-id thresh1% thresh2%  
!
 wrr-queue random-detect max-threshold 1 80 100
 wrr-queue random-detect max-threshold 2 70 100
 wrr-queue random-detect max-threshold 3 70 100
 wrr-queue dscp-map 2 46 56 48
 wrr-queue dscp-map 1 0 8 16 24 34

c) Schedule/services packets on queue. Now that the packet has been queued, all the interfaces queues are serviced in a round-robin fashion, which is the simplest approximation to the “ideal” GPS (Generalized Processor Sharing) algorithm. The reason to choose such simple scheduler is the need for wire-speed latency of hardware packet switching. You just can’t implement WFQ or CBWFQ effectively for high-density port devices like a L3 switches due to the algorithms higher complexity. However, the scheduler used is not that primitive. Rather, it uses weighted round robin (WRR) to service interface queues. That means, you can assign up to four weights, one to each of the queues, and the scheduler will then service the queues in accordance to their weights.
Say if you assigned weigh values “10 20 30 40” to queues 1, 2, 3 and 4 then every round scheduler will take up to 10 packets from queue 1, no more than 20 packets from queue 2 etc. This way, all queues are services in a very effective manner, which still allows implementing Assured Forwarding behavior per the Diff-Serv model requirements. Note, that WRR does not limit the upper bound of packet rates – it only ensures it queue is services proportional to it’s weight, when interface is heavily congested. Under normal conditions, a queue could claim more bandwidth, than it’s configured by the use of it’s weight. The default weight values are 25 25 25 25. Side Note: The WRR description given here is not the classic WRR algorithm; the latter requires the average packet size for each queue to be known in ahead, in order to adjust weights and provide fairness. Therefore, per the DocCD description, we may assume that scheduling implemented is not the classic WRR, but rather a simplified form of it.

interface FastEthernet 0/3
 wrr-queue bandwdith 10 20 30 40

The last component to interface queue scheduler is priority queue. With each interface, you may configure queue-id 4 to be treated as priority. This means, whether you have any packets on queue-id 4, this queue is always empties first, no matter how many packets are there. Only then the regular WRR queues gets services. Expedite (priority) queue is enabled with priority-queue out command at inerface level:

interface FastEthernet 0/3
!
!  With PQ enabled, you may assign any weight to queue-id 4
!
 wrr-queue bandwdith 10 20 30 1
 priority-queue out

Note that when you have priority-queue enabled, you may configure any WRR weigth for this queue-id (4) – it is not taken in account when servicing WRR queues.
Basically, these are all the important details about 3550 QoS. We did not mention things like DSCP mutations maps, and some other minor features. However, the entire core QoS processing has been described and, hopefully, been made clear to a reader.
Further Reading
Understanding QoS Policing and Marking on the Catalyst 3350
Illustration
Consider the following test topology:
Cat3550-QoS

With the next example we will classify three traffic types on a single port: RIP updates, ICMP packets and IPv6 traffic. We will use policy-map to assign the IP precedence and CoS values to the packets accordingly.

SW3:
ip access-list extended RIP
 permit udp any any eq 520
!
ip access-list extended ICMP
 permit icmp any any

!
! IPv6 Ethertype is 0x86DD
!
mac access-list extended IPV6
 permit any any 0x86DD 0x0

class-map RIP
 match access-group name RIP
!
class-map ICMP
 match access-group name ICMP
!
class-map VOICE
 match ip dscp ef
!
class-map IPV6
 match access-group name IPV6

!
!  Classify and police ingress traffic on the link to R3
!
policy-map CLASSIFY
  class RIP
   set ip precedence 3
  class ICMP
   set ip precedence 4
   police 32000 8000 exceed drop
  class IPV6
   set cos 5
   police 32000 8000 exceed drop
!
mls qos map cos-dscp 0 8 16 24 32 46 48 56
!
!
interface FastEthernet 0/3
 service-policy input CLASSIFY

Verification: Create an access-list on R4 to match the IP packets

R4:
no ip access-list extended MONITOR_34
ip access-list extended MONITOR_34
 permit udp any any eq 520 precedence 3
 permit icmp any any precedence 4
 permit ip any any
!
interface FastEthernet 0/1.34
 ip access-group MONITOR_34 in

Send ICMP packet at a rate enough to kick in the policer exceed action:

Rack15R3#ping 155.15.34.4 repeat 50 size 1000
Type escape sequence to abort.
Sending 50, 1000-byte ICMP Echos to 155.15.34.4, timeout is 2 seconds:
!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!
Success rate is 90 percent (45/50), round-trip min/avg/max = 4/4/9 ms

And verify the access-list at R4:

Rack15R4#show ip access-lists MONITOR_34
Extended IP access list MONITOR_34
    10 permit udp any any eq rip precedence flash (18 matches)
    20 permit icmp any any precedence flash-override (135 matches)
    30 permit ip any any (9 matches)

To check if IPv6 packets are matched by MAC access-list, send highly saturated stream of ICMPv6 echo packets to R4:

Rack15R3#ping 2001:0:0:34::4 repeat 50 size 1000 timeout 1
Type escape sequence to abort.
Sending 50, 1000-byte ICMP Echos to 2001:0:0:34::4, timeout is 1 seconds:
!!!!!!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.
Success rate is 82 percent (41/50), round-trip min/avg/max = 4/7/8 ms

ShareThis

Documentation Update for the CCIE Lab

From Cisco:

CCIE labs changing from UniversCD to Cisco Documentation
On Sept 24 2008 CCIE labs will no longer support using the UniversCD documentation for the lab exam.
All labs are migrating to Cisco Documentation only. For those scheduled to take the CCIE lab prior to Sept 24 access will still be available for UniversCD.
The Cisco Documentation pages have the same information that currently resides on UniversCD, please refer to the links on the CCIE web pages to view these pages and become familiar with the new format.
After Sept 24 2008 only the Cisco Documentation web pages will be available for CCIE labs.

So what does this mean for people taking the lab after Sept 24th? It means you will still have access to everything needed in relation to the documentation but you will need to access it using the link below:
http://cisco.com/web/psa/products/tsd_products_support_configure.html

Tips for Working with the Proctors

“Proctor, Proctor, give me the news, I got a bad case of Multicast blues!”
Are the proctors helpful or not? Many have plenty of opinions on this. At the very least, let’s consider some tips that might help us in working with them…

Be polite! If you are confrontational, they are going to be far less likely to care about you and your silly question about the lab ☺ An example of politeness that I used was to always preface my question with a comment like “I am so sorry to bother you…” or “May I take a moment of your time?”

Demonstrate your mastery of the subject matter in your question. Politely stress that your issue is vagueness or grammar in the task – DO NOT give any indication that it is the material you are struggling with. And while you might be a bit upset that the grammar in the lab is poor, certainly do not go to great lengths to point that out! The proctor you are speaking to may have written that task, and they might take great pride in it! Here is an example of demonstrating your mastery on a subject – “Sir, I am considering the use of Root Guard for this task as I believe it meets the requirements, yet I am concerned about the request that the interface must be Shut Down by a violation. Technically Root Guard does not do this. Root Guard blocks the port using what is termed a root-inconsistent state. Is it still a viable solution even though I am not truly shutting down the port?” You are going to get a lot further with the proctor that way then this way – “Should I use Root Guard for this task?”

Do not be afraid to visit a proctor two or three times about the same question. I did this in the Multicast section and eventually got the guidance I needed.

If you are getting nowhere with a particular proctor, try another one if that is possible at your testing center.

Immediately following a lab attempt, spend some time with the proctors to pick their brains about ways you can improve, their grading system, etc. They are very willing to help typically!

Do not attempt to bribe your proctors. They might take your money – BUT THEY DO NOT GRADE YOUR EXAM! Someone in another time zone grades your exam! ☺

Do you have other tips? Let us know in the comments! Thanks for reading my dear friends! And special thanks to Chris from my Mocklab Workshop for the sample proctor question! He asked it the correct way of course. ☺

By Anthony Sequeira, #15626

A quick overview of basic IGMP timers

In this post we will quickly discuss the use of most commonly needed IGMP timers. First, as we know, multicast routers periodically query hosts on a segment. If there are two or more routers sharing the same segment, the one with the lowest IP address is the IGMP querier (per IGMPv2 election procedure – as you remember, IGMPv1 let the multicast routing protocol define the querier).

The periodic interval is defined using the command:
ip igmp query-interval [interval in secs]
The hosts on the segment are supposed to report their group membership in response to the queries. Note that IGMPv2 defines special report suppression procedure, which allows host to suppress its own report, if it saw some other host reporting the same group. The query-interval timer is also used to define the amount of time a router will store particular IGMP state if it does not hear any reports on the group. This interval is 3xquery-time and it was the only mechanism available in IGMPv1 to expire a non-needed group. By default the interval is 60 seconds.
From what we said above follows that hosts must respond to a query during some time-window interval. This time window is specified in IGMPv2 packets using special field that defines the maximum response time. You set the value of this field using the command:
ip igmp query-max-response-time [time-in-seconds]
When a host receives the query packet, it starts counting to a random value, less that the maximum response time. When this timer expires, host replies with a report, provided that no other host has responded yet. This accomplishes two purposes:
a) Allows controlling the amount of IGMP reports sent during a time window.
b) Engages the report suppression feature, which permits a host to suppress its own report and conserve bandwidth.
Naturally, the maximum response timer could not be less than the query-interval. Note that IGMPv1 does not support the maximum response time field in its packets, and this timer is fixed to 10 seconds with version 1.
The next important timer, pertaining to IGMPv2, is last member query interval. This interval is configured using the following command:
ip igmp last-member-query-interval [interval in ms]
IGMP uses this value when router hears IGMPv2 Leave report. This means that at least one host wants to leave the group. After router receives the Leave report, it checks that the interface is not configured for IGMP Immediate Leave (single-host on the segment) and if not, it sends out an out-of-sequence query. The maximum-response-time in this query is set to last-member-query-interval which is 1000ms by default. The router sends out maximum of
ip igmp last-member-query-count [number]
messages and if no one responds during this time, the router removes the IGMP state for the group. The whole procedure controls if there are any more members left on the interface. After the last query send router waits some additional time, approximately 0,5 second to finally remove the group. So by default, after a reception of the Leave message the router waits for 2×1000ms+0,5seconds before stopping the multicast traffic flow.
If the interface is configured for immediate leave for a specific group list using the command:
ip igmp immediate-leave group-list [list]
Then the router will treat these groups as having single host member. After the reception of a Leave message, the router immediately removes the multicast forwarding state.
The last interesting timer is
ip igmp query-timeout [timeout]
This timer is used by “silent” routers, i.e. the routers that lost the IGMP querier election process. If the inactive routers did not hear any query for the 2 * [timeout] interval, they start election process again.
And in the end, a quick command to learn all default IGMP timer values:

Rack21R5#show ip igmp interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet address is 129.21.59.5/24
  IGMP is enabled on interface
  Current IGMP host version is 2
  Current IGMP router version is 2
 IGMP query interval is 60 seconds
  IGMP querier timeout is 120 seconds
  IGMP max query response time is 10 seconds
  Last member query count is 2
  Last member query response interval is 1000 ms
  Inbound IGMP access group is not set

By Petr Lapukhov, CCIE #16379

Have you seen my Router ID?

There is more than one possible solution for this challenge. Feel free to post your proposed answer in the comments section. We will try to keep comments hidden from public view, so that the fun isn’t spoiled for others. Also, don’t feel bad if the answer(s) aren’t immediately apparent. A number of very bright people have been puzzled by this scenario. Answers will be posted on Friday, September 18th.
Scenario:
R1 and R2 are configured with their FastEthernet interfaces on the same subnet. R1 will be forming an OSPF neighbor adjacency to R2 over the FastEthernet interface, and will also be advertising some loopback networks into OSPF.
R1R2

R1’s Relevant Configuration:

interface Loopback1
 ip address 1.1.1.1 255.255.255.255

interface Loopback11
 ip address 11.11.11.11 255.255.255.255

interface Loopback111
 ip address 111.111.111.111 255.255.255.255

interface FastEthernet0/0
 ip address 150.10.12.1 255.255.255.0
 no shut

R2’s Relevant Configuration:

interface FastEthernet0/0
 ip address 150.10.12.2 255.255.255.0
 no shut

router ospf 1
 network 150.10.12.0 0.0.0.255 area 0

Challenge:
Your task is to configure R1 while meeting all of the following criteria for requirements and restrictions:

R2 should see the networks 1.1.1.1/32, 11.11.11.11/32, and 111.111.111.111/32 as OSPF routes in R2’s routing table, but they should not appear as IA, E2, or E1.
The output of “show ip ospf neighbor” on R2 should show 11.11.11.11 as the Neighbor ID for the adjacency to R1, even if R1 is reloaded. No other Neighbor IDs should show up on R2.
You are not allowed to use the “router-id” command on R1.
You are not permitted to shut down any interfaces on R1, or remove any of the existing configuration on R1.
No additional configuration may be added to R2, all configuration for this challenge is done on R1.

By Marvin Greenlee, CCIE #12237

CCIE Lab Strategy – Task Dissection

In yesterday’s post, titled “Have you seen my Router ID?”, a challenge section was provided. This post will focus on scrutinizing the section itself, from a strategy / analysis point of view.
From a high level overview, we have two devices peering OSPF over a FastEthernet link, with some loopback networks advertised by one side, and received on the other router. If that was all that the section was asking for, then it should be a task that anyone at CCNA level could complete. When looking at the higher levels of certification, to some point you’re still configuring some of the same items, but you are expected to know more and more about the underlying technologies, theories, and interactions.
Just like other practice lab sections, we are provided with a list of bullet points. In order to get full credit for the section, we need to make sure that we are meeting ALL of the stated requirements. In the event that you don’t know how to complete ALL the items, you are usually better off skipping the section, unless it is needed for core connectivity. When you’re in the studying phase, it’s also a good idea to play “what if”, and ask yourself how you would achieve the task if the section were worded slightly differently.
Make sure that you take the time to read carefully, rather than just diving into a configuration. Make sure that you are carefully taking the time to understand exactly what is being asked.
Taking a look at the individual bullet points:

1. R2 should see networks A, B, and C as OSPF routes in R2’s routing table, but they should not appear as IA, E2, or E1.
Here we have a general requirement, but it is coupled with a restriction. With a solution in place, this should be easy to verify.
Knowledge questions:

What are the different types of OSPF routes that you might see in the routing table?
Of the various OSPF route types, are there any that are NOT possible, given the information in the section?
If there are route types that are NOT possible, why are they not possible?
If the section was worded differently, and for example said they SHOULD appear as a certain type, do you know how you would configure that?

Self assessment: Will your proposed solution meet the requirements of this bullet point?
2. The output of “show ip ospf neighbor” on R2 should show 11.11.11.11 as the Neighbor ID for the adjacency to R1, even if R1 is reloaded. No other Neighbor IDs should show up on R2.
More requirements and restrictions, but still very straightforward regarding how to verify that a solution meets the requirements of this bullet point.
Knowledge questions:

What is the significance of R2 showing 11.11.11.11 as the Neighbor ID for the adjacency?
What types of situations would cause a reload to have an effect on the Neighbor ID?
What would cause R2 to see other Neighbor IDs?

Self assessment: Will your proposed solution meet these requirements?
3. You are not allowed to use the “router-id” command on R1.
This bullet point is an explicit restriction.
Knowledge questions:

What does the “router-id” command do?
If this restriction was not here, would your solution be different?
If the section was worded differently, and you were REQUIRED to use this command, do you know how to use it?

Self assessment: Were you careful to make sure your proposed solution was not using this command?
4. You are not permitted to shut down interfaces on R1, or remove any of the existing configuration on R1.
Knowledge questions:

How could shutting down an interface affect this scenario?
How could removing configuration affect this scenario?

5. No additional configuration may be added to R2, all configuration for this challenge is done on R1.
Mostly just excess clarification here, to point out that only R1 needs to be configured.
Knowledge question: Would being able to make configuration changes on R2 affect anything in this scenario?
Note: The questions listed here are just some samples of the types of things that you might be thinking or asking yourself when practicing a technology, or working through a lab scenario.

By Marvin Greenlee, CCIE #12237

The Top Ten Qualities for a Successful Lab Attempt

No jokes here folks – just the Top Ten Qualities for a Successful Lab Attempt! Did I miss any? Let me know in the Comments below! I know many of you will take care of the jokes for me.

10. Effective use of the proctors – for more information, see Tips for Working with the Proctors.
9. Proper diet – be sure to bring your own lunch and snacks.
8. Attention to the Core Knowledge Section – do not rush this section, and once complete, do not think about it again.
7. Use of the DOC-CD – knowing when to use it and how is critical.
6. Effective diagramming techniques – for more information, see May I Have a Diagram with that Please.
5. Positive mindset – no thoughts of failure, only thoughts of success.
4. Effective disaster management techniques – how quickly and effectively you react to a major issues is critical.
3. Precise and accurate verifications.
2. Precise and accurate troubleshooting.
And the Number 1 Quality for a Successful Lab Attempt:
1. Time management and overall lab strategy.

By Anthony Sequeira, #15626

“Broken MPLS? Troubleshoot it we should, mmmmm.” … yoda

Cheers from London! I learned this week that a “Christmas Cracker” is not a food item, OR a person.

There is so much to know. I am grateful for students willing to show me the ropes here in the UK. Thank you all. Now on to the topic at hand.
MPLS is an important part of the RS Bootcamp, including troubleshooting MPLS.
Here is an MPLS troubleshooting scenario, that has 1 (one,одну,un,uno) configuration issue. Can you spot it? Lets get to it! Here is the diagram.
mpls-ine-blog

Problem: Clients on the 5.5.5.0 network are not able to ping the server, or any other devices, on the 1.1.1.0 network. Your challenge, based on the provided IOS show commands only, is to identify the 1 configuration problem that is causing the network failure.
For this scenario, the PC and Server configurations are correct, as well as all the layer 2 switching infrastructure on the Catalyst switches. R1 and R5 are CE routers, R2 and R4 are PE routers, and R3 is a P router.
We will work from the diagram, using the show commands from right to left, starting with R5. (I have grouped the show commands together, then the individual commands and their output. This way, the post may be used as a study/reference tool.)
R5
show ip int brief | ex una
show ip route
show ip protocols
ping 136.1.45.255

R5#show ip int brief | ex una
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            5.5.5.5         YES manual up                    up
FastEthernet0/1            136.1.45.5      YES NVRAM  up                    up
Loopback0                  150.1.5.5       YES NVRAM  up                    up
R5#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

     136.1.0.0/24 is subnetted, 2 subnets
R       136.1.12.0 [120/1] via 136.1.45.4, 00:00:08, FastEthernet0/1
C       136.1.45.0 is directly connected, FastEthernet0/1
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/1] via 136.1.45.4, 00:00:08, FastEthernet0/1
     5.0.0.0/24 is subnetted, 1 subnets
C       5.5.5.0 is directly connected, FastEthernet0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.5.0 is directly connected, Loopback0
R5#show ip protocols
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 11 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    5.0.0.0
    136.1.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    136.1.45.4           120      00:00:08
  Distance: (default is 120)

R5#ping 136.1.45.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.45.255, timeout is 2 seconds:

Reply to request 0 from 136.1.45.4, 8 ms
Reply to request 1 from 136.1.45.4, 32 ms
Reply to request 2 from 136.1.45.4, 16 ms
Reply to request 3 from 136.1.45.4, 4 ms
Reply to request 4 from 136.1.45.4, 24 ms
R5#

R4
show ip route
show ip route vrf Vrf1
show ip protocols
show mpls interface
show mpls ldp neighbor
show mpls forwarding-table
show ip bgp summary
show ip bgp vpnv4 all
ping vrf Vrf1 136.1.45.255
ping 136.1.34.255

R4#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

     136.1.0.0/24 is subnetted, 2 subnets
O       136.1.23.0 [110/65] via 136.1.34.3, 00:04:28, FastEthernet0/0
C       136.1.34.0 is directly connected, FastEthernet0/0
     150.1.0.0/32 is subnetted, 2 subnets
C       150.1.4.4 is directly connected, Loopback0
O       150.1.2.2 [110/66] via 136.1.34.3, 00:04:28, FastEthernet0/0
R4#show ip route vrf Vrf1

Routing Table: Vrf1
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

     136.1.0.0/24 is subnetted, 2 subnets
B       136.1.12.0 [200/0] via 150.1.2.2, 00:04:23
C       136.1.45.0 is directly connected, FastEthernet0/1
     1.0.0.0/24 is subnetted, 1 subnets
B       1.1.1.0 [200/2] via 150.1.2.2, 00:04:23
     5.0.0.0/24 is subnetted, 1 subnets
R       5.5.5.0 [120/1] via 136.1.45.5, 00:00:01, FastEthernet0/1
R4#show ip protocols
Routing Protocol is "ospf 234"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 150.1.4.4
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
  Routing on Interfaces Configured Explicitly (Area 0):
    FastEthernet0/0
    Loopback0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    150.1.2.2            110      00:04:28
    150.1.3.3            110      00:04:28
  Distance: (default is 110)

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 0 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 1, receive any version
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 120)

Routing Protocol is "bgp 24"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    150.1.2.2
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: external 20 internal 200 local 200

R4#show mpls interface
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (ldp)     No       Yes
R4#show mpls ldp neighbor

R4#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
17     Untagged    150.1.2.2/32      0          Fa0/0      136.1.34.3
18     Untagged    136.1.23.0/24     0          Fa0/0      136.1.34.3
19     Untagged    5.5.5.0/24[V]     19950      Fa0/1      136.1.45.5
20     Aggregate   136.1.45.0/24[V]  1684
R4#show ip bgp summary
BGP router identifier 150.1.4.4, local AS number 24
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
150.1.2.2       4    24     148     149        1    0    0 02:08:57        0
R4#show ip bgp vpnv4 all
BGP table version is 22, local router ID is 150.1.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf Vrf1)
*>i1.1.1.0/24       150.1.2.2                2    100      0 ?
*> 5.5.5.0/24       136.1.45.5               1         32768 ?
*>i136.1.12.0/24    150.1.2.2                0    100      0 ?
*> 136.1.45.0/24    0.0.0.0                  0         32768 ?
R4#ping vrf Vrf1 136.1.45.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.45.255, timeout is 2 seconds:

Reply to request 0 from 136.1.45.5, 4 ms
Reply to request 1 from 136.1.45.5, 28 ms
Reply to request 2 from 136.1.45.5, 16 ms
Reply to request 3 from 136.1.45.5, 32 ms
Reply to request 4 from 136.1.45.5, 8 ms
R4#ping 136.1.34.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.34.255, timeout is 2 seconds:

Reply to request 0 from 136.1.34.3, 8 ms
Reply to request 1 from 136.1.34.3, 4 ms
Reply to request 2 from 136.1.34.3, 16 ms
Reply to request 3 from 136.1.34.3, 8 ms
Reply to request 4 from 136.1.34.3, 4 ms
R4#

R3
show ip route
show ip protocols
show mpls interface
show mpls ldp neighbor
show mpls forwarding-table

R3#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

     136.1.0.0/24 is subnetted, 2 subnets
C       136.1.23.0 is directly connected, Serial0/0.23
C       136.1.34.0 is directly connected, FastEthernet0/0
     150.1.0.0/32 is subnetted, 3 subnets
O       150.1.4.4 [110/2] via 136.1.34.4, 00:05:16, FastEthernet0/0
C       150.1.3.3 is directly connected, Loopback0
O       150.1.2.2 [110/65] via 136.1.23.2, 00:05:26, Serial0/0.23
R3#show ip protocols
Routing Protocol is "ospf 234"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 150.1.3.3
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
  Routing on Interfaces Configured Explicitly (Area 0):
    FastEthernet0/0
    Serial0/0.23
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    150.1.4.4            110      00:05:16
    150.1.2.2            110      00:05:26
  Distance: (default is 110)

R3#show mpls interface
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (ldp)     No       Yes
Serial0/0.23           Yes (ldp)     No       Yes
R3#show mpls ldp neighbor

R3#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Untagged    150.1.2.2/32      0          Se0/0.23   point2point
17     Untagged    150.1.4.4/32      0          Fa0/0      136.1.34.4

R2
show ip route
show ip route vrf Vrf1
show ip protocols
show mpls interface
show mpls ldp neighbor
show mpls forwarding-table
show ip bgp summary
show ip bgp vpnv4 all
ping 136.1.23.255
ping vrf Vrf1 136.1.12.255

R2#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

     136.1.0.0/24 is subnetted, 2 subnets
C       136.1.23.0 is directly connected, Serial0/0.23
O       136.1.34.0 [110/65] via 136.1.23.3, 00:05:41, Serial0/0.23
     150.1.0.0/32 is subnetted, 2 subnets
O       150.1.4.4 [110/66] via 136.1.23.3, 00:05:41, Serial0/0.23
C       150.1.2.2 is directly connected, Loopback0
R2#show ip route vrf Vrf1

Routing Table: Vrf1
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

     136.1.0.0/24 is subnetted, 2 subnets
C       136.1.12.0 is directly connected, FastEthernet0/0
B       136.1.45.0 [200/0] via 150.1.4.4, 00:05:18
     1.0.0.0/24 is subnetted, 1 subnets
O       1.1.1.0 [110/2] via 136.1.12.1, 02:18:47, FastEthernet0/0
     5.0.0.0/24 is subnetted, 1 subnets
B       5.5.5.0 [200/1] via 150.1.4.4, 00:05:18
R2#show ip protocols
Routing Protocol is "ospf 234"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 150.1.2.2
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
  Routing on Interfaces Configured Explicitly (Area 0):
    Serial0/0.23
    Loopback0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    150.1.4.4            110      00:05:41
    150.1.3.3            110      00:05:51
  Distance: (default is 110)

Routing Protocol is "bgp 24"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    150.1.4.4
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: external 20 internal 200 local 200

R2#show mpls interface
Interface              IP            Tunnel   Operational
Serial0/0.23           Yes (ldp)     No       Yes
R2#show mpls ldp neighbor

R2#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
17     Untagged    136.1.34.0/24     0          Se0/0.23   point2point
18     Untagged    150.1.4.4/32      0          Se0/0.23   point2point
21     Aggregate   136.1.12.0/24[V]  1040
22     Untagged    1.1.1.0/24[V]     18240      Fa0/0      136.1.12.1
R2#show ip bgp summary
BGP router identifier 150.1.2.2, local AS number 24
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
150.1.4.4       4    24     151     150        1    0    0 02:10:15        0
R2#show ip bgp vpnv4 all
BGP table version is 13, local router ID is 150.1.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf Vrf1)
*> 1.1.1.0/24       136.1.12.1               2         32768 ?
*>i5.5.5.0/24       150.1.4.4                1    100      0 ?
*> 136.1.12.0/24    0.0.0.0                  0         32768 ?
*>i136.1.45.0/24    150.1.4.4                0    100      0 ?
R2#ping 136.1.23.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.23.255, timeout is 2 seconds:

Reply to request 0 from 136.1.23.3, 12 ms
Reply to request 1 from 136.1.23.3, 16 ms
Reply to request 2 from 136.1.23.3, 32 ms
Reply to request 3 from 136.1.23.3, 28 ms
Reply to request 4 from 136.1.23.3, 28 ms
R2#ping vrf Vrf1 136.1.12.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.12.255, timeout is 2 seconds:

Reply to request 0 from 136.1.12.1, 4 ms
Reply to request 1 from 136.1.12.1, 28 ms
Reply to request 2 from 136.1.12.1, 16 ms
Reply to request 3 from 136.1.12.1, 28 ms
Reply to request 4 from 136.1.12.1, 12 ms
R2#

R1
show ip int brief | ex una
show ip route
show ip protocols
ping 136.1.12.255

R1#show ip int brief | ex una
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            136.1.12.1      YES NVRAM  up                    up
FastEthernet0/1            1.1.1.1         YES manual up                    up
Loopback0                  150.1.1.1       YES NVRAM  up                    up
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

     136.1.0.0/24 is subnetted, 2 subnets
C       136.1.12.0 is directly connected, FastEthernet0/0
O E2    136.1.45.0 [110/1] via 136.1.12.2, 00:06:20, FastEthernet0/0
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/1
     5.0.0.0/24 is subnetted, 1 subnets
O E2    5.5.5.0 [110/1] via 136.1.12.2, 00:06:20, FastEthernet0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Loopback0
R1#show ip protocols
Routing Protocol is "ospf 12"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 150.1.1.1
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    1.1.1.0 0.0.0.255 area 0
    136.1.12.1 0.0.0.0 area 0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    136.1.12.2           110      00:06:20
  Distance: (default is 110)

R1#ping 136.1.12.255 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.12.255, timeout is 2 seconds:

Reply to request 0 from 136.1.12.2, 8 ms
Reply to request 1 from 136.1.12.2, 20 ms
Reply to request 2 from 136.1.12.2, 12 ms
Reply to request 3 from 136.1.12.2, 24 ms
Reply to request 4 from 136.1.12.2, 8 ms
R1#

What do you see as the problem, and what may be done to correct it?
Good luck!

By Keith Barker, CCIE #6783

Using Extended ACLs for BGP Filtering

Prior to the support of prefix-lists in the IOS advanced filtering for BGP needed to be done using extended ACLs. The syntax for using extended ACLs is shown below:
access-list permit ip
The source portion of the extended ACL is used to match the network portion of the BGP route and the destination portion of the ACL is used to match the subnet mask of the BGP route. Here are some examples:
access-list 100 permit ip 10.0.0.0 0.0.0.0 255.255.0.0 0.0.0.0
Matches 10.0.0.0/16 – Only
access-list 100 permit ip 10.0.0.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.0.0.0/24 – Only
access-list 100 permit ip 10.1.1.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.1.1.0/24 – Only
access-list 100 permit ip 10.0.0.0 0.0.255.0 255.255.255.0 0.0.0.0
Matches 10.0.X.0/24 – Any number in the 3rd octet of the network with a /24 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.0 255.255.255.0 0.0.0.0
Matches 10.X.X.0/24 – Any number in the 2nd & 3rd octet of the network with a /24 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.240 0.0.0.0
Matches 10.X.X.X/28 – Any number in the 2nd, 3rd & 4th octet of the network with a /28 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.0 0.0.0.255
Matches 10.X.X.X/24 to 10.X.X.X/32 – Any number in the 2nd, 3rd & 4th octet of the network with a /24 to /32 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.128 0.0.0.127
Matches 10.X.X.X/25 to 10.X.X.X/32 – Any number in the 2nd, 3rd & 4th octet of the network with a /25 to /32 subnet mask

By Brian Dennis, CCIE #2210

BGP Order of Preference

For inbound updates the order of preference is:
1. route-map
2. filter-list
3. prefix-list, distribute-list

For outbound updates the order of preference is:
1. prefix-list, distribute-list
2. filter-list
3. route-map