BGP Path Attributes


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


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


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?


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


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

CCIE4.0-IPv6 Multicast – Multicast Listener Discovery (MLD)


IPv6 multicast renames IGMP to the Multicast Listener Discovery Protocol (MLP). Version 1 of MLD is similar to IGMP Version 2, while Version 2 of MLD is similar to Version 3 IGMP. As such, MLD Version 2 Source Specific Multicast (SSM) for IPv6 environments.

Using MLD, hosts can indicate they want to receive multicast transmissions for select groups. Routers (queriers) can control the flow of multicast in the network through the use of MLD.

MLD uses the Internet Control Message Protocol (ICMP) to carry its messages. All such messages are link-local in scope, and they all have the router alert option set.

MLD uses three types of messages – Query, Report, and Done. The Done message is like the Leave message in IGMP version 2. It indicates a host no longer wants to receive the multicast transmission. This triggers a Query to check for any more receivers on the segment.

Configuration options for MLD will be very similar to configuration tasks we needed to master for IGMP. You can limit the number of receivers with the ipv6 mld limit command. If you want the interface to “permanently” subscribe, you can use the ipv6 mld join-group command. Also, like in IGMP, there are several timers you may manipulate for the protocol’s mechanics.

Configuring IPv6 multicast-routing with the global configuration command ipv6 multicast-routing, automatically configures Protocol Independent Multicast (PIM) an all active interfaces. This also includes the automatic configuration of MLD. Here are verifications:

R0#show ipv6 pim interface
Interface          PIM  Nbr   Hello  DR
 Count Intvl  Prior

Tunnel0            off  0     30     1     
 Address: FE80::C000:2FF:FE97:0
 DR     : not elected
VoIP-Null0         off  0     30     1     
 Address: ::
 DR     : not elected
FastEthernet0/0    on   0     30     1     
 Address: FE80::C000:2FF:FE97:0
 DR     : this system
FastEthernet0/1    off  0     30     1     
 Address: ::
 DR     : not elected

Notice the PIM is indeed enabled on the Fa0/0 we have configured in this scenario. Now for the verification of MLD:

R0#show ipv6 mld interface
Tunnel0 is up, line protocol is up
 Internet address is FE80::C000:2FF:FE97:0/10
 MLD is disabled on interface
VoIP-Null0 is up, line protocol is up
 Internet address is ::/0
 MLD is disabled on interface
FastEthernet0/0 is up, line protocol is up
 Internet address is FE80::C000:2FF:FE97:0/10
 MLD is enabled on interface
 Current MLD version is 2
 MLD query interval is 125 seconds
 MLD querier timeout is 255 seconds
 MLD max query response time is 10 seconds
 Last member query response interval is 1 seconds
 MLD activity: 5 joins, 0 leaves
 MLD querying router is FE80::C000:2FF:FE97:0 (this system)
FastEthernet0/1 is administratively down, line protocol is down
 Internet address is ::/0
 MLD is disabled on interface

Internetwork Expert’s R&S Lab Workbook Volume IV Logs – Lab 6 of 10


Lab 6 Volume 4

by: CCIE Pilot

Ticket 1: EIGRP

The slower EIGRP link via the FR cloud been used. There is an optimal path via port-channel between SW3 and SW3 found to be down.

The fix of this issue is related to port-channel.

Per Etherchannel tunneling rules, you need to have a single separate VLAN for every pair or opposing channel links. Meaning, every VLAN are used : VLAN 100 and VLAN 101.

Make sure that each access-port is having unique vlan id towards the  port-channel interface.

interface FastEthernet0/17

switchport access vlan 100  (or 101 on the second link)

switchport mode dot1q-tunnel

l2protocol-tunnel cdp

l2protocol-tunnel point-to-point lacp

no cdp enable

spanning-tree bpdufilter enable

The effect is that EIGRP will prefer the faster link vial the etherchannel.

Show ether-channel summary

Ticket 2: Connectivity

Use bottom up approach, check Layer by layer.

Here you will discover some frame-relay map statement is misconfigured.

Easily correct the config.

For RIP running on an NBMA interface, make sure that split-horizon is disabled to encourage route propagation.

Show ip interface serial 0/0/0

Show frame map

Ticket 3:  BGP

In dealing with BGP make sure to clear out all lower layer issue.

In this case, the keepalive or essentially the LMI is turn-off effecting ckt to be brought down.

Watch also for IBGP route reflection issue. Make sure RR is enabled or used if you are not having a full mesh connection.

Show ip bgp neig

Sh run interface

Ticket 4: IPv6

This case is related to tunneling IPV6. This case uses 6to4 automatic tunneling.

Make sure the source IPv4 address is properly configured and reachable.

Check static route of 2002://16 towards the Tunnel interface.

Ping ipv6

Ticket 5: Multicast

Perform basic multicast topology analysis. PIM should be enabled on the path from R3 and R6. Check for tunnel and should run PIM also.

Watch out for RFP failures.

Static mroute command can be useful also.

Ticket 6: Core Dumps

Check reflexive access-list along the way. Passived FTP should be use under normal circumstances, else no data session will be established.

Active FTP will not bypass the packet filter.

Check correct configuration for the core dumps.

ip ftp username R6CORE

ip ftp password CISCO

exception core-file R6DUMP.txt

exception protocol ftp

exception dump 148.6.3.100

Ticket: 7: Time Synchronization

Make sure authentication key is configured properly and should be trusted.

Make sure ACL is correctly configured.

ntp authentication-key 1 md5 13263E212823 7

ntp authenticate

ntp trusted-key 1

ntp access-group peer 5

ntp master 5

ntp peer 148.6.57.7

ntp server 204.12.1.254 key 1 prefer

access-list 5 permit 127.127.7.1

access-list 5 permit 204.12.1.254

access-list 5 permit 148.6.57.7

show ntp ass

show ntp ?

Ticket 8: NAT

This case is about NAT as a load balancer.

The real servers at the back should be define as type rotary.

Secondly, the access-list specifying the traffic to the virtual server should be mirrored – it should match traffic from sources to the virtual server’s IP address.

ip nat pool POOL1 <start-ip> <end-ip> prefix-length> 24 type rotary

ip access-list ext SERVERS

permit tcp any host x.x.x.x eq www (or 8080 or 443)

Ticket 9: Server Access

For RIP make sure the distance is not set to 255.

Any underlying layer 2 filtering like vlan filter will effectively drop traffic also.

Make sure that RIP udp port is not filtered out.

Take away unnecessary servers if needed.

Show ip route rip

Show vlan filter

Ticket 10: Convergence

Make sure you don’t make unwanted configuration for dampening.

interface FastEthernet0/1

no dampening 30 1000 17956 125 restart 17956

Rack6R5(config-if)#dampening ?

<1-30>  Half-life time for the penalty

<cr>

Rack6R5(config-if)#dampening 30 ?

<1-20000>  Value to start reusing an interface

<cr>

Rack6R5(config-if)#dampening 30 1000 ?

<1-20000>  Value to start suppressing an interface

Rack6R5(config-if)#dampening 30 1000 17956 ?

<1-255>  Maximum duration to suppress an interface

Rack6R5(config-if)#dampening 30 1000 17956 125 ?

restart  Enable restart penalty

<cr>

Rack6R5(config-if)#dampening 30 1000 17956 125 restart ?

<1-20000>  Penalty applied at restart

<cr>

Rack6R5(config-if)#dampening 30 1000 17956 125 restart 17956

Internetwork Expert’s R&S Lab Workbook Volume IV Logs – Lab 5 of 10


Lab 5 Volume 4

Ticket 1: OSPF

-Case related to dot1q tunneling between 2 indirectly connected devices.

-Make sure the dot1q tunnel port has and access vlan assignment and l2protocol-tunnel allowed.

-Do the usual OSPF routine checking.

-This case is not actually related to OSPF.

Interface f0/x

switchport access vlan 100

switchport trunk encapsulation dot1q

switchport mode dot1q-tunnel

l2protocol-tunnel cdp

show cdp neighbor.

Ticket 2: OSPF

-Optimal path issue.

-Make sure in OSPF network NBMA type, the Hub router is has higher priority with the spoke router.

-Check Virtual links location and if working properly.

no ip ospf priority 0 (at the hub of course)

show ip ospf virtual-links

show ip ospf neighbor

Ticket 3:  BGP

-A reason of BGP router not receiving or dropping route advertisement is that AS path length limitation.

-Make sure AS path length configured properly. No limit by default.

%BGP-6-ASPATH: Long AS path 100 300 100 300 54 received from 204.12.1.6: More than configured MAXAS-LIMIT

router bgp 200

bgp maxas-limit 3

show ip bgp sum

clear ip bgp *

logging buffered

Ticket 4: IPv6

-The IPv6 router advertisement neighbor discovery helps the client IPV6 host in setting up its ipv6 address and default route.

ipv6 unicast-routing

interface FastEthernet0/0

ipv6 nd ra suppress <<-watch out for this!

show ipv6 interface

Ticket 5: MPLS VPN

-MPLS VPN via interface tunnel. Make sure tunnel source and destination ip address are reachable via global routing table.

-In EIGRP VPN, do not forget the AS number of the VPN address-family configuration.

show ip route vrf VPN_A eigrp

show ip eigrp neig

Ticket 6: MPLS VPN

-OSPF Sham links

-Make sure MPLS protocol is consistent either using TDP or LDP.

-Create a new loopback ip address on both PEs.

-Do not advertise the new loopbacks into OSPF but should be advertise via BGP or other protocol on the primary path.

-Make the OSPF area towards the backdoor as a sham.

-Increase OSPF cost at backdoor link to a high value.

sh ip ospf sham-links

show ip route vrf xxx

Ticket: 7: Multicast

-Watch out for PIM Stub routing feature.

-Both should be using DENSE mode, but the other side is filtering announcement using ip pim neighbor-filter command to avoid PIM neighborship between routers.

-To test do not forget the client router to run also pim DM/SM and use ip igmp-join group command.

-PIM SM and DM can combine on a multicast network.

-Identify the first hop router and next hop routers.

-Beware of RPF failures when dealing with multicast scenario.

-ip mroute x y z

-show ip pim interface x/x detail

-show ip pim interface

-show ip pim neighbor

Multicast Killer command:

sh run | i igmp|pim|mroute|multicast

Ticket 8: QoS

-Watch out for “Mr. 768” (that 768Kbps bandwidth), it means fragmentation is necessary and mandatory.

-For VOIP the recommended fragmentation size is = 768000 / 8  * .01 sec = 960 bytes.

To check Qos Fragmentation use:

Show frame-relay fragment

Configuration:

Frame-relay fragment 960 end-to-end (MQC compatible)

Else use map-class.

Ticket 9: Secure Access

-SSH Configuration Troubleshooting.

-Remember the 7 basic steps to a successful SSH server setup.

-Make sure routing is stable and the remote ssh server is ip reachable.

1. username and password

2. hostname

3. domain-name

4. crypto key generate rsa modulus

5. ip ssh version

6. line vty, transport input ssh – enable ssh as transport input.

7. line vty, login local

debug ip ssh

show line vty

ssh –l username –v 2 x.x.x.x

Ticket 10: Security

Dynamic ACL troubleshooting

-Make sure that username for the DYNACL has the autocommand access-host enable feature.

-Check AAA configuration and check AAA authorization – like

aaa authorization exec default local

-Watch out for the direction of ACL applied and the ACL config too.

-show run | i aaa

-show access-list

-debug aaa authentication

-debug aaa authorization

Expansion of Routing and Switching Lab v4.0 Blueprint


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

Internetwork Expert’s R&S Lab Workbook Volume IV Logs – Lab 4 of 10


10:24 PM 3/16-25/2010 HKT (Redo)

Trouble Ticket 1: RIPV 2

-Do not discount VLAN filter in trouble shooting IP connectivity.

-Use CDP, trace spanning tree for the VLAN in question.

-Logging should be on to console.

-Always verify after putting the configuration or fix.

-Use CDP

-Ping test using source.

-Test if related to any layer 2 issue. (VTP, STP, Trunking, Allowed VLAN,

Duplex/speed issue).

-Check direction of filter.

-Enable ICMP debugging.

-Enable logging buffered to flash.

Filtering can be performed by:

a. ACL

b. PBR

c. Policing

d. uRPF

e. Filters on VLAN

f. FPM – Flexible Packet Matching.

Trouble Ticket 2: BGP Prefixes

-For eBGP using loopbacks as source and destination IP address, do not forget the ebgp-multihop command to reconsider adjusting the TTL for BGP.

-For back to back frame relay using, no keepalive on each site will turn

off LMI and bring up the ckt. PVC will be on static state.

-In BGP make sure the next-hop ip address is reachable and good.

-BGP is on layer 4, means the layer below has to be up and running first.

show ip route <next hop ip>

show ip bgp regex ..

Trouble Ticket 3: OSPF

-OSPF database entries cannot be filtered out by distribute-list.

-An access-list of deny only needs to have explicit allow / permit entries at the bottom of the ACL.

-Check for route-maps used in redistribution. Make sure the prefix needed is allowed.

-Check also for ospf network types. Always check whos should be the DR and BDR, check if the state should not be all to DROTHER.

-For compatible network types of broadcast or non-broadcast, a DR must e xist on a segment.

-debug ip ospf packets

-debug ip ospf events

-debug ip ospf adj

-debug ip ospf hello

Trouble Ticket 4: IPv6

-IPv6 bgp neighbors, make sure it is activated.

-Ebgp does not change the next hop, if route entry for the p2p Ebgp link, you can use next-hop-self to change ebgp next hop.

-to verify: -ping destination using source lan interface local or a loopback local interface.

-show bgp ipv6 unicast summary

-show bgp ipv6

Trouble Ticket 5: OSPF

-OSPF – even the mtu is mismatched the OSPF neighbors can still go up if both priority for broadcast segment is set to 0. This is not a true OSPF neighborship, since it is DROTHER, they do not exchange DBD anyway.

-to fix this do one of the following options

1. changed system mtu for switch

2. ip mtu command on the interface

3. ip ospf mtu-ignore.

-A route can be on the OSPF database but cannot make it on the routing table due to filters. check for filters.

show ip ospf database

Trouble Ticket 6: BGP

-check bgp neighborship.

-dont forget to check the return path of the broken route.

-you may manually advertise via network statement, redistribution in bgp to the BB neighbor to have a return path back to the source.

-check using ping with an explicit source ip address.

-Do not forget Ebgp multihop or use TTL security hops.

show ip bgp summary

Trouble Ticket 7:  MPLS VPN

MPLS VPN troubleshooting:

-check MPLS speaking interfaces and relationships to its LDP neighbor.

show mpls interface

show mpls ldp neighbor

-check LFIB for labels generated by loopback, do this again later to verify.

show mpls forwarding-table x.x.x.x

where x.x.x.x. is the loopback ip address of the LDP neighbor.

-check local labels that every router generates for that loopback interfaces.

show mpls ldp binding local x.x.x.x NN

where NN = prefix length i.e. 24 for /24, 32 for /32 ,usually a /32.

-check mask and ip address.

show run int loopback

-check VPN routes and neighborship.

show bgp vpnv4 unicast all summary

-to check consistency of RT values.

show bgp vpnv4 unicast all x.x.x.x | i RT

show ip vrf detail | i RT

-do ping test using source ip address.

ping xxxx source yyyy.

-do debug VPNv4 updates

debug bgp vpnv4  unicast updates

clear bgp vpnv4 unica * soft out

show ip cef vrf VPN_A x.x.x.x

Trouble Ticket 8: BGP Peering

-L2 issue on the ethernet channel.

-Make sure mode are compatible.

-Then BGP in the L4 will follow.

show etherchannel summary

Trouble Ticket 9: EIGRP

-Authorised arp is enable

-added static arp entry on the router.

-alternative solution is to use DHCP for ip address assignment on the interface.

Trouble Ticket 10 – Netflow

-make sure to know the the direction of netflow.

-Netflow is enabled using MQC.

-Watch out for the access-list requirement and direction of flow.

-check running config.

-check doc cd for syntax.

Internetwork Expert’s R&S Lab Workbook Volume IV Logs – Lab 3 of 10


11:01 AM 3/7/2010 HKT

LAB 3 VOLUME 4 Notes:

Ticket 1 – RIPv2

• Fix the issue preventing R6 from learning RIPv2 prefixes from BB1.
• Do not change the IP addressing on R6 to resolve this problem.

-Know the scope of the problem.
-Check RIP running config first. Check interfaces running RIP.
-Check interface status up/down
-Check Layer 2 parameters, do ping test.
-PPP can be stuck in LCP exchange, check any authetication issue.
-This ticket is not directly related RIP but rather related to L2 PPP issue on the Serial link running RIP.
-Enable logging console and logging buffered

debug ppp negotiation – Look for “Authentication Failure” for hints.
show ip protocols
show ip route rip
show interface x/x
show frame-relay pvc yyy
show interface virtual-access x | i PPP|packets

Ticket 2 – BGP Peering

• The BGP session between R6 and SW2 is not coming up for some
reason.
• Find what might be causing this and fix the problem applying minimal
changes.

-BGP check – Remember BGP is a layer 4
-Underlying issue maybe related to switch trunking or any layer2 issue.
-Make sure the layer 2 is intact.
-Mark all access and trunk links.
-If using DTP (no switchport noneg) make sure VTP names and password are consistent, else trunks using DTP will not come up.
-Checking of logs is very critical, make sure to familiarized log checking.
-This case is not directly related to any BGP process or layer 4 issue, but rather some layer 2 trunking issue.
-Check BGP decent running config.

show spanntree vlan xxx
show interface fx/x switchport | i Mode
show vtp status
show ip bgp summary.

Ticket 3 – Backup Link

• Users on VLAN42 report terrible performance when connecting the
servers on VLAN5.
• You suspect that the problem is that packets are taking suboptimal path across the backup ISDN link between the two sites.
• Restore optimal performance and ensure the primary path over Frame-Relay cloud is being used.

-This setup is a dual link via Serial p2p and Serial frame-relay ckt.
-FR is down. Check for FR configuration, proper DLCI assignment.
-Check EEK.
-Check OSPF neighbor
-EEK is applied via a map-class, make sure it is consisted on both ends.

debug interface xx
debug ip ospf adj
show ip protocols
show interface xx | i LMI
show frame pvc xxx | s UNUSED
show frame-relay pvc | i DELETED

Ticket 4 – Network Optimization

This ticket requires Tickets 1 and 2 resolved prior to starting.
• After a recent merge process, some networks have been joined together.
• In order to provide end-to-end connectivity, mutual redistribution has been configured between RIP and OSPF on R1, R2, R3, R4 and SW1.
• However, the straight-forward configuration approach resulted in network instabilities and sub-optimal routing.
• Fix the network configuration to ensure optimal routing, which means
using high-speed links (Ethernet and Frame-Relay) for primary data paths.
• The routers behind R5 should receive a single default route to reach the rest of the network.
• R4 may still use the Serial link to reach the networks behind R5.

-Redistribution issue.
A. layout 1

RIP-R2–OSPF—-R1—–OSPF—-R3—
|        |
|__RIP-SW2-RIP__|

Beware of layout 1 when doing mutual redistribution  on all router involved (R1, R2, R3,SW2). The ospf and RIP domain will by default will looped back.

N: At R2 make rip distance lesser than OSPF (e.g. distance 109 – router rip)

B. Redistribution troubleshooting technique.

-Shut down some interfaces to make the topology simple. Check whether you can get expected routes from the neighboring routers.
-Check for filtering in or out direction on the 1. interface, routing process.
-Alternative to bumping up AD of OSPF versus RIP, you can bump down RIP AD targeting only from a specific neighbor.

e.g.

router rip
distance 109 x.x.x.x 0.0.0.0
x.x.x.x is the neighbor.

-this makes routes from neighbor x.x.x.x to have a better distance learned from OSPF.

or it is usually like this:

router ospf 1
distance ospf external 121
! or
distance 110 x.x.x.x 0.0.0.0
! or
router ospf 1
redistribute rip metric 10000 subnets <<<<<<<makes sure the the redistributed routes to OSPF has a worse metric.

General Rule in Redistribution:

1. Native prefixes for one protocol should be reached via this protocol, can have the best metric against others.
2. External prefixes should have AD that is worse than the  AD of the native prefixes from different protocol.
3. When injecting external information into a protocol, assign it a high metric value to make is less preferred.
4. You can safely generate default route for stub domains but watch out and do filter of this default if needed.

Redistribution commandments notes:

1. ospf to eigrp -> 110 to 170 -> ok
2. eigrp to ospf->  90 to 110 -> ok
3. eigrp(external) to ospf -> 170 to 110 <<<– problem here, not ok, watch out!
4. lower AD wins

TECHNIQUES:

1. route tagging
2. route summarization
3. distance

To the following with redistributing:

1. Check first all native routes per router.
2. Check all external routes per protocol type, perrouter.
3. Think of the redistribution commandments.
4. Can make ospf acts like EIGRP on dealing with external prefixes. (distance ospf external 171)
5. Bump up or bump down certain prefixes. (external or internal).
6. The distance of external EIGRP cannot be changed on a per prefix basis.
7. ping the destination using the source IP address interface on different network
8. debug ip packet detail with an ACL (ACL is permit icmp from any to any or host)
9. Adjust default AD of IGP. RIP->109, OSPF= 121, OSPF External = 171, ospf = 89, depends on the situation and requirments.

Watchout on the following with redistributing.

1. route feedback.
2. manually tag the route with higher AD with put into the redistributed towards the lower AD.
3. lockdown pre-redistribution externals to equal to the native AD (e.g. distance 110 0.0.0.0 255.255.255.255  ACL_EXTERNAL_ALREADY
4. The rest of new routes coming is can be bump up (distance ospf external 171)
5. Item 3,4 are OSPF and EIGRP samples.

-debug ip routing
-show ip route xxx
-show ip rip data
-show ip ospf topology

Ticket 5 – Server Farm

• Two new servers have been recently connected to SW1 port 0/18 and SW2 port 0/19 respectively.
• For the lab purpose, the servers are emulated by L3 ports in SW3 and SW4 respectively.
• The following is the configuration policy for the server block:
o The new servers are assigned to the subnet 192.10.X.0/24
o To ensure security, the servers should not be able to communicate directly.
o The servers should be able to reach and communicate via R4.
• However, the configuration appears to be incomplete, as servers cannot reach to each other.
• Ensure the connectivity via R4 and verify it by using IP addresses assigned to the switchports of SW3 and SW4.

-This case is related to private vlan configurations.

show interface f0/x switchport | i private-vlan
show interface trunk
show vlan id
show ip interface f0/xx | i arp

Ticket 6 – BGP

• AS254 and AS54 cannot exchange routes across AS 100, AS 200 and AS 300.
• Applying changes to BGP configurations only, restore the end-to-end connectivity.
• Do not apply any changes to AS 300 routers to accomplish this.
• The ticked will be resolved when AS 54 and AS 254 could see each other’s routes.

-External BGP loop prevention mechanism uses AS-PATH information.
-The use local-as on the source AS will generate the AS path information.
-Use allowas-in on the far receiving end
-Make user no other L2/L3 issue exist. IGP should be stable at this time. No routing loops occured.
-Check for IBGP relationships and watch out for route-refrelector requirments.

show ip bgp regexp _
show ip bgp neig xxx advertise-routes
show ip bgp sum
show ip bgp neig | i state|neighbor|index|update-group|reflec
show ip bgp update-group

Ticket 7 – L2VPN

• You have tasked a junior system administrator to configure an L2VPN tunnel between VLAN64 and VLAN46 interfaces of R6 and R4.
• Some time after this, he reported that the configuration has been done, but there are some issues preventing it from working properly.
• Find and resolve the issues preventing the Layer 2 VPN tunnel from coming up.

-Watch out for inconsistend ckt id name. Ckt id should be the same on both ends.

show vpdn tunnel
show vpdn session
show l2tun session all
show sss circuits

Ticket 8 – L2VPN Issues

• The Frame-Relay connection between R1 and R2 has been recently replaced with L2 VPN. Soon after this, users on VLAN263 started complaining that they cannot download files from the servers on VLAN42.
• They still could use telnet and ssh to access the servers though.
• Suspecting that this may be caused by Path MTU discovery failures, you configured a workaround by clearing DF bit on all TCP packets received by R2 on its VLAN263 interface.
• However, this does not seem to help and the problem persists. Find the solution to this problem that works for all types of network traffic.

-Do ping test with oversized packet to check fragmentation issues.
-Fragments per packet is controlled by VFR – ip virtual-reassembly max-fragments x command.
-Using ip tcp adjust-mss will keep the router to modify and MSS field in TCP packet header.  MSS is 40 bytes less than the MTU. Only for TCP.
-IP virtual-reassembly, use to set max amount of fragmented packets

There are basically few ways to filter fragmented packets:
1) Using an access-group applied to an interface.
2) Using a policy-map that routes fragmented traffic to Null0.
3) Using a service-policy that drops fragments.
4) Configuring IP virtual-reassembly on interface.
5) Using IOS IPS to drop fragmented traffic.
6) Using CoPPr or Control-Plane policing to restrict packets going to the router.

show ip virtual-reassembly | i Fragments
show ip int xx | i list
show ip ips all
show ip policy

Ticket 9 – NTP

• You have recently re-loaded the configuration for R3 and R4 using the backup copies and soon after that discovered the logging timestamps went wrong.
• You know that NTP has been used for time synchronization on R3 and R4.
• R5 was supposed to be the NTP master for R3 and R4.
• You may assume that R5 is configured correctly and fix the issues in R3 and R4.

-NTP key should match on Server and client.
-Use key chain to decrypt md5 hash on same router.
-if the master NTP server is using ACLS on the peers and clients make sure the clients and peers are allowed on the ACL. Make sure NTP source is allowed.
-NTP authentications need to do “ntp authenticate” command
-NTP key should be manually trusted.

show ntp status
show ntp ass detail

Ticket 10 – Internet Access

• After the recent security policy changes users on VLAN5 started complaining they cannot reach YouTube videos anymore.
• Asking a few questions you found that uses cannot access any other WWW sites as well.
• After a short investigation you found that the uplink used to reach the YouTube website is via BB1.
• Talking to the users you found that only HTTP is being affected, FTP downloads work well.
• Applying minimal changes to the network configuration resolve this problem and restore WWW connectivity.

-Related to WWW access only. Described that FTP traffic is not affected.
-Not Path MTU issue.
-Watch out for TOS value is matched and on the route-map is set to drop it to null0 interface.
-The DF bit can be cleared using route-map. set ip df 0.

-Check MTU issue
-Check local policy-map
-Check ip ips
-Check route-maps applied to the interface, make sure it is not dropping it.
-enable http server on each router as a test to web traffic.

ip http server
ip http path flash:
copy http://x.x.x.x/test null:
sho ip policy
show ip ips all
show ip int virtual-access x | i access

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


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


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


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


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


  • 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


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


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


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


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


* 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.


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)


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?


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.


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