Category: CCIE

BGP Path Attributes

~ Mar Apuhin ~ Leave a comment

Path Attributes as the name suggests are the characteristics of an advertised BGP Route. BGP routing policy is set and communicated using the path attributes.

Path Attributes fall into one of the two categories
1. Well-known Path Attributes
2. Optional Path Attributes

Well-known: Meaning these attributes must be recognized by all the BGP implementations.

Well- Known BGP Path Attributes fall into two sub-categories known as
1. Mandatory (Called as Well-known Mandatory)
2. Discretionary (Called as Well-Known Discretionary)

Mandatory: This means the attribute must be always included and carried in all BGP update messages to peers. The BGP implementation has to recognize the attribute, accept it and also advertise it to its peers.

Discretionary: Meaning these are recognized by the BGP implementation but may or may not be sent in a specific Update message. Its up to the discretion of BGP Implementation to send or not to send these attributes in the update messages to the peers.

Optional: Meaning these attributes may or may not be supported by the BGP implementations.

Optional BGP Path attributes also fall into two sub-categories
1. Transitive (Called as Optional Transitive)
2. Non-transitive (Called as Optional Non-transitive)

Transitive: BGP process has to accept the path in which it is included and should pass it on to other peers even if these attributes are not supported. Meaning if any optional attribute is not recognized by a BGP implementation, then BGP looks to check if the transitive flag is set. If the transitive flag is set then BGP implementation should accept the attribute and advertise it to its other BGP Peers.

Non-transitive: If the BGP process does not recognize the attribute then it can ignore the update and not advertise the path to its peers. If the transitive  flag is not set then BGP implementation can quietly ignore the attribute, it does not have to accept and advertise this attribute to its other peers.

To Summarize the BGP Path Attribute Categories

  1. Well-known Mandatory: Recognized and Included in all BGP Update messages.
    2. Well-known Discretionary: Recognized and May or May not include in BGP Update messages
    3. Optional Transitive: Even if Not Supported it Still need to accept and Send in Update Message.
    4. Optional Non-transitive: Can be ignored and not advertise to peers.
LIST OF BGP PATH ATTRIBUTES
Attribute Name Category / Class
ORIGIN Well-Known Mandatory
AS_PATH Well-Known Mandatory
NEXT_HOP Well-Known Mandatory
LOCAL_PREF Well-Known Discretionary
ATOMIC_AGGREGATE Well-Known Discretionary
AGGREGATOR Optional Transitive
COMMUNITY Optional Transitive
MULTI_EXIT_DISC (MED) Optional Non-Transitive
ORIGINATOR_ID Optional Non-Transitive
CLUSTER LIST Optional Non-Transitive
MULTIPROTOCOL Reachable NLRI Optional Non-Transitive
MULTIPROTOCOL Unreachable NLRI Optional Non-Transitive

 

Python Tutorial: Python Network Programming – Build 7 Apps

ORIGIN ATTRIBUTE:
As the name suggests the ORIGIN attribute specifies the origin of the routing update. This is a Well-known Mandatory BGP Attribute and hence has to be recognized and sent to peers by all BGP implementations. The Origin attribute can contain one of these three values
1. IGP
2. EGP
3. Incomplete

If BGP has multiple routes then ORIGIN is one of the factor in determining the preferred route. IGP is the highest preferred ORIGIN value followed by EGP and Incomplete ORIGIN Attribute is the lowest preferred ORIGIN value of the three.

IGP: It means that the NLRI was learnt from an internal routing protocol of the originating AS.
EGP: This ORIGIN code specifies that the NLRI was learnt from EGP.
Incomplete: Usually misunderstood, this value means that the NLRI was learnt from some other means, it does not mean that the route is faulty, it only specifies that the information to determine the ORIGIN is not complete. All redistributed routes into BGP have an Incomplete ORIGIN attribute, since the origin of these routes cannot be determined.

AS_PATH ATTRIBUTE:

AS_Path describes the inter-AS path taken to reach a destination. It gives a list of AS Numbers traversed when reaching to a destination. Every BGP speaker when advertising a route to a peer will include its own AS number in the NLRI. The subsequent BGP speakers who advertise this route will add their own AS number to the AS_Path, the subsequent AS numbers get prepended to the list. The end result is the AS_Path attribute is able to describe all the autonomous systems it has traversed, beginning with the most recent AS and ending with the originating AS.

AS_Path is a well-known attribute, so if a BGP speaker advertises the route to a destination then it has to include its AS number in the advertisement if its originating the NLRI or if its advertising a received NLRI to other peers then it has to prepend its AS number to the existing list of autonomous systems in the AS_path attribute.

For an example below:

Lets assume AS-100 is advertising 1.1.1.0/22 to AS-200 Since AS-100 is originating the NLRI the advertisement will be [ 1.1.1.0/22 100]
AS-200 will receive this NLRI and advertise it to its peers AS-300 and AS-400, the NLRI  advertisement will look like  [ 1.1.1.0/22 200,100] – specifying that to reach the network 1.1.1.0/22 you have a path where you can to traverse AS-200 then AS-100.

The subsequent autonomous systems AS-300, AS-400 and others do the same. In the end AS-600 receives two routes to reach the network 1.1.1.0/22. To reach any host in network 1.1.1.0/22 it can either reach through AS-500 or from AS-400, since BGP is a path vector protocol by default AS-600 will choose the path from AS-400 since its shorter (less number of Autonomous Systems to traverse). Also note by default EBGP will not load balance across the two paths and will select only one best path, but it can be configured to load balance.

Also, BGP Speaker will add its AS number to the AS_Path only when an Update message is being sent to the neighbor which means only when BGP is advertising the route to the peer it will prepend its AS number to the AS_Path attribute.

AS_Path Prepend to Prefer one route over another:

In BGP the outgoing route advertisements directly influence the incoming traffic. In the example lets assume the link between AS-200 and AS-400 is a T1 and AS-200 does not want to prefer this route. Since the outgoing advertisements directly influence the incoming traffic in BGP, and AS-200 wants to prefer AS-300 assuming this is a high speed Gig link, AS-200 will prepend its AS number is the advertisements to AS-400 so that it makes it less preferable, the new BGP path ratio is reflected in the example diagram . AS-600 will now prefer the path from AS-500 and will follow the path 500-300-200-100 to reach 1.1.1.0/22 since this one becomes the shorter path.

AS_Path prepending is one of the way to influence how the BGP advertisements and the incoming traffic is handled.

AS_Path Attribute also makes sure that there is no routing loop, if an NLRI advertisement is received from a BGP peer and the receiving AS sees its own AS number in the AS_Path list of the destination route which is received, then the receiving BGP speaker knows that there is a loop and will not accept the advertisement.

AS_Path can be shown by issuing the command “sh ip bgp” on a cisco router.

NEXT_HOP ATTRIBUTE:

NEXT_HOP Attribute specifies the next hop IP address to reach the destination advertised in the NLRI.  NEXT_HOP is a well-known mandatory attribute and it has some set of rules to be followed for different BGP scenarios.

  1. If the BGP Peers are in different Autonomous Systems then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the advertising router.
  2. If the BGP peers are in the same AS (IBGP Peers), and the destination network being advertised in the update message is also in the same AS, then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the advertising router.
  3. If the BGP peers are in the same AS (IBGP Peers), and the destination network being advertised in the update message is in an external AS, then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the external peer router which sent the advertisement to this AS.

Below are some examples for each of these scenarios.

NEXT_HOP BGP UPDATE Between Different Autonomous Systems:

In this example, the EBGP update is pretty straight forward. As the rule states If the BGP Peers are in different Autonomous Systems then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the advertising router.

NEXT_HOP will always be advertised by the router which is sending an update to the BGP peer on how to reach a particular network.

The router in AS-200 sends in its update that network 2.2.2.0/24 is reachable via its IP address of 192.168.100.2

The router in AS-100 when needs to reach the network 2.2.2.0/24, it will always use the next hop ip address of 192.168.100.2 which is advertised by the router in AS-100 as a NEXT_HOP Attribute to reach this network.

Since NEXT_HOP is a well-known Mandatory Attribute, the router in AS-100 will have to accept and honor this value.

In this scenario where there are two routers in different AS and have formed the EBGP relationship, the NEXT_HOP attribute is pretty simple and straight forward.

The command “show ip bgp neighbor 192.168.100.1 advertised-routes” when executed on the router in AS-200 will show the network prefix it is advertising and the NEXT_HOP it is advertising. Both these values will be network: 2.2.2.0/24 and the NEXT_HOP as 192.168.100.2

NEXT_HOP BGP UPDATE Within Peers in Same Autonomous System:

NEXT_HOP address for the BGP peers in the same Autonomous Systems  is the address of the advertising router which in this case is RTR-A. Both RTR-A and RTR-C are IBGP Peers, When RTR-A sends an update message indicating the reachabilty information for network 10.10.10.0/24, it puts its own IP address in the NEXT_HOP. For RTR-C to reach the network 10.10.10.0/24, it will have the NEXT_HOP IP address of RTR-A and not RTR-B to which it is directly connected.

Also, this applies to the routers on the same shared IP segment, the NEXT_HOP will always be the IP address of the advertising router.

NEXT_HOP BGP UPDATE For Different AS:

In this scenario, the router is AS-100 is advertising the network 172.16.30.0/24 and specifies the next hop ip address of its own as 172.16.10.1, the router in AS-200 receives this update and has the next hop to reach this network as the IP address of the router which advertised the network which is the router in AS-100.

Within AS-200 now RTR-A advertises this network to its IBGP peers and advertises the NEXT_HOP as the IP address of the router in AS-100.

RTR-C which is the IBGP peer of RTR-A, now knows to reach the network 172.16.30.0/24 it has to use the next hop ip address of 172.16.10.1 (which is the ip address on router in AS-100).

This could cause an issue because RTR-C does not know how to reach the address 172.16.10.1 and the packets for the destination in 172.16.20.0/24 are dropped.  The route 172.16.30.0/24 is installed in BGP table but it is not installed in the IGP as the next hop IP address specified is not reachable and is considered as an invalid address. This issue can be resolved in one of the three ways.
1. Use static routes to link external addresses to internal routers, not a very feasible solution to use.
2. Run IGP is passive mode on the external interfaces.
3. BGP implementation gives a more practical solution called as “Next_Hop_Self” this when configured on the local RTR-A it will cause RTR-A to set its own IP address in the NEXT_HOP attribute.  The internal peers RTR-B and RTR-C will now have a NEXT_HOP IP address of 192.168.10.1 to reach the network 172.16.30.0/24 in AS-100. Since the internal routers already have the RTR-A’s address in IGP they know how to reach the external network through RTR-A.

 

Local Preference (LOCAL_PREF):

LOCAL_PREF is only used in updates sent to the IBGP Peers. This is a well-known discretionary attribute and as the name suggests it is used locally within an AS to update the internal BGP peers. It is not passed on to the BGP peers in other autonomous systems.

LOCAL_PREF specifies the BGP Speaker’s degree of preference for an advertised route.
The higher the value of Local Preference attribute the more preferred the route is.
Remember: For Local Preference : Higher Value = More Preference

Note that the Local Preference will only affect the traffic leaving the AS.

For an example on how LOCAL_PREF influences BGP routing, take a look at the diagram below.

In this example, the customer is peering with two ISPs to get the internet routing table, assuming that the connection to ISP-1 is a Gig connection and the connection to ISP-2 is only a T1, the customer wants to use ISP-1 and keep ISP-2 as a backup in case the link to ISP-1 fails.

From the diagram, RTR-A is connected to ISP-1 and it advertises the routes received from ISP-1 with a local preference of 200 to other internal BGP peers.

RTR-B is connected to ISP-2 and is advertising the routes received from ISP-2 with a local preference value of 100 (which is the default value of LOCAL_PREF).

Assuming that both the ISPs are advertising the same destination routes then RTR-C, the internal BGP Peer receives the routes from both RTR-A and RTR-B and will select RTR-A because the LOCAL_PREF value is higher on the routes advertised by RTR-A.

Also note that RTR-B will also prefer the routes advertised by ISP-1 connected to RTR-A. that is all internal routers within the customer AS in the diagram will now prefer Routes received from ISP-1.

LOCAL_PREF affects the traffic leaving the AS, the traffic leaving the Customer-AS in this example will prefer the routes from ISP1 to reach the destination networks. If there are any destination routes that ISP2 is advertising which are not being advertised on ISP1 for some reason, then traffic destined for those routes which are missing in ISP1’s advertisements will leave from RTR-B to ISP2 in order to reach those destinations network prefixes.

ATOMIC_AGGREGATE and AGGREGATOR:

ATOMIC_AGGREGATOR path attribute does  route aggregation on the routes that are non identical but point to the same destination. In effect if summarizes the routes when advertising them to the BGP peer.

When a router receives routes for the same destination, it makes the best path decision by selecting the more specific path. When aggregation is performed the BGP Speaker starts advertising the less specific routes to its peers but the path detail information is lost in this process. Anytime a BGP speaker does this aggregation by summarizing more specific routes into a less specific route it has to inform its down stream BGP peers that aggregation has been done, this is done by attaching the ATOMIC_AGGREGATE attribute to the update message.

When the downstream BGP speakers receive the route with ATOMIC_AGGREGATE attribute set, then they cannot advertise the more specific routes for this aggregated route, and they will have to keep the ATOMIC_AGGREGATE attribute attached when advertising this route to their BGP peers.

In some instances not all routes in a  network can be aggregated, and in others  all of them can be aggregated but still there might be an need to advertise both aggregate-address and the more-specific routes. In both the cases the router can advertise both the more specific routes as well as the aggregate address. Aggregation is done by the command “aggregate-address <network-prefix> <mask> and individual network statements” if the same command is used with the keyword “summary-only” then only the aggregate address is advertised and not the more-specific prefixes.

ATOMIC_AGGREGATE is a well-known discretionary attribute and informs its down stream routers that a loss of path information has occurred.

AGGREGATOR:

when the ATOMIC_AGGREGATE attribute is set, the BGP speaker has an option of attaching the AGGREGATOR attribute. AGGREGATOR i optional transitive attribute and gives information on where the aggregation was performed by including the AS number and the IP address of the router that originated the aggregate route. Cisco uses the Router ID as the the address of AGGREGATOR.

AS_SET:

When aggregation is done on the BGP route, the AS_Path information is lost. One of the purposes why AS_Path is used is to avoid any loops, and if the BGP speaker does not see its own AS number in the AS_Path, it will accept the route and can create a potential loop in the routing.

AS_SET is used to avoid this, AS_SET gives an unordered list of AS numbers when aggregation is done.

When a BGP speaker does aggregation for an NLRI leant from other autonomous systems, it can include all the AS numbers in the AS_Path as AS_SET,  including AS_SET will still give a list of AS numbers, though unordered it will still let the BGP speaker know if its own AS number was there somewhere in the path and it can reject the NLRI if its own AS number was seen for this NLRI advertisement.

MULTI_EXIT_DISC ATTRIBUTE: (MED)

MED is an optional non-transitive attribute and it is used to influence how the incoming traffic comes into an AS.

MED allows the AS  to inform its immediate neighbor AS of its preferred entry points. MED is also called as metric and the lowest value of MED is the most preferred one.
Note that MED Is not passed beyond the receiving AS. It is only used to influence traffic between two directly connected autonomous systems. Also MEDS are never compared when the routes to the same destination are received from two or more different AS. MED only applies to the routes advertised by a single AS.

In this example, AS-100 advertises the route from two different entry points with the MED value of 50 0n one router and a value of 100 on another. The Preferred entry point will be the router which is advertising the routes with the MED value of 50, since this is the lower value. Also notice that AS-200 will not advertise the AS-100 MED values to AS-300 in its outgoing route advertisements, since MED is an optional non-transitive attribute.

Also in this example the MED attribute will only take affect if AS-200’s BGP implementation recognizes the MED attribute, or else setting these MED attribute values on the routes for a preferred entry point into AS will not have any affect.

Note: By default MED values are not compared for routes to the same destination received from tw0 or more different autonomous systems. There is however a way for enabling this by using the command “bgp-always-comapre-med”. when this command is used, MED values on the received routes for same destination from different autonomous systems are compared. If this command is configured then it needs to be configured on every BGP router in the AS.

COMMUNITY ATTRIBUTE:

COMMUNITY attribute allows to share a common policy across multiple BGP peers who can be identified to be in a same group.

This is an optional transitive attribute so it needs to be passed on to other BGP peers. This attribute simplifies the policy enforcement by grouping a set of BGP peers with common properties to share a common set of policy.

An AS can set a COMMUNITY attribute for some of its BGP peer routes, and set the LOCAL_PREF and MED attributes based on the COMMUNITY rather than setting these values individually for each of these Peers. This helps in simplifying the process of policy enforcement.

Community attribute is always represented in Hex Format and is a set of 4 Octets.
As per RFC 1997 the first 2 octets are AS-number and the last two octets are an administratively defined identifier , resulting in the format of  AA:NN
The default Cisco format is the reverse of this as NN:AA, but this can be changed by the command “ip bgp-community new-format”

Community values in these ranges are reserved
0 – 65535 [Hex: 0x00000000-0x0000FFFF] and
4294901760 – 4294967295 [Hex: 0xFFFF0000-0xFFFFFFFF]
some of the well-known communities fall into these reserved ranges, as below.

  1. INTERNET:The internet community is the default community, it has no value. All routes by default to belong to this community and all of the routes in this category are advertised freely.
  2. NO_EXPORT:Routes received carrying this value cannot be advertised to EBGP Peers.  That is these routes must not be advertised outside the AS. The value is  0xFFFFFF01. If there is a confederation defined and this value is received then the routes cannot be advertised outside the confederation.
  3. NO_ADVERTISE:Routes received carrying this value cannot be advertised at all, that is they cannot be advertised to IBGP or EBGP peers. The value is 0xFFFFFF02.
  4. LOCAL_AS:Routes received carrying this value cannot be advertised to EBGP peers and peers in other AS within a confederation. The value is 0xFFFFFF03. As per RFC 1997 this attribute is called as NO_EXPORT_SUBCONFD.

Apart from these well-known community attributes, private community attributes can also be defined for certain uses, but these private community attributes will only be significant to the AS that has defined it in context to its BGP peers.

A route can carry more than one community attribute, and the BGP peer that receives such a route with multiple community attributes  can act based on one, some or all of the community attributes. A router can also add or modify the community attributes before passing them to other BGP peers.

Administrative Weight: (Cisco Only Parameter)

This is a Cisco Specific attribute that is applied to a route within a router. it is not communicated to other routers. The value of admin weight ranges between 0 to 65.535 and the route with higher value is more preferred.
By default all routes leant from a BGP peer have a value of 0 and all routes generated by the local router have a value of 32,768.

In this example, the router RTR-C prefers route  1.1.1.0/24  from RTR-B in AS-200, because the admin weight assigned is higher on the route received from RTR-B. Administrative weight is the first parameter which Cisco routers use for deciding the best BGP route when multiple routes to the same destination are available.

Source: http://netcerts.net/bgp-path-attributes-and-the-decision-process/

dB vs. dBm

~ Mar Apuhin ~ Leave a comment

Decibel (dB) and dB relative to a milliwatt (dBm) represent two different but related concepts.

A dB is a shorthand way to express the ratio of two values. As a unit for the strength of a signal, dB expresses the ratio between two power levels. To be exact, dB = log (P1/P2).

Using the decibel allows us to contrast greatly differing power levels (a common predicament in radio link design) with a simple two- or three-digit number instead of a more burdensome nine- or 10-digit one.

For instance, instead of characterizing the difference in two power levels as 1,000,000,000 to 1, it’s much simpler to use the decibel representation as 10*log (1,000,000,000/1), or 90 dB. The same goes for very small numbers: The ratio of 0.000000001 to 1 can be characterized as -90 dB. This makes keeping track of signal levels much simpler.

The unit dBm denotes an absolute power level measured in decibels and referenced to 1 milliwatt (mW). To convert from absolute power “P” (in watts) to dBm, use the formula dBm = 10*log (P/1 mW). This equation looks almost the same as that for the dB. However, now the power level “P” has been referenced to 1 mW. It turns out that in the practical radio world, 1 mW is a convenient reference point from which to measure power.

Use dB when expressing the ratio between two power values. Use dBm when expressing an absolute value of power.

– See more at: https://www.isa.org/standards-publications/isa-publications/intech-magazine/2002/november/db-vs-dbm/#sthash.U0xobENS.dpuf

Source: https://www.isa.org/standards-publications/isa-publications/intech-magazine/2002/november/db-vs-dbm/

Free CCIE Voice Lectures from INE.COM

~ Mar Apuhin ~ 1 Comment

CCIE Voice – Deep Dive Module 1 ($99 Value)

1.0 – Introduction and Basic Theory

http://ieclass.internetworkexpert.com/p49924175/

1.1 – Net Infrastructure Hands-On: VLANs, NTP, DHCP

http://ieclass.internetworkexpert.com/p85573473/

1.2 – Net Infrastructure Hands-On: DHCP, TFTP

http://ieclass.internetworkexpert.com/p41558071/

1.3 – QoS Advanced Theory

http://ieclass.internetworkexpert.com/p44458827/

1.4 – QoS Advanced Theory cont’d

http://ieclass.internetworkexpert.com/p71682550/

1.5 – QoS LAN Hands-On

http://ieclass.internetworkexpert.com/p31037485/

CCIE Voice Specific Q&A Follow-Up Discussion

http://ieclass.internetworkexpert.com/p27856701/

Why you don’t want to lose a CCIE from your staff?

~ Mar Apuhin ~ 3 Comments

According to Cisco these are the answers:

  • The risk to operations is significant with the loss of a qualified IT expert. The remaining staff must compensate to avoid disruptions that impact customer satisfaction, reduce productivity or inflict economic loss.
  • Return on investment in an employee is disrupted with turnover. Employers invest in certified staff through training courses, books and technical materials, practice equipment, time off for study and exams, and the cost of the exam itself.
  • It takes time to achieve certification. The typical CCIE will spend at least 18 months completing the process and take the lab exam more than once before passing.
  • The benefits of Gold or Silver Channel Partner status are only available to companies who maintain the required number of certified staff.

CCIE Employer Information

~ Mar Apuhin ~ 2 Comments

Cisco introduced CCIE in 1993 to help individuals, companies, industries and countries succeed in the networked world, by distinguishing the top echelon of internetworking experts.

Today the CCIE program sets the standard for internetworking expertise and evolves with the industry. The CCIE program is committed to valid, fair and high quality exams.
What CCIE certification stands for:

  • CCIE identifies experts with the skills and experience to handle the most challenging assignments in their field. CCIE exams are constantly updated and revised to evolve with the industry, focusing on current technologies and real-world applications.
  • CCIE is recognized worldwide as the most respected high-level certification in the industry (see Awards & Recognitions). The program continually updates and revises its testing tools and methodologies to ensure unparalleled program quality, relevance and value.
  • CCIE is an objective way to compare individuals, or job candidates, with different experience and backgrounds.
  • Preferred status is given to Cisco partners who employ CCIEs (find out more at Cisco Channel Programs).

Why you should hire a CCIE:

  • Maintenance of your network is fundamental to protect assets and to ensure seamless operations. The environment is growing more complex with operations conducted over VPNs, wireless, remote access and the Internet. You need proven experts to choose, implement and maintain the solutions required.
  • Having certified staff can increase the confidence of your customers, investors and business partners, and thereby boost your organization’s credibility, reputation and value.
  • Certified CCIEs are a highly-select group. Less than 3% of all Cisco certified individuals make it to the CCIE level, a tiny fraction of IT professionals worldwide.
  • Passing the exams is not easy. Earning your CCIE requires passing a lab exam in a time pressured environment. Hands-on experience is the only way to prepare for the lab.
  • CCIEs have invested a lot to expand their knowledge and further their careers. The average candidate spends thousands of their own dollars and at least 18 months pursuing certification. He or she will attempt the lab exam more than once before passing.
  • CCIEs are committed to maintaining their expert skills. Keeping their status active requires passing a recertification exam every two years.

Why you don’t want to lose a CCIE from your staff:

  • The risk to operations is significant with the loss of a qualified IT expert. The remaining staff must compensate to avoid disruptions that impact customer satisfaction, reduce productivity or inflict economic loss.
  • Return on investment in an employee is disrupted with turnover. Employers invest in certified staff through training courses, books and technical materials, practice equipment, time off for study and exams, and the cost of the exam itself.
  • It takes time to achieve certification. The typical CCIE will spend at least 18 months completing the process and take the lab exam more than once before passing.
  • The benefits of Gold or Silver Channel Partner status are only available to companies who maintain the required number of certified staff.

Source:  http://www.cisco.com/web/learning/le3/ccie/employers/index.html

Expansion of Routing and Switching Lab v4.0 Blueprint

~ Mar Apuhin ~ 4 Comments

Detailed Checklist of Topics to Be Covered – Routing and Switching (Expanded by Cisco).

Please be advised that this topic checklist is not an all-inclusive list of Cisco CCIE Routing and Switching lab exam subjects. Instead, Cisco provides this outline as a supplement to the existing lab blueprint to help candidates prepare for their lab exams. Other relevant or related topics may also appear in the actual lab exam.

1.0 Implementing Layer 2 Technologies

Configuring and Troubleshooting Layer 2 Technologies
1.01 Frame Relay
1.01.1 Frame Relay Multipoint Links on a Physical Interface Using Inverse ARP
1.01.2 Frame Relay Multipoint Links on a Physical Interface Without Using Inverse ARP
1.01.3. Frame Relay Multipoint Link on a Subinterface Using Inverse ARP
1.01.4. Frame Relay Multipoint Link on a Subinterface Without Using Inverse ARP
1.01.5. Frame Relay Point-to-Point Subinterfaces
1.01.6. PVC with a Multipoint Interface on One Side and a Subinterface on the Other Side
1.01.7. Authentication on a Frame Relay Link Using PPP
1.2 Catalyst Configuration
1.2.01. Trunks Using an Industry-Standard Encapsulation
1.2.02. Trunks Using a Cisco Proprietary Encapsulation
1.2.03. Creating, Deleting, and Editing VLANs
1.2.04. VTP in Client/Server Mode
1.2.05. VTP in Transparent Mode
1.2.06. VTP Authentication
1.2.07. VTP Pruning
1.2.08. Controlling VLANs That Cross a Trunk
1.2.09. Optimizing STP by STP Timers
1.2.10. PortFast
1.2.11. Loop Guard
1.2.12. BPDU Guard
1.2.13. BPDU Filters
1.2.14. UplinkFast
1.2.15. BackboneFast
1.2.16. MSTP
1.2.17. Selecting the Root Bridge for VLANs in a PVST Environment
1.2.18. Selecting the Root Bridge for an MST Instance in an MST Environment
1.2.19. Setting the Port Priority to Designate the Forwarding Ports
1.2.20. EtherChannel Using an Industry-Standard Protocol
1.2.21. EtherChannel Using a Cisco Proprietary Protocol
1.2.22. Disabling Protocols on the EtherChannel
1.2.23. Load-Balancing Type on the EtherChannel
1.2.24. SNMP Management on the Switch
1.2.25. Telnet and SSH Management on the Switch
1.2.26. Controlling Inbound and Outbound Telnet on the Switch
1.2.27. Regular and Smart Macros
1.2.28. Switch Banners
1.2.29. UDLD
1.2.30. Switch Virtual Interfaces (SVIs) for IP Routing
1.2.31. Router on a Stick
1.2.32. SPAN
1.2.33. RSPAN
1.2.34. IP Routing on the Switch Using RIPv2, EIGRP, OSPF, and BGP
1.2.35. IP Phones to Connect to the Catalyst Switch
1.2.36. Dot1q Tunneling
1.3 Other Layer 2 Technologies
1.3.1. HDLC
1.3.2. PPP
1.3.3. PPP over Ethernet
2.0 Implementing IPv4

Configuring and Troubleshooting IPv4
2.1. IPv4 Addressing
2.1.1. IPv4 Addressing
2.1.2. IPv4 Subnetting
2.1.3. IPv4 VLSM
2.2. OSPFv2
2.2.01. OSPF on a Broadcast Multicast Access Network (Ethernet)
2.2.02. OSPF over a Frame Relay Multipoint Network by Changing Network Types
2.2.03. OSPF over a Frame Relay Multipoint Network by Using the neighbor Command
2.2.04. OSPF over a Frame Relay Point-to-Point Network
2.2.05. Virtual Links
2.2.06. Stub Areas
2.2.07. Totally Stubby Areas
2.2.08. NSSA Areas
2.2.09. NSSA and Stub Areas
2.2.10. NSSA and Totally Stubby Areas
2.3. EIGRP
2.3.1. Basic EIGRP
2.3.2. Passive Interfaces
2.3.3. EIGRP Stub on Routers and Switches
2.3.4. EIGRP Update—Bandwidth Control
2.3.5. Changing the Administrative Distance of EIGRP
2.3.6. Unequal-Cost Load Balancing for EIGRP
2.4. Filtering, Redistribution, and Summarization
2.4.01. Route Filtering for OSPF Within the Area Using a Distribute List with an ACL and Prefix Lists
2.4.02. Route Filtering for OSPF Between Areas
2.4.03. Summarization of OSPF Routes Between Areas
2.4.04. Summarization of External Routers Within OSPF
2.4.05. Filtering with a Distribute List Using an ACL and Prefix Lists
2.4.06. Using Advanced ACLs and a Prefix List for Filtering Routes
2.4.07. Summarizing Routes with EIGRP
2.4.08. Route Summarization for RIP
2.4.09. Redistribution Between OSPF and EIGRP
2.4.10. Redistribution Between RIP and EIGRP
2.4.11. Redistribution of Directly Connected Routes
2.4.12. Redistribution of Static Routes
2.4.13. Redistribution with Filtering Using ACLs and Prefix Lists
2.4.14. Redistribution with Filtering Using Route Tagging
2.5. IBGP
2.5.1. IBGP Peering
2.5.2. Advertising Routes in BGP
2.5.3. Next-Hop Attribute
2.5.4. Route Reflectors
2.5.5. Redundancy by Neighbor Relationships Based on Loopbacks
2.6. EBGP
2.6.1. EBGP Peering
2.6.2. EBGP Peering Based on Loopbacks
2.7. BGP Advanced Features
2.7.01. Filtering Using ACLs
2.7.02. Filtering Using Prefix Lists
2.7.03. Filtering Using AS Path Filters
2.7.04. Redistributing Connected Routes into BGP
2.7.05. Redistributing Dynamic Routing Protocols into BGP
2.7.06. BGP Aggregation
2.7.07. BGP Aggregation with the Summary Only Parameter
2.7.08. BGP Aggregation with Suppress Maps
2.7.09. BGP Aggregation with Unsuppress Maps
2.7.10. BGP Best-Path Selection – Weight
2.7.11. BGP Best-Path Selection – Local Preference
2.7.12. BGP Best-Path Selection – MED
2.7.13. BGP Communities – No-Export
2.7.14. BGP Communities – No-Advertise
2.7.15. BGP Confederation
2.7.16. BGP Local AS
2.7.17. Working with Private AS Numbers
2.7.18. Route Dampening
2.7.19. Conditional Advertising
2.7.20. Peer Groups
3.0 Implementing IPv6

Configuring and Troubleshooting IPv6
3.1. IPv6
3.1.1. IPv6 Addresses
3.1.2. OSPFv3
3.1.3. EIGRPv6
3.1.4. IPv6 Tunneling
3.1.5. IPv6 on a Frame Relay Network – Multipoint
3.1.6. IPv6 on a Frame Relay Network – Point-to-Point
3.1.7. Route Filtering with a Distribute List Using an ACL and Prefix Lists
3.1.8. Route Redistribution Between OSPFv3 and EIGRPv6
4.0 Implementing MPLS

Configuring and Troubleshooting MPLS
4.1. MPLS Unicast Routing
4.1.1. MPLS Unicast Routing Using LDP
4.1.2. Controlling Label Distribution
4.2. MPLS VPN
4.2.1. MPLS VPN Using Static Routing Between PE-CE
4.2.2. MPLS VPN Using EIGRP as the PE-CE Routing Protocol
4.2.3. MPLS VPN Using OSPF as the PE-CE Routing Protocol
4.2.4. MPLS VPN Using EBGP as the PE-CE Routing Protocol
4.2.5. Controlling Route Propagation Using the Route Target with Import and Export Maps
4.3. VRF-Lite
4.3.1. VRFs at the Customer Sites Using VRF-Lite
5.0 Implementing IP Multicast

Configuring and Troubleshooting IP Multicast
5.1. PIM and Bidirectional PIM
5.1.1. PIM Dense Mode
5.1.2. PIM on an NMBA Network
5.1.3. PIM Sparse Mode – Static Rendezvous Point
5.1.4. PIM Sparse Mode – Multiple Static Rendezvous Points
5.1.5. PIM Sparse Mode – Auto Rendezvous Point
5.1.6. PIM Sparse Mode with Multiple Rendezvous Points Using the Auto Rendezvous Point
5.1.7. Bidirectional PIM
5.2. MSDP
5.2.1. MSDP
5.2.2. MSDP to an Anycast Rendezvous Point
5.3. Multicast Tools
5.3.1. Multicast Rate Limiting
5.3.2. IGMP Filtering on the Switch
5.3.3. Use of the Switch to Block Multicast Traffic
5.3.4. Multicasting Through a GRE Tunnel
5.3.5. Multicast Helper Address
5.4. IPv6 Multicast
5.4.1. IPv6 Multicast Routing Using PIM
5.4.2. IPv6 Multicast Listener Discovery (MLD) Protocol
6.0 Implementing Network Security

Configuring and Troubleshooting Network Security
6.1. AAA and Security Server Protocols
6.1.1. Use of a Router to Authenticate Against a AAA Server Using TACACS+
6.1.2. Use of a Router to Authenticate Against a AAA Server Using RADIUS
6.1.3. Local Privilege Authorization
6.1.4. Accounting to a AAA Server Using TACACS+
6.1.5. Accounting to a AAA Server Using RADIUS
6.2. Access Lists
6.2.1. Standard Access Lists
6.2.2. Extended Access Lists
6.2.3. Time-Based Access Lists
6.2.4. Reflexive Access Lists
6.3. Routing Protocol Security
6.3.1. Routing Protocol Authentication for EIGRP
6.3.2. Routing Protocol Authentication for OSPF – Area-Wide
6.3.3. Routing Protocol Authentication for OSPF – Interface-Specific
6.3.4. Routing Protocol Authentication for OSPF Virtual Links
6.3.5. Routing Protocol Authentication for BGP
6.4. Catalyst Security
6.4.1. Storm Control
6.4.2. Switch Port Security
6.4.3. Dot1x Authentication
6.4.4. Dot1x Authentication for VLAN Assignment
6.4.5. VLAN Access Maps
6.4.6. DHCP Snooping
6.4.7. DAI
6.4.8. IP Source Guard
6.4.9. Private VLANs
6.5. Cisco IOS and Zone-Based Firewalls
6.5.1. Basic Cisco IOS Firewall
6.5.2. DoS Protection on a Cisco IOS Firewall
6.5.3. Basic Zone-Based Firewall
6.5.4. Zone-Based Firewall with Deep Packet Inspection
6.6. NAT
6.6.1. Dynamic NAT
6.6.2. PAT
6.6.3. Static NAT
6.6.4. Static PAT
6.6.5. Policy-Based NAT
6.7. Other Security Features
6.7.1. Configuring the TCP Intercept Feature
6.7.2. Configuring Blocking of Fragment Attacks
6.7.3. Configuring Switch Security Features
6.7.4. Configuring Antispoofing Using an ACL
6.7.5. Configuring Antispoofing Using uRPF
6.7.6. SSH on Routers and Switches
6.7.7. Cisco IOS IPS
6.7.8. Controlling Telnet and SSH Access to the Router and Switch
7.0 Implementing Network Services

Configuring and Troubleshooting Network Services
7.1. DHCP
7.1.1. Configuring DHCP on a Cisco IOS Router
7.1.2. Configuring DHCP on a Switch
7.1.3. Using a Router and a Switch to Act as a DHCP Relay Agent (Helper Address)
7.2. HSRP
7.2.1. HSRP Between Two Routers
7.2.2. Pre-empt for HSRP
7.2.3. Authentication for HSRP
7.2.4. VRRP
7.2.5. GLBP
7.3. IP Services
7.3.1. Use of the Router for WCCP
7.3.2. Use of the Router to Generate an Exception Dump Using TFTP
7.3.3. Use of the Router to Generate an Exception Dump Using FTP
7.3.4. Use of the Router to Generate an Exception Dump Using RCP
7.3.5. Broadcast Forwarding for Protocols
7.4. System Management
7.4.1. Telnet Management on the Router and Switch
7.4.2. SSH Management on the Router and Switch
7.4.3. Disabling Telnet and the SSH Client on the Switch
7.4.4. HTTP Management on the Router and Switch
7.4.5. Controlling HTTP Management on the Router and Switch
7.5. NTP
7.5.1. NTP Using the NTP Master and NTP Server Commands
7.5.2. NTP Without Using the NTP Server
7.5.3. NTP Using NTP Broadcast Commands
8.0 Implementing QoS

Configuring and Troubleshooting QoS
8.1. Classification
8.1.1. Marking Using DSCP
8.1.2. Marking Using IP Precedence
8.1.3. Marking Using CoS
8.2. Congestion Management and Congestion Avoidance
8.2.1. Priority Queuing
8.2.2. Custom Queuing
8.2.3. Weighted Fair Queuing
8.2.4. WRED
8.2.5. RSVP
8.3. Policing and Shaping
8.3.1. CAR Using Rate Limiting Under the Interface
8.3.2. Frame Relay Traffic Shaping Using Map Classes
8.3.3. Discard Eligible List
8.4. Link Efficiency Mechanisms
8.4.1. Compression
8.4.2. Link Fragmentation and Interleaving (LFI) for Frame Relay
8.5. Modular QoS CLI
8.5.1. Policing
8.5.2. Class-Based Weighted Fair Queuing (CB-WFQ)
8.5.3. Low Latency Queuing (LLQ)
8.5.4. Shaping Using MQC
8.5.5. Random Early Detection Using MQC
8.5.6. WRED Using MQC
8.5.7. Using NBAR for QoS
8.5.8. Discard Eligible Marking Using MQC
8.6. Catalyst QoS
8.6.1. SRR on the Catalyst Switch
9.0 Troubleshooting a Network

Troubleshooting Network-Wide Connectivity Issues
9.1. Troubleshooting Layer 2 Problems
9.1.1. Troubleshooting Catalyst Switch Network Issues
9.1.2. Troubleshooting Frame Relay Network Issues
9.2. Troubleshooting Layer 3 Problems
9.2.1. Troubleshooting IP Addressing Network Issues
9.2.2. Troubleshooting Routing Protocol Network Issues
9.2.3. Troubleshooting Routing Protocol Loop Issues
9.3. Troubleshooting Application Problems
9.3.1. Determining Which Aspects of the Network to Troubleshoot to Determine Network Functionality (Given a Set of Symptoms)
9.4. Troubleshooting Network Services
9.4.1. Troubleshooting Misconfigured NTP Setup
9.4.2. Troubleshooting Misconfigured DHCP Setup
9.4.3. Troubleshooting Misconfigured Telnet and SSH Setup
9.4.4. Troubleshooting Misconfigured SNMP Setup
9.5. Troubleshooting Security Services
9.5.1. Troubleshooting Misconfigured ACLs
9.5.2. Troubleshooting Misconfigured NAT
9.5.3. Troubleshooting Misconfigured AAA Services
10.0 Optimizing a Network

Configuring and Troubleshooting Optimization of a Network
10.1. Logging In
10.1.1. Logging into a Remote Syslog Server
10.1.2. Logging into the Internal Buffer
10.2. SNMP
10.2.1. Use of a Router to Communicate to an SNMP Management Station
10.2.2. Use of a Router to Generate SNMP Traps
10.3. RMON
10.3.1. Use of a Router to Generate SNMP Traps Using RMON
10.4. Accounting
10.4.1. IP Accounting
10.5. SLA
10.5.1. IP SLA
10.6. Implementing Network Services on the Routers
10.6.1. Use of a Router as an FTP Server
10.6.2. Use of a Router as a TFTP Server
10.6.3. Cisco IOS Embedded Event Manager
10.6.4. NetFlow
10.6.5. HTTP and HTTPS on a Router
10.6.6. Telnet on a Router
10.6.7. Implementing Secure Copy Protocol (SCP) on a Router

Notes comment from IP Expert:

  • PPP over Frame Relay is explicitly mentioned
  • Regular and smart macros for switches are explicitly mentioned
  • Redistribution between OSPF and RIP isn’t mentioned, but we shouldn’t ignore it
  • BGP peer groups are mentioned, but not templates
  • There is no mention on OER/PfR!
  • Bidirectional PIM is mentioned
  • Dense-mode PIM is mentioned
  • Bootstrap ROuter (BSR) is not mentioned
  • Multicast Routing Monitor isn’t mentioned
  • Zone Based Firewall with deep packet inspection is mentioned
  • Policy-based NAT is mentioned
  • TCP intercept is mentioned
  • “Old” QoS reappears – CQ, PQ, CAR and FRTS

How the bgp deterministic-med Command Differs from the bgp always-compare-med Command

~ Mar Apuhin ~ 2 Comments

Introduction

There is sometimes confusion between the two Border Gateway Protocol (BGP) configuration commands bgp deterministic-med and bgp always-compare-med. This document explains the differences in how the bgp deterministic-med and bgp always-compare-med commands can affect Multi Exit Discriminator (MED)-based path selection and how each command changes the behavior of BGP when choosing a best route.
Prerequisites
Requirements

There are no specific requirements for this document.
Components Used

The information in this document is based on the Cisco IOS® Software Release 12.2(10b).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Background Information

There are two BGP configuration commands that can influence the MED-based path selection, the bgp deterministic-med and the bgp always-compare-med commands.

Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems. The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for setting MED. Thus, for network X, if Internet Service Provider A (ISP A) sets the MED to 10, and ISP B sets the MED to 20, both ISPs agree that ISP A has the better performing path to X.

Note: The bgp deterministic-med and bgp always-compare-med commands are not enabled by default. Also, the two commands are separate; enabling one does not automatically enable the other.
Command Examples

The examples in this section demonstrate how the bgp deterministic-med and bgp always-compare-med commands can influence MED-based path selection.

Note: Cisco Systems recommends enabling the bgp deterministic-med command in all new network rollouts. For existing networks, the command must either be deployed on all routers at the same time, or incrementally, with care to avoid possible internal BGP (iBGP) routing loops.

For example, consider the following routes for network 10.0.0.0/8:

entry1: AS(PATH) 500, med 150, external, rid 172.16.13.1
entry2: AS(PATH) 100, med 200, external, rid 1.1.1.1
entry3: AS(PATH) 500, med 100, internal, rid 172.16.8.4

The order in which the BGP routes were received is entry3, entry2, and entry1. (Entry3 is the oldest entry in the BGP table, and entry1 is the newest one.)

Note: When BGP receives multiple routes to a particular destination, it lists them in the reverse order that they were received, from the newest to the oldest. BGP then compares the routes in pairs, starting with the newest entry and moving toward the oldest entry (starting at top of the list and moving down). For example, entry1 and entry2 are compared. The better of these two is then compared to entry3, and so on.
Example 1: Both Commands Disabled

Entry1 and entry2 are compared first. Entry2 is chosen as the better of these two because it has a lower router ID. The MED is not checked because the paths are from a different neighbor autonomous system. Next, entry2 is compared to entry3. Entry2 is chosen as the best path because it is external.
Example 2: bgp deterministic-med Disabled, bgp always-compare-med Enabled

Entry1 is compared to entry2. These entries are from different neighbor autonomous systems, but since the bgp always-compare-med command is enabled, MED is used in the comparison. Of these two entries, entry1 is better because it has a lower MED. Next, entry1 is compared to entry3. The MED is checked again because the entries are now from the same autonomous system. Entry3 is chosen as the best path.
Example 3: bgp deterministic-med Enabled, bgp always-compare-med Disabled

When the bgp deterministic-med command is enabled, routes from the same autonomous system are grouped together, and the best entries of each group are compared. The BGP table looks like this:

entry1: AS(PATH) 100, med 200, external, rid 1.1.1.1
entry2: AS(PATH) 500, med 100, internal, rid 172.16.8.4
entry3: AS(PATH) 500, med 150, external, rid 172.16.13.1

There is a group for AS 100 and a group for AS 500. The best entries for each group are compared. Entry1 is the best of its group because it is the only route from AS 100. Entry2 is the best for AS 500 because it has the lowest MED. Next, entry1 is compared to entry2. Since the two entries are not from the same neighbor autonomous system, the MED is not considered in the comparison. The external BGP route wins over the internal BGP route, making entry1 the best route.
Example 4: Both Commands Enabled

The comparisons in this example are the same as in Example 3, except for the last comparison between entry2 and entry1. The MED is taken into account for the last comparison because the bgp always-compare-med command is enabled. Entry2 is selected as the best path.

Featured Article: Flexible Packet Matching

~ Mar Apuhin ~ 1 Comment

Featured Article: Flexible Packet Matching By Steve Means

One of the issues facing network and security engineers is defending the network against dynamic threats. This means traffic that cannot easily be identified by regular means, such as an application that changes layer 4 ports or tunnels within an existing protocol. Because of this, a solution is needed to match and filter based on specific information within the packet that is unique to the application you want to block.

Enter “Flexible Packet Matching”, otherwise known as FPM. FPM works by loading XML files called “Protocol Header Description Files” that define fields within the protocol header: IP, TCP, UDP, ICMP, etc…. Once defined, information within the fields can be matched and acted on using MQC.

As a simple example, we’re going to allow ICMP but block echo requests that come from 192.168.9.10 with a length greater than 500.

To enable FPM, you need to first load the PHDFs for the protocol stack you’ll be working with. We’ll be using ETHER, IP and ICMP, so those files are loaded with the “load” command:

load protocol system:/fpm/phdf/ether.phdf
load protocol system:/fpm/phdf/ip.phdf
load protocol system:/fpm/phdf/icmp.phdf

Next you have to tell FPM the correct protocol stack to examine. This is done with a class-map type stack. Notice that we start at layer 2, match the ethertype for IP, then move to layer 3, matching IP protocol 1 or ICMP.

class-map type stack match-all IP_ICMP
stack-start l2-start
match field ether type eq 0x800 next IP
match field layer 3 IP protocol eq 1 next ICMP

With the stack defined, we’re now free to match the specific information we’re after, FPM uses “class-map type access-control”.

class-map type access-control match-all BAD_ICMP
match field icmp type eq 8
match field ip source-addr eq 10.6.6.6
match field ip length gt 500

Now we’ll create a “policy-map type access-control” to drop any traffic that is a part of this class. This policy map is then nested within another policy map that matches our previously defined protocol stack. It is then applied to the interface:

policy-map type access-control DROP_BAD_ICMP
class BAD_ICMP
drop
policy-map type access-control FPM
class IP_ICMP
service-policy DROP_BAD_ICMP
!
int fa0/1
service-policy type access-control input FPM

Verification is simple. First we’ll ping from a router with an interface IP of 192.168.2.10 with no options:

R2# ping 10.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 50/58/60 ms

The ping is successful as expected. It matches the stack, ICMP type and source address, but not the size. Now we can repeat the ping, upping the size:

R2# ping 10.6.6.6 size 1000
Type escape sequence to abort.
Sending 5, 1000-byte ICMP Echos to 10.6.6.6, timeout is 2 seconds:
….
Success rate is 0 percent (0/5)

This time the packets were dropped. We can further verify by checking the policy-map on the router using FPM. Notice that we have lots of packets matching the stack class-map, but only our 5 echo requests were dropped:

R1#sho policy-map type access-control interface
FastEthernet0/1

Service-policy access-control input: FPM

Class-map: IP_ICMP (match-all)
136 packets, 15468 bytes
5 minute offered rate 0 bps
Match: field ETHER type eq 0x800 next IP
Match: field layer 3 IP protocol eq 1 next ICMP

Service-policy access-control : DROP_BAD_ICMP

Class-map: BAD_ICMP (match-all)
5 packets, 5070 bytes
5 minute offered rate 0 bps
Match: field ICMP type eq 8
Match: field IP length gt 500
Match: field IP source-addr eq -1062729462
drop

This is a fairly basic example that is easy to verify and learn with. FPM can be much more detailed, even going so far as to match specific strings within the data payload itself. The preferred method of applying this in the field is to sniff the traffic you’re interested in, find something that is unique to this traffic and match based on it.

Free Lab Book (download) – Narbik

~ Mar Apuhin ~ 5 Comments

Here is Narbik’s post from GS

To All,

First of all I would like to apologize for the delay.

Secondly, please excuse any typos, I kind of rushed to get this out so you guys will enjoy the lab.

Once again there are no registrations, no sign-ins or any other requirements to download the lab.

Please go to

http://www.micronicstraining.com/classes/index.php?dispatch=categories.view&category_id=93

And then, click on *CCIE Routing and Switching Trouble Shooting Workbook* and then, click on *Download FREE sample chapter*.

Please let me know if you experience any problems.

The initial config file is also included. You need to have winrar to unzip the directory, it also includes the diagrams.

This lab is one of the 10 Troubleshooting Mock labs and hope it would NOT be a waste of your precious time. PLease go through and read the answers and see the steps that one has to go through to resolve a trouble ticket.

I have also included another FREE lab work book that you guys can download; it has 338 pages of good labs (They help reduce your blood pressure, whereas, the TS labs help reducing the cholestrol). You should see it there as well.

The security work book and the SP will be our next priority and they should be completed before the end of the year.

There will also be a FREE VOD on ZBFW, that should be finished within a week or so.

Enjoy and I hope to see you guys later.

–
Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
http://www.MicronicsTraining.com
Sr. Technical Instructor
YES! We take Cisco Learning Credits!

CCIE Policies

~ Mar Apuhin ~ 2 Comments

Candidates should be familiar with the policies for CCIE program participation, as stated below. If you have any questions regarding the policies please contact CCIE customer support through the Certifications Online Support tool.

  • Conduct
    Candidates must agree they will not compromise the integrity or confidentiality of any Cisco certification exam or certification program. Prohibited actions are described in the Cisco Career Certifications and Confidentiality Agreement. Remedies for violating the policy can include a lifetime ban on all future exams and voiding of all previous certifications.

    Return to Top

  • Confidentiality
    The questions and answers of the certification exams are the exclusive and confidential property of Cisco and are protected by Cisco’s intellectual property rights. Candidates taking Cisco exams must agree they have read and will abide by the terms and conditions of the Cisco Career Certifications and Confidentiality Agreement before beginning each exam.

    Return to Top

  • Correspondence
    All official correspondence to certified CCIEs and candidates is sent to the email address in the CCIE database. This database is SEPARATE from the Cisco customer database. Changing an email address in the Cisco customer database does not automatically update the CCIE database. CCIEs and candidates must keep their CCIE email address updated in order to ensure they received all official correspondence.

    Return to Top

  • Exam Violations
    Disclosure of test content is strictly prohibited. Please report any suspicious activity as described in Cisco’s Exam Violation Rules.

    Return to Top

  • Lab Exam: Double Booking
    CCIE candidates are allowed to schedule only a single CCIE lab exam date at any location for each CCIE track. Double booking for lab exams in the same track, at either the same location or different locations, is not permitted by the database. Candidates will be allowed to simultaneously schedule lab exams for different tracks.

    Return to Top

  • Lab Exam: Exam Rules
    Candidates for the CCIE written exam or lab exam are not allowed to bring anything into the exam room or take anything out. This includes, but is not limited to: notes, documentation, watches, laptops, keyboards, pagers, PDAs, and mobile phones. DO NOT confer or consult with anyone about the exam while taking the exam or after the exam is completed. During an exam, you may only discuss your exam with the lab engineer.

    Return to Top

  • Lab Exam: Payment

    Price not confirmed and is subject to change until full payment is made.

    Types. Lab sites in China and Japan will only accept payment via wire transfer. All other locations accept online credit card payment (American Express, Visa, Mastercard, or Eurocard) See “Lab Exam: Scheduling and Payment” for details. You are responsible for any fees your financial institution may charge to complete the payment transaction.

    Due Date. Full payment must be received at least 90 days before the lab exam date. Only one e-mail notice is sent as a payment reminder. Payments generally take one to seven business days to process, so be sure to initiate payment in advance of the due date. It is important that if payment will be made by wire transfer, that the payment is scheduled well in advance to prevent the lab date being dropped. Exams for which payment is not received by the due date will be automatically dropped from the schedule. If you still wish to take the lab, you must rebook the exam online and complete your payment. There is no guarantee that your original date will still be available once it has been dropped for non-payment. If you book an exam for a date less than 90 days away, you must complete payment on the day you book the exam or the registration cannot be submitted. Candidates are ultimately responsible for making the lab payment in a timely manner and Cisco will not be held liable for any candidates automatically dropped due to non-payment.

    Processing. Credit card payments entered into the system will be processed on the payment due date, exactly 90 days prior to your lab date, as will invoices for all payment types. Be sure the company name, invoicing address and email address are complete and accurate to ensure proper delivery of your invoice. No invoices will be generated before the lab exam due date.

    Return to Top

  • Lab Exam: Rescheduling, Canceling and Postponing
    Prior to Due Date. Cancellations or changes to the exam date, location, or track must be made prior to the payment due date–90 days before the scheduled lab date. To make any changes, you must log into the Lab Scheduling tool and drop your current lab. Then you can reschedule according to preferred date, location and track. You may book an exam for a date less than 90 days away, if you complete payment on the day you book the exam.

    If you need to cancel an exam before the due date, and paid via a wire transfer that has already cleared, you are eligible for a full refund by requesting support via the Certifications Online Support tool.

    After Due Date. Changes and cancellations are not permitted after the payment due date–90 days prior to the scheduled lab date–and no refunds will be issued. If you are not able to attend your scheduled lab date, contact support to let them know the lab seat will not be used. You will still forfeit your payment, but you will be allowed to book another exam date immediately. If you do not contact support, you will be marked as a “no show” for the exam and be barred from booking another exam for 30 days.

    Candidates Requiring Visas. If you require a visa to attend your lab exam, it is strongly recommended you apply 10-12 weeks before your lab date. Candidates who fail to obtain required visas will still be bound by these cancellation policies and must cancel their lab exam before the payment due date to be eligible for a full refund. For more information in requesting a CCIE Invitation Letter, please visit our CCIE: Invitation Letter (Entrance Visa) Instant Answer.

    Return to Top

  • Lab Exam: Reevaluation of Lab Results

Exam results appeals are available for the routing and switching, security, and service provider technology tracks. Only exams with potential to change from fail to pass will have the option to request an appeal, based on years of historical data. Appeals are not available for the voice or storage tracks due to equipment limitations.

An appeal consists of a second proctor loading your configurations into a rack to recreate the test and re-score the entire exam. This process takes up to three weeks after receipt of payment. Only one appeal per lab attempt is permitted.

The result of the appeal is a confirmation of the existing fail or an update to a pass.

Payment Terms

Make your request within 14 days following your exam date by using the “Request for Reread” link next to your lab record. Each appeal costs $250.00 USD plus any applicable local taxes. Payment is made online via credit card and your card will be charged upon receipt of the request. You may not cancel the appeal request once the process has been initiated. Refunds are given only when results change from fail to pass.

Return to Top

  • Lab Exam: Retakes
    All candidates must wait 30 days between CCIE lab attempts. Please note the 30 days starts from the day after a failed lab exam.

    Return to Top

  • Lab Exam: Scoring
    You must obtain an overall score of at least 80% to pass the lab exam. You can view your lab exam results online (login required), usually within 48 hours. Results are Pass/Fail and failing score reports indicate major topic areas where additional study and preparation may be useful.

    Return to Top

  • Lab Exam: Start Times
    Start times for exams are indicated in email can also found on the web page associated with each lab location (for a list, see Lab Exam Locations). Please verify your email address in your candidate profile so we can notify you of any changes. If you have any questions about the start time of your exam, please contact CCIE customer support through the Certifications Online Support tool . If you arrive more than two hours after the start of your exam, you will not be allowed to start. If you arrive less than two hours late, you will be allowed to start but you must finish with the rest of the group.

    Return to Top

  • Logo Guidelines
    Certified CCIEs may only use the CCIE logo as provided and in accordance with the published Logo Guidelines.

    Return to Top

  • Recertification
    To maintain active CCIE status, CCIEs are required to pass either a CCIE written exam of their choosing from among all of the currently available written exams, or a CCIE lab exam in a new track every 24 months. Candidates can only apply one passed written exam towards recertification for every 24 month recertification period. Certification candidates are responsible for keeping track of their certification expiration dates; your recertification deadline can be viewed online anytime (with login) at Certification Status. Subsequent recertification deadlines are always based on your original certification date, not on when you took your last recertification exam.

    If your CCIE recertification requirements are not completed on or before the certification’s expiration date, your CCIE certification will be suspended for one year. Candidates have one year to recertify their CCIE certification by passing the required written exam. If a candidate does not recertify prior to the one year suspension period, all CCIE certification requirements must be completed again to obtain the certification (pass both the written exam and the lab exam.) Please see Recertification for detailed information.

    Return to Top

  • Travel Costs
    Under no circumstances will Cisco reimburse travel costs for CCIE lab exams.

    Return to Top

  • Written Exam: Expiration
    Candidates must make an initial attempt of the CCIE lab exam within 18 months of passing the CCIE written exam. Candidates who do not pass must re-attempt the lab exam within 12 months of their last scored attempt in order for their written exam to remain valid. If a candidate does not pass the lab exam within three years of passing the written exam, he or she must retake the written exam before being allowed to attempt the lab exam again.

    Return to Top

  • Written Exam: Retakes
    There is no limit to the number of attempts that can be made on the written exam. However, candidates must wait 5 calendar days between exam attempts. Once a candidate passes a particular written exam, he or she may not retake that same exam for at least 180 days. (Though rare, this may occur in certain recertification situations.)

    Return to Top

  • Written Exam: Scoring
    Pass marks are set by using statistical analysis and are subject to change. The pass score is given on the Examination Score Sheet at the end of the test. Along with the candidate’s score, there is a notation of either PASS or FAIL. Scores on written exams are automatically downloaded from testing vendors, but may take up to 10 days to appear in the CCIE database.

    Return to Top

IP Routing Tech Notes and Troubleshooting Guides

~ Mar Apuhin ~ 1 Comment

  • Border Gateway Protocol (BGP)
  • Classless Interdomain Routing (CIDR)
  • Enhanced Interior Gateway Routing Protocol (EIGRP)
  • Integrated Intermediate System-to-Intermediate System (IS-IS)
  • Interior Gateway Routing Protocol (IGRP)
  • Multiprotocol BGP (MBGP)
  • On-Demand Routing (ODR)
  • Open Shortest Path First (OSPF)
  • Routing Information Protocol (RIP)

I found the above link from Cisco’s website very usefule.

Happy Labbing!

Core Knowledge Questions Now on All CCIE Labs

~ Mar Apuhin ~ 2 Comments

Effective January 4, 2010, the CCIE® Service Provider, Storage, and Wireless Lab Exams will add a new type of question format in a section called Core Knowledge. In this new section, candidates will be asked a series of four open-ended questions which require a short written response be entered into the computer–typically several words. The questions will be randomly drawn from a pool of questions on topics eligible for testing. Candidates can review the topics by visiting the CCIE track information on Cisco.com or Cisco Learning Network. No new topics are being added as a result of this change. Candidates will have up to 30 minutes to complete the Core Knowledge section and may not return to it once they have moved on. A passing score on the Core Knowledge section is required to achieve certification. Core Knowledge questions were implemented on Routing and Switching labs in February 2009, Security labs in June 2009, and Voice labs in July 2009, and allow Cisco to maintain strong exam security and ensure only qualified candidates are awarded CCIE certification. Candidates with exam dates January 4, 2010 or later should expect to see the new question format on their lab exam.

To find out more information regarding updates to the CCIE Lab and scoring format, please click here to go to the CCIE Q&A section.

Cisco IOS Zone-Based Firewall and Intrusion Prevention System Overview VOD’s

~ Mar Apuhin ~ 1 Comment

To all my active and loyal CCIEPILOT.COM’s followers…

Training session Webex Recordings

Cisco IOS Zone-Based Firewall Concept, Configuration, and Troubleshooting
https://ciscosupport.webex.com/ciscosupport/ldr.php?AT=pb&SP=MC&rID=1908767&rKey=af5f55c7874a225b

Cisco IOS Intrusion Prevention System Overview and Troubleshooting
https://ciscosupport.webex.com/ciscosupport/ldr.php?AT=pb&SP=MC&rID=1922807&rKey=22339b09e0dc96d0

PPP – no peer neighbor-route

~ Mar Apuhin ~ Leave a comment

Trivia: PPP

Diagram:

R4-s0/1<<——–Serial-back-2-back———>>s0/1-R5

Question:

Configure PPP on the Serial connection between R4 and R5 using dialer
interfaces.

Answer:

R4 and R5

interface Serial0/1
no ip address
encapsulation ppp
dialer in-band
dialer pool-member 1
pulse-time 1

interface Dialer0
ip address 45.45.45.x 255.255.255.0
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
end

Routing Table:

C       45.45.45.x/32 is directly connected, Dialer0
C       45.45.45.0/24 is directly connected, Dialer0

R4#sh dialer

Se0/1 – dialer type = IN-BAND SYNC NO-PARITY
Dialer pool 1, priority 0
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Interface bound to profile Di0
Time until disconnect never
Connected to <unknown phone number> (<unknown phone number>)

Di0 – dialer type = DIALER PROFILE
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Number of active calls = 1

Dial String      Successes   Failures    Last DNIS   Last status

Trivia: PPP – I dont want the /32 in you.

We always see a /32 host route every time we use PPP. What if you dont like and want it? What

will you do?

Diagram:

R1-s0/1<<—–Serial-Connection——>s0/1-R2

Answer Configuration: use “no peer neighbor-route” interface command.

R1 and R2

interface Serial0/1
ip address 12.12.12.x 255.255.255.0
encapsulation ppp
no peer neighbor-route

Routing Table:

12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       12.12.12.0/24 is directly connected, Serial0/1
C       12.12.12.2/32 is directly connected, Serial0/1 <<<<< Get rid of this!

After:

Gateway of last resort is not set

12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/1

Verification:

R1#ping 12.12.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/56 ms
R1# ping 12.12.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/68/120 ms
R1#

Show to know:

R1#sh int s0/1 | i Open
Encapsulation PPP, LCP Open
Open: IPCP, CDPCP, crc 16, loopback not set
R1#

That’s it!

Internetwork Experts CCIE 2.0 Program

~ Mar Apuhin ~ Leave a comment

Audio Classes

CCIE 2.0

Classes-on-Demand

Workbooks

Lab Breakdown for R&S Lab Workbook Volume II v4.1

CCIE Routing & Switching Open Lecture Series

~ Mar Apuhin ~ 1 Comment

* IP Multicast – 11/13/2008 Part 1
o PIM Dense Mode
o RPF Failure
o Static Mroutes

* IP Multicast – 11/13/2008 Part 2
o PIM Sparse Mode
o Static RP Assignment
o IGMP Join
o PIM Join
o PIM Register

* IP Multicast – 11/13/2008 Part 3
o PIM Register Troubleshooting

* IP Multicast – 11/14/2008 Part 1
o PIM Sparse Dense Mode

* IP Multicast – 11/14/2008 Part 2
o PIM Sparse Dense Mode with Auto-RP

* IP Multicast – 11/14/2008 Part 3
o PIM AutoRP Listener

* IP Multicast – 11/14/2008 Part 4
o PIM NBMA Mode

* IP Multicast – 11/14/2008 Part 5
o PIM NBMA Mode
o Default RP Placement

* OSPF – 11/18/2008 Part 1
o OSPF Intra-Area Routing

* OSPF – 11/18/2008 Part 2
o OSPF Inter-Area Routing

* OSPF – 11/18/2008 Part 3
o OSPF Inter-Area Routing with Multiple ABRs

* OSPF – 11/18/2008 Part 4
o OSPF External Routing

* OSPF – 11/20/2008 Part 1
o OSPF Virtual Links

* OSPF – 11/20/2008 Part 2
o Traffic Engineering with Virtual-Links

* BGP – 11/26/2008
o BGP Traffic Engineering with Aggregation

* QoS – 12/03/2008
o Custom Queuing

* QoS – 12/04/2008
o WFQ
o CBWFQ
o Bandwidth Reservations
o Prioritization with LLQ

* Bridging & Switching – 12/09/2008
o EtherChannel
o Dot1q Tunneling
o EtherChannel over Dot1q Tunneling

* IP Routing – 12/16/2008
o IP SLA
o Enhanced Object Tracking
o Reliable Static Routing
o Reliable Policy Routing

* RIP – 12/17/2008
o RIP Filtering

* Redistribution – 12/23/2008
o Advanced IPv4 Redistribution

* IPv6 – 12/30/2008
o Advanced IPv6 Design

* NAT – 01/14/2009
o Advanced NAT Design

* First Hop Redundancy – 01/15/2009
o Advanced First Hop Redundancy Protocols

* Redistribution – 01/23/2009
o Advanced IPv4 Redistribution

* BGP – 01/28/2009
o BGP Conditional Route Injection

* BGP – 01/29/2009
o BGP Next-Hop Processing

* Security – 02/04/2009
o Reflexive Access-Lists
o CBAC
o TCP Intercept

* Security – 02/06/2009
o Dynamic Access-Lists
o Time Based Access-Lists

* Multicast – 02/11/2009
o IP Multicast Helper Map
o Broadcast to Multicast Conversions

* Security – 02/12/2009
o LAN Security
o DHCP Snooping
o IP Source Guard
o Dynamic ARP Inspection

* Security – 02/18/2009
o Local Command Authorization
o Role Based CLI

* Security – 02/19/2009
o AAA

* BGP – 02/25/2009
o BGP Route Reflection and Clusters

* BGP – 02/26/2009
o BGP Aggregation

* BGP – 03/05/2009
o BGP Synchronization
o BGP and IGP Redistribution

* IPv6 – 03/10/2009
o IPv6 BGP

* BGP – 03/18/2009
o BGP Communities

* Bridging & Switching – 03/19/2009
o 802.1q Tunnelling and EtherChannel

* Core Knowledge – 04/01/2009
o Open Ended Questions
o Core Knowledge Simulation

* IP Multicast – 04/02/2009
o Understanding RPF Check

* Security – 04/08/2009
o Content Based Access Control (CBAC)

* CCIE Lab Strategy – 04/09/2009
o Task Tracker

* Dynamips with GNS3 – 04/22/2009
o Using GNS3 For Lab Preparation

* IP Routing – 04/23/2009
o Route Config BP

* Security – 04/30/2009
o Calculating Complex Access Lists

* BGP – 05/01/2009
o BGP Bestpath Selection

* Bridging & Switching – 05/07/2009
o Spanning Tree Features

* Bridging & Switching – 05/08/2009
o Multiple Spanning Tree (MST)

* Bridging & Switching – 05/13/2009
o MST – Multiple Regions

* Bridging & Switching – 05/14/2009
o Point-to-Point Protocol (PPP)
o PPP over Frame Relay (PPPoFR)

* Bridging & Switching – 05/20/2009
o Layer 2 Catalyst QoS

* IP Routing – 05/21/2009
o GRE Tunnelling
o Recursive Routing

* EIGRP – 05/28/2009
o EIGRP Unequal Cost Load Balancing

* RIP – 06/03/2009
o RIPv2 Filtering

* EIGRP – 06/04/2009
o EIGRP Filtering and Stub Routing

* Security – 06/10/2009
o Security – BGP Remotely Triggered Blackhole Filtering

* Security – 06/12/2009
o BGP Sinkhole Filtering

* Bridging & Switching – 06/25/2009
o Transparent Bridging
o IRB

* QoS – 06/24/2009
o Frame Relay Traffic Shaping

* OSPF – 06/30/2009
o OSPF Filtering

* IGP – 07/02/2009
o IGP Summarization

* IP Services – 07/07/2009
o NAT TCP Load Balancing
o Server Load Balancing
o IOS SLB

* BGP – 07/09/2009
o BGP Communities

* Using the Cisco Documentation – 07/16/2009
o Using the Cisco Documentation

* MPLS – 07/17/2009
o CCIE R&S v4.0 Blueprint
o MPLS Introduction

* MPLS – 07/23/2009
o MPLS Configuration

* MPLS – 07/24/2009
o MPLS Configuration (Cont)

* MPLS – 07/28/2009
o MPLS L3VPN Verification

* Security – 07/30/2009
o Zone Based Policy Firewall

EIGRP stub feature demonstration.

~ Mar Apuhin ~ 10 Comments

Diagram:

<RIP>—–R1——-<EIGRP>——-R2—<RIP>
                  |
         Loopbacks0-3

Loopbacks0-3

R1:
router eigrp 100
redistribute static metric 1 1 1 1 1
redistribute rip metric 1 1 1 1 1
network 1.0.0.0
network 131.1.0.0
no auto-summary
router rip
version 2
passive-interface default
no passive-interface FastEthernet1/0
network 200.1.1.0
no auto-summary

R1#r stat
S 11.0.0.0/8 is directly connected, FastEthernet1/0
R1#r c
1.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 1.1.0.0/24 is directly connected, Loopback0
C 1.1.1.0/24 is directly connected, Loopback1
C 1.1.2.0/24 is directly connected, Loopback2
C 1.1.3.0/24 is directly connected, Loopback3
C 200.1.1.0/24 is directly connected, FastEthernet1/0
131.1.0.0/24 is subnetted, 1 subnets
C 131.1.12.0 is directly connected, Serial0/0.12
R1#i s0/0.12
Building configuration…

Current configuration : 195 bytes
!
interface Serial0/0.12 point-to-point
ip address 131.1.12.1 255.255.255.0
ip summary-address eigrp 100 1.1.0.0 255.255.252.0 12
snmp trap link-status
frame-relay interface-dlci 102
end

R1#

R1#e n
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 131.1.12.2 Se0/0.12 12 00:01:49 152 1368 0 124
R1#

This is the normal routing table of R2

R2#r e
1.0.0.0/22 is subnetted, 1 subnets
D 1.1.0.0 [90/2297856] via 131.1.12.1, 00:02:01, Serial0/0.12
D EX 200.1.1.0/24 [170/2560512256] via 131.1.12.1, 00:02:01, Serial0/0.12
D EX 11.0.0.0/8 [170/2560512256] via 131.1.12.1, 00:02:01, Serial0/0.12
R2#

On R2 we received the following from R1:

– static routes of R1
– connected but summarized routes of R1 – EX 11.0.0.0/8
– External IGP routes (from R1’s RIP) – EX 200.1.1.0/24

Now we will demonstrate the EIGRP stub feature.
In this scenario we will configure R1 for EIGRP stub feature.

R1(config)#router eigrp 100
R1(config-router)#?
Router configuration commands:
eigrp EIGRP specific commands
R1(config-router)#eigrp ?
stub Set IP-EIGRP as stubbed router

R1(config-router)#eigrp stub ?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

Here we will demonstrate the following options:

connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

Results:

ORIGINAL Routing table on R2:

R2#show ip route e
1.0.0.0/22 is subnetted, 1 subnets
D 1.1.0.0 [90/2297856] via 131.1.12.1, 00:02:01, Serial0/0.12
D EX 200.1.1.0/24 [170/2560512256] via 131.1.12.1, 00:02:01, Serial0/0.12
D EX 11.0.0.0/8 [170/2560512256] via 131.1.12.1, 00:02:01, Serial0/0.12
R2#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.1 (Serial0/0.12) is down: Interface Goodbye received
R2#r e
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.1 (Serial0/0.12) is up: new adjacency

2. eigrp stub connected

R1(config-router)#eigrp stub connected

R2#show ip route e
1.0.0.0/24 is subnetted, 4 subnets
D 1.1.0.0 [90/2297856] via 131.1.12.1, 00:00:05, Serial0/0.12
D 1.1.1.0 [90/2297856] via 131.1.12.1, 00:00:05, Serial0/0.12
D 1.1.2.0 [90/2297856] via 131.1.12.1, 00:00:05, Serial0/0.12
D 1.1.3.0 [90/2297856] via 131.1.12.1, 00:00:05, Serial0/0.12

R2#

Result of R1(config-router)#eigrp stub summary on R2:

R2#show ip route e
1.0.0.0/22 is subnetted, 1 subnets
D 1.1.0.0 [90/2297856] via 131.1.12.1, 00:00:05, Serial0/0.12

Result of R1(config-router)#eigrp stub static on R2:

R2#show ip route e
D EX 11.0.0.0/8 [170/2560512256] via 131.1.12.1, 00:00:01, Serial0/0.12

Result of R1(config-router)#eigrp stub receive-only on R2: – NOTHING IS RECEIVED!

R2#show ip route e
R2#

Gets?

Show and tell (part 1 of many)

~ Mar Apuhin ~ Leave a comment 

Configure R5 to have an output the same as below:

R5#sh queueing int f0/0
Interface FastEthernet0/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class                     Random drop      Tail drop    Minimum Maximum  Mark
                            pkts/bytes       pkts/bytes    thresh  thresh  prob
      0                         0/0              0/0           20      40  1/10
      1                         0/0              0/0           22      40  1/10
      2                         0/0              0/0           24      40  1/10
      3                         0/0              0/0           26      40  1/10
      4                         0/0              0/0           28      40  1/10
      5                         0/0              0/0           31      40  1/10
      6                         0/0              0/0           33      40  1/10
      7                         0/0              0/0           35      40  1/10
   rsvp                         0/0              0/0           37      40  1/10

R5#sh queueing int f0/1
Interface FastEthernet0/1 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 75000 kilobits/sec

R5#sh policy-map int f0/1                 
 FastEthernet0/1

  Service-policy output: WRED

    Class-map: class-default (match-any)
      25550 packets, 2163646 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 0/0/0
         exponential weight: 9

  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
      0   13809/1396426         0/0              0/0           20      40  1/10
      1       0/0               0/0              0/0           22      40  1/10
      2       0/0               0/0              0/0           24      40  1/10
      3       0/0               0/0              0/0           26      40  1/10
      4       0/0               0/0              0/0           28      40  1/10
      5       0/0               0/0              0/0           30      40  1/10
      6   11741/767220          0/0              0/0           32      40  1/10
      7       0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10

R5#

 

Answer: (highlight to answer)

 

interface FastEthernet0/0
 random-detect

interface FastEthernet0/1
 service-policy output WRED

policy-map WRED
 class class-default
  fair-queue
  random-detect

 

Which FILTER is the most appropriate?

~ Mar Apuhin ~ Leave a comment

Configure R5 so that these hosts can only use
normal HTTP applications from 9am – 5pm Monday – Friday. All traffic should be dropped during the hours outside of this.

R5:
interface FastEthernet0/1
ip access-group FILTER1 in
!
ip access-list extended FILTER1
permit tcp any any eq www time-range WORK_HOURS
deny ip any any
!
time-range WORK_HOURS
periodic weekdays 9:00 to 17:00

or

R5:

interface FastEthernet0/1
ip access-group FILTER2 in

ip access-list extended FILTER2
permit tcp any any eq www time-range WORK_HOURS
deny tcp any any eq www
permit ip any any

time-range WORK_HOURS
periodic weekdays 9:00 to 17:00

Which FILTER is the most appropriate?

Effects of disabling spanning-tree STP between two path switches.

~ Mar Apuhin ~ Leave a comment

During my lab sessions I tried to disable STP between 2 switches with 2 links connected in parallel. These are the effects of disabling spanning tree between two path switches.

Rack1SW3(config)#no spanning-tree vlan 1363
Rack1SW3(config)#
*Mar 2 12:38:37.862: %SW_MATM-4-MACFLAP_NOTIF: Host 0014.f2ef.f300 in vlan 1363 is flapping between port Fa0/20 and port Fa0/21
Rack1SW3(config)#
*Mar 2 12:38:47.834: %SW_MATM-4-MACFLAP_NOTIF: Host 0014.f2ef.f300 in vlan 1363 is flapping between port Fa0/20 and port Fa0/21
Rack1SW3(config)#
*Mar 2 12:39:02.994: %SW_MATM-4-MACFLAP_NOTIF: Host 0014.f2ef.f300 in vlan 1363 is flapping between port Fa0/20 and port Fa0/21
Rack1SW3(config)#

After putting the switcport backup interface

Rack1SW4(config-if)#switchport backup interface f0/21
*Mar 2 12:41:04.494: %SPANTREE-6-PORTDEL_ALL_VLANS: FastEthernet0/20 deleted from all Vlans
*Mar 2 12:41:04.494: %SPANTREE-6-PORTDEL_ALL_VLANS: FastEthernet0/21 deleted from all Vlans
Rack1SW4(config-if)#switchport backup interface f0/21?
:

Rack1SW4(config-if)#switchport backup interface f0/21 ?
mmu mac-address move update
preemption preemption parameters
prefer load-balancing

The Proper CCIE Study Approach

~ Mar Apuhin ~ Leave a comment

• The first step is to get a basic
understanding
• The second step is to gain hands-on
experience to reinforce and expand your
understanding
• The third step is to gain an expert level of
understanding
• The fourth step is to finally gain the expert
level hands-on experience

CCIE Pilot is an OFFICIAL member of the InternetworkExpert.COM – INE.COM

~ Mar Apuhin ~ Leave a comment

Materials, VODs, Workbooks I use:

Routing & Switching Courses: CCIE 2.0

CCIE R&S Core Knowledge Simulation
R&S Lab Meet-Up Series Class-on-Demand
R&S Open Lecture Series Class-on-Demand
R&S Advanced Technologies 10-Day Class-on-Demand v4.5
R&S Advanced Technologies 5-Day Class-on-Demand v4.5
R&S Bootcamp Class-on-Demand (5-Day)

Workbooks

R&S Lab Workbook Volume I v4.1
R&S Lab Workbook Volume I Version 5.0 Beta
R&S Lab Workbook Volume II v4.1
R&S Lab Workbook Volume II Version 5.0 Beta
R&S Lab Workbook Volume III v4.1
R&S Lab Workbook Volume IV

Difference with IEWB Version 4.1 and Version 5.

~ Mar Apuhin ~ Leave a comment

You are now chatting with Mike (Sales)

Mike: Hello, thank you for contacting the Sales department. My name is Mike. How may I help you today?
Mar: Hi
Mike: How may I assist you today?
Mar: what is the difference between VOL2 WB version 4.1 and 5.0 ?
Mike: The primary difference between v4.1 and v5 of our R&S materials is simply the presentation format of the materials. Cisco has not made any recent changes to the R&S lab exam, and so both versions we have cover the same lab exam blueprint (up until October 2009). As such, you can use both to study with. New updates to cover the October 2009 changes will be released this summer.
Mike: As for the Volume II labs, we have a few available in v5 so far, with a grand total of 10 planned. These labs are structured just like the v4.1 labs we already have in the current Volume II, they’re just unique and new. So for Volume II labs, use both interchangeably to maximize your practice.
Mar: so you will have 10 more but all new and totally different from the 4.1 version?
Mike: Yes
Mar: any time line pls?
Mike: Yes, all will be finished by October 18th
Mar: Thank you for your answers. :-)
Mar: bye
Mike: Goodbye

Silly NAT Router Trick!

~ Mar Apuhin ~ 2 Comments

I found this on one of my MOCK labs.  The results shows 90% of students who took this question failed.  I do not want you to fail on this silly router trick. I failed on this question.

11. IP Services

11.1. NAT

  • • Configure a new Loopback interface on R3 using the IP address 145.X.133.3/24.
  • • Do not advertise this Loopback with any routing protocol.
  • • Configure R3 to source all telnet sessions off this new Loopback interface.
  • • Ensure that users on R3 can successfully telnet to all devices in your network.

Answer:  (highlight to show)

Task 11.1

R3:
!
ip telnet source-interface Loopback1
!
interface Loopback1
ip address 145.16.133.3 255.255.255.0
ip nat inside
!
interface FastEthernet0/0
ip nat outside
!
interface FastEthernet0/1
ip nat outside
!
interface Serial1/2.13
ip nat outside
!
interface Serial1/3.23
ip nat outside
!
ip nat inside source list 150 interface Loopback0 overload
!
access-list 150 permit tcp host 145.16.133.3 any eq telnet

Task 11.1 Verifications

Rack16R3#telnet 150.16.4.4 /source-interface loopback 1
Rack16R4#show tcp brief
Rack16R3#show ip nat translation

How to hide an IOS image on the flash?

~ Mar Apuhin ~ 1 Comment

I was wondering why one of my Lab routers had no boot image installed on the flash, while it can still boot up an image.

This is what I found out, a hidden IOS boot image on the flash drive.

Rack2R2#sh flash: | i bin
Rack2R2#sh ver | i flash:
System image file is “flash:c1841-adventerprisek9-mz.124-19b.bin”
Rack2R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack2R2(config)#no secure boot-image
Rack2R2(config)#
Rack2R2#sh flash: | i bin
1 25648872 Jul 26 2009 17:45:30 +00:00 c1841-adventerprisek9-mz.124-19b.bin
Rack2R2#