a monster...

rrrrrrrrrrrrrrrrrr...

look at this thing... it uses nm-esw16's of course...

you can find it here... there's 20 labs there...

http://certcana.ca/tshoot/

it'll peg your cpu's, count on it... but if you adjust the topology.net file with known good idle values, you'll be ok...

it's very exciting...

unfortunately, i can't suffer the behavior of the routers as switches... and since i have 3560's, i'm not interested... have fun with that...

halabi bgp cont...

it's paint by numbers...

rtc(config)#router bgp 1
rtc(config-router)#neigh 172.16.20.2 remote-as 3
rtc(config-router)#
*Jan 30 11:58:39: %BGP-5-ADJCHANGE: neighbor 172.16.20.2 Up
rtc(config-router)#end
rtc#
*Jan 30 11:58:51: %SYS-5-CONFIG_I: Configured from console by console
rtc#sh tcp brie all
TCB       Local Address               Foreign Address             (state)
67F17354  172.16.20.1.179             172.16.20.2.63717            ESTAB
68636BC8  0.0.0.0.179                 172.16.20.2.*                LISTEN

i do love that show tcp brief all command...

i hate when i'm an idiot, but i'm used to it... he gives no config for rte, he just states in the topology that it doesn't have bgp...

here is the rtd config:

rtd#sh run | b router
router ospf 10
 network 192.68.0.0 0.0.255.255 area 0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 192.68.5.1 remote-as 3
 neighbor 192.68.5.1 ebgp-multihop 2

so i configured rte thus...

rte#sh run int s1/0
Building configuration...

Current configuration : 88 bytes
!
interface Serial1/0
 ip address 192.68.5.2 255.255.255.0
 serial restart-delay 0
end

rte#sh run int s1/1
Building configuration...

Current configuration : 89 bytes
!
interface Serial1/1
 ip address 192.68.12.2 255.255.255.0
 serial restart-delay 0
end

rte#sh run | b router
router ospf 1
 network 192.68.0.0 0.0.255.255 area 0

this is shalabi's output... look closely...

RTF#show ip bgp neighbor
 BGP neighbor is 172.16.2.254, remote AS 3, internal link
 BGP version 4, remote router ID 172.16.2.254
 BGP state = Established, table version = 2, up for 22:36:09

 BGP neighbor is 192.68.12.1, remote AS 2, external link
 BGP version 4, remote router ID 192.68.5.2
 BGP state = Established, table version = 2, up for 22:13:01

not sure how that can be... he explicitly states that rte is not running bgp... 192.68.5.2 is the other side of rtf's serial connection... i stand by my configuration...

rtf#sh ip bgp neigh | i BGP
BGP neighbor is 172.16.2.254,  remote AS 3, internal link
  BGP version 4, remote router ID 172.16.2.254
  BGP state = Established, up for 00:43:01
  BGP table version 1, neighbor version 1/0
 
BGP neighbor is 192.68.12.1,  remote AS 2, external link
  BGP version 4, remote router ID 192.68.12.1
  BGP state = Established, up for 00:10:12
  BGP table version 1, neighbor version 1/0
  Last reset 00:12:29, due to BGP protocol initialization
  External BGP neighbor may be up to 2 hops away.

somebody's lying to somebody here...

then he writes:

RTF's other neighbor 192.68.12.1 is also in an established state. This external neighbor belongs to AS2. Note that the display indicates that this neighbor is two hops away (as configured in the ebgp-multihop).

which confirms my configuration...

halabi bgp...

this is nice... note 192.68... finally configuration starts at chapter 11... you gotta pay to play...

he starts off slow...  it's like being brand new again...

rta#sh run | b router
router ospf 10
 network 172.16.0.0 0.0.255.255 area 0
!
router bgp 3
 bgp log-neighbor-changes
 neighbor 172.16.1.2 remote-as 3
 neighbor 172.16.1.2 update-source Loopback0
 neighbor 172.16.20.1 remote-as 1
!

he mentions turning on ip classless and no auto-summary... somebody forgot to tell him it's not 2000 anymore... this is a very good book... it would be nice if they revised it, like doyle did for routing tcpip...

i'll give his line by line of the pertinent commands, unless of course, you already know everything...

router process
[process-id]

This is a global command that defines a process such as OSPF, RIP, or
BGP and gives the process a process ID. Some processes, such as RIP,
do not require a process ID. For example, in RTA's configuration,
router ospf 10 indicates an OSPF process with ID 10, whereas router
bgp 3 indicates a BGP process in autonomous system 3.


network 

This command indicates the networks or, in the case of OSPF, the
interfaces that will participate in a specific routing process.

etc...

rtf#sh run | b router
router ospf 10
 network 172.16.0.0 0.0.255.255 area 0
 network 192.68.0.0 0.0.255.255 area 0
!
router bgp 3
 bgp log-neighbor-changes
 neighbor 172.16.2.254 remote-as 3
 neighbor 192.68.12.1 remote-as 2
 neighbor 192.68.12.1 ebgp-multihop 2

rtf#sh tcp brie all
TCB       Local Address               Foreign Address             (state)
695BAA54  172.16.1.2.179              172.16.2.254.60797           ESTAB
6874F178  0.0.0.0.179                 192.68.12.1.*                LISTEN
695B979C  0.0.0.0.179                 172.16.2.254.*               LISTEN

rtf#sh ip bgp neigh | i BGP
BGP neighbor is 172.16.2.254,  remote AS 3, internal link
  BGP version 4, remote router ID 172.16.2.254
  BGP state = Established, up for 00:04:04
  BGP table version 1, neighbor version 1/0
BGP neighbor is 192.68.12.1,  remote AS 2, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Idle
  BGP table version 1, neighbor version 1/0
  External BGP neighbor may be up to 2 hops away.

note rte isn't lit up yet... there is no configuration in the book...


In RTF's configuration, you can see the ebgp-multihop 2 command being used as part of the neighbor configuration. This indicates that the exterior BGP peer is not directly connected and can be reached at a maximum of two hops away. Remember that ebgp-multihop is applicable with only EBGP, not IBGP. Also, the value at the end (2 in this example) represents the TTL (Time To Live) value to be configured in the IP packet header.

quote of the day... halabi speaks...

this is a nice quote... this guy writes well...

Redundancy is achieved by providing multiple alternative paths for the traffic, usually by having multiple connections to one or more ASs. Symmetry means having traffic that leaves the AS from a certain exit point return through the same point. Load balancing is the capability to divide traffic optimally over multiple links. Putting these three requirements together, you can imagine how challenging it is to achieve an optimal routing solution.

bgp origin...

routes that were learned via redistribution will give you an origin code of ? or incomplete... learned from a source other than igp...

routes learned through an igp will give you an origin code of "i" as below... these things we know...

isp#sh ip bgp | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   172.16.0.0       192.168.1.6              0             0 64512 i
 *>                   192.168.1.2              0             0 64512 i
 *>  192.168.1.0/30   0.0.0.0                  0         32768 i
 *>  192.168.1.4/30   0.0.0.0                  0         32768 i
 *>  192.168.100.0    0.0.0.0                  0         32768 i

look ma, no routes learned through redistribution...

if you receive routes with an origin code of "e" then immediately check yourself into the EGP mental ward because you're seeing things...

however, a redistributed route that has been defined as a network in bgp, ie, network 10.1.1.0 mask 255.255.255.0, will still have as it's origin "i", not "?", even though it has been redistributed...

lay it on them habibi:

Although network X has been injected into BGP via explicit redistribution of static routes, it is also defined natively to BGP via the network command, which is why it is sent out with an ORIGIN of IGP(i). If network X had not been defined with a static network command, it would have been sent out with an ORIGIN of INCOMPLETE. It should be noted that network X did not need to be redistributed because defining it statically and listing it via the network command would suffice to inject it into BGP.

bgp capabilities...

have at it... as if there wasn't enough already... this is borderline trivia...

https://tools.ietf.org/html/rfc5492

This specification defines an Optional Parameter and processing rules
   that allow BGP speakers to communicate capabilities in an OPEN
   message.  A pair of BGP speakers that supports this specification can
   establish the peering even when presented with unrecognized
   capabilities, so long as all capabilities required to support the
   peering are supported.

which means they're not a peer breaker...

note: route refresh appears as a capability in an open message, but it is also a message, type 5...

open, update, notification, keepalive and route refresh. in numerical order by type...

bgp update...

as-path, origin and next hop are well known transitive... it has to be true, it says so right in the update packet...

bgp messages...

nothing groundbreaking here...

1 open, 2 update, 3 notification 4 keepalive... and 5 route refresh (introduced in 2000, after halabi went to the presses:

 http://tools.ietf.org/html/rfc2918

null0 default bgp...

the following example is from r2 in the last tshoot lab 10...  the routing is static... pay particular attention to the default route, and the advertised network in bgp... r2 below in the lab represents the isp:

R2#sh run | b router
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 0.0.0.0
 neighbor 192.168.1.1 remote-as 65501
 neighbor 192.168.1.1 ebgp-multihop 2
 neighbor 192.168.1.1 update-source Loopback0
 no auto-summary!
ip route 0.0.0.0 0.0.0.0 Null0
ip route 10.1.0.0 255.255.0.0 209.165.200.225
ip route 192.168.1.1 255.255.255.255 209.165.200.225

on r1, the customer (enterprise), all 0's is the advertised bgp network... 10.1.0.0 is the internal enterprise network... r1's 192.168.1.1 is connected to 192.168.2.1...

R1#sh tcp brie all
TCB       Local Address           Foreign Address        (state)
84D5CF00  192.168.1.1.32348       192.168.2.1.179        ESTAB


R1#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          192.168.2.1              0             0 65502 i

the effectiveness of the default to null0 in conjunction with the statics is clearly shown here... of course within the confines of the lab it is meaningless but we have our imagination hats on, correct? 

from doyle:

Configuring a Default Route to BGP Neighbors
router bgp 100
network 0.0.0.0
neighbor 192.168.1.210 remote-as 300
neighbor 192.168.1.222 remote-as 100
neighbor 192.168.1.225 remote-as 200
!
ip route 0.0.0.0 0.0.0.0 Null0
 
A default route to the Null0 interface is created statically, and the route is advertised with the network command...

 any destination address that cannot be matched to a more-specific route matches the static route and is dropped.

from halabi:

Less-Specific Routes of a Network’s Own Aggregate

A specific rule of routing states that, for the sake of preventing routing loops, a network must not follow a less-specific route for a destination that matches one of its own aggregated routes. A routing loop occurs when traffic circles back and forth between network elements, never reaching its final destination. Default routes 0.0.0.0/0 are a special case of this rule. A network should not follow the default route to reach destinations that are part of its aggregated advertisements. This is why routing protocols that handle aggregation of routes should always keep a bit bucket (Null0 route in Cisco parlance) to the aggregate route itself. Traffic sent to the bit bucket will be discarded, which prevents
potential looping situations.

this is wildly important...

quote of the day, mem halabi...

of course the first fifty pages of this book is dedicated to internet acronyms like rir, arin, iana, and internet history in general, which i actually enjoy because it is a timeline of various stages of my networking career... 

and the next fifty pages is devoted to addressing, which gets old but i always suffer through in case of the occasional curve ball... rare...

thankfully, vlsm was minimal; i half expected a class on subnetting like you get with the ccie cert guide from wendell where he goes into binary for quite a few pages (WENDELL!!)... yuck... if you survived ccna and are still not using minus 256, or God forbid, a calculator at least, go get your damn head examined...

this thing is actually a good read by the way...

(the) terms aggregate, CIDR block, and supernet are often used interchangeably. Generally, these terms all indicate that a group of contiguous IP networks has been summarized into one route announcement. More precisely, CIDR is represented by the notation, supernets have a prefix length
shorter than the natural mask, and aggregates represent any summary route.

and the above has NOTHING TO DO WITH VLSM on your nasty little enterprise network...

good, we can relax now...

time for halabi...

it never stops... i've mentioned it before, i like to buy my books as pdf from cisco press because in the event of disaster, your account is also your library... they also watermark your pdf's with your name... that's probably a better security feature for them than any other...

it's old, but the word is, it's a must read... it's what we do...

if they are less than 500 pages, it's like a gift...

ccie and switch...

it's right here... all of it... don't tell anybody...

and you can download the whole damn pdf for your very own... the contents page is basically a blueprint map for switch on the ccie lab... shhhhhhhhhhhhh...

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_55_se/configuration/guide/3750escg.html

deepak aurora...

i've seen this guy posting on the INE ccie forums...  here's a link to his stuff... he passed the lab about a year or so ago...

http://deepakarora1984.blogspot.com/2010/03/ccie-r-switching-study-plan.html

he has some interesting ideas about switch prep for ccie...

his first idea about reading hucaby (again, anyway) is the first idea i'd reject flat... yes i read it and yes i don't recommend it (of course if you haven't passed switch yet, you MUST read it)... i thought his switch book was abyssmal, but you still have to go through it... paul browning would be my recommendation there, and absolutely, the ccnp net acad switch lab manual... and better still, you must download the complete pdf from the cisco doccd for 3560/3750 switch... if you have to ask where the location of the doccd is, please just go away now...

here is his list of links on switch...

http://www.cciecandidate.com/?p=490



note; my view on fallback bridging here:
tp://insearchofthecert.blogspot.com/2012/04/fallback-bridging.html

http://blog.ipexpert.com/l2-tunneling/

http://blog.ipexpert.com/explaining-etherchannel/


http://blog.ipexpert.com/old-ccie-myths-storm-control/

http://blog.ipexpert.com/2010/04/07/old-ccie-myths-vtp/

http://blog.ipexpert.com/2010/07/12/etherchannel-over-dot1q-tunnels/

http://blog.ine.com/2009/02/04/solving-for-the-physical-topology-using-a-logical-topology/

http://blog.ine.com/2008/02/05/turning-switch-into-hub/

http://blog.ine.com/2008/07/05/udld-modes-of-operation/

http://blog.ine.com/2008/07/14/private-vlans-revisited/

http://blog.ine.com/2008/01/31/understanding-private-vlans/

http://blog.ine.com/2008/07/08/8023x-flow-control/

http://blog.ipexpert.com/private-vlans/

http://blog.ine.com/2008/07/08/8023x-flow-control/

http://blog.ine.com/2008/07/17/pvst-explained/

http://blog.ine.com/2008/07/27/mstp-tutorial-part-i-inside-a-region/

http://blog.ine.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/

http://blog.ine.com/2010/02/22/understanding-mstp/

http://blog.ine.com/2009/03/07/understanding-stp-convergence-part-i/

http://blog.ine.com/2009/03/14/understanding-stp-conv-2/

http://blog.ine.com/2009/09/07/rstp-and-fast-convergence/

http://blog.ine.com/2009/08/10/vlan-access-control-lists-vacls-tiers-1/

http://blog.ine.com/2010/01/07/ccie-l2-security-a-frame-of-reference/
 

http://blog.ipexpert.com/spanning-tree-direct-vs-indirect-link-failures/

http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/

yeah it's a lot of work... just shut up and do it... waaaahhh

guster in the box...

 and michael jackson...

he is the king of the forrest...

jeff doyle and bgp fsm...

this gives me brain flotsam... jeff doyle had igor whiteboard this mess... sorry dr. frankenstein, but the absurdity of it will make us look smarter than them...

the above is for Will Hunting...  jeff,  that's a swing and a miss for the human's on the planet...


below, is for the outpatients...

you can follow this one... see the excellent link for more...

http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/operation/finite_state_model.shtml

R3# sh ip bgp neigh 1.1.1.1
BGP neighbor is 1.1.1.1,  remote AS 123, internal link
  BGP version 4, remote router ID 1.1.1.1
  BGP state = Established, up for 01:05:12

quote of the day... netcerts.net...

bgp... live it, breathe it, hate it...

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

this guy, amit, belongs in your bookmarks... bookmark him NOW...

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

repetition makes the heart grow fonder... arghh... of course there are a million little rules for bgp because you have to do everything for it... it should be called a no-routing protocol... 

it's articles like his that speak to how far you have to go... the never ending story...

radix tree redux...

i forgot to remember that i passed the 800 post marker this morning...

i noticed some of you looking at this old post about radix trees...

http://insearchofthecert.blogspot.com/2012/09/radix-tree.html

when i bumped into mtrie the other day digging into cef i thought of resurrecting it, but then went onto something else...

however:
http://www.google.com/patents/US7149216

a trie data structure is used to map a multicast packet header by a sequence of nodes that match on destination address or source address.

or

A device for switching packets at high speed. For each packet, the A device matches packet data with protocols, to determine how to switch the packet.

Inventor: David R. Cheriton
Original Assignee: Cisco Technology, Inc. 


cisco has quite a storied history of patents with this...

and yet another book i should read one day:
http://books.google.com/books?id=IDmpiQd5FwwC&pg=PA60&lpg=PA60&dq=mtrie+cisco&source=bl&ots=q6uuTZMdWE&sig=RrpCrfEfMZJOmPcO8CiQKFAQwCQ&hl=en&sa=X&ei=VHICUYvFL6LC0QG4-4C4BQ&ved=0CEMQ6AEwAQ#v=onepage&q=mtrie%20cisco&f=false

max-metric router-lsa on-startup wait-for-bgp...

o yeah, it's real, you should say something...

an infinite cost can be advertised by an ospf transit router until bgp comes up...

benefit:  http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800ade18.shtml

• Graceful removal of an OSPF router from networks (i.e. to upgrade software or to perform maintenance) and reduction in packet drop
  
  
• Reduce black-hole packet dropping when interacting with BGP

makes a transit router a stub router without making it a stub router...

this is very exciting...

It can be desirable to have a router in a network that is not a transit router. A "transit router" forwards traffic that is not destined for networks directly connected to the router. A router that only forwards packets destined to its directly connected links is known as a "stub router". In OSPF networks, a router could become a stub router by advertising large metrics for its connected links, so that the cost of a path through this router becomes larger than that of an alternative path. It does not matter what specific metrics are advertised in a stub network that is connected to the router, because data must reach the network via the stub router itself.

and you thought it was safe to go back in the water...

infinity is 16,777,215 in ospf...

that's 2^24 = 16,777,216

this is better than coffee first thing in the morning...

quote of the day... ospf auth...

you have been warned...

NOTE 
OSPF authentication is a good place for tricky CCIE lab questions—ones that can be solved in a few minutes if you know all the intricacies.

of course...  authentication can create havoc with routing protocols... and yes, the configuration for eigrp, ospf and bgp are unique to each routing protocol...

so what's the plan... you hate it so much that you love it... like frame relay, dtp, vtp, or whatever your particular hateful protocol might be...

bring the hate and you will find the love...

the devil's in the details, baby...

ccie... concentrate...

this is a companion to an earlier post...

i've heard complaints about wendell's cert guide for ccie r&s... regardless of the complaints it is a must read... end of story there...

it is very long but so is this adventure... by contrast the ccie quick reference is only 250 pages... i have to laugh as i look at that... quick ref, only 250 pages, there's some irony in that...

here's the thing; yeah i'm gonna tell you the thing... this stuff is not meant to be read like normal human's would read...  you have to dissect this shit with a microscope...

here's an example:

i have read various articles about the elusive lsa type 4, and i'm pretty sure i have a good handle on that one... elaborate articles, with configuration examples, output, all that...

if you are simply reading, which means, looking, you will miss this:

When an ABR then floods the type 5 LSA into another area, the ABR creates a type 4 LSA, listing the ABR’s metric to reach the ASBR that created the type 5 LSA.

it is frightening how you can convince yourself you got it when you read it when in fact you missed the whole thing...

the ABR creates a type 4 LSA, listing the ABR’s metric to reach the ASBR that created the type 5 LSA.

now that's the thing 

the ABR creates a type 4 LSA, listing the ABR’s metric to reach the ASBR that created the type 5 LSA.

the ABR creates a type 4 LSA, listing the ABR’s metric to reach the ASBR that created the type 5 LSA.  

quote of the day... odom

wendell, you have the floor:

Neighbors—Two routers that share a common data link, that exchange Hello messages, and the Hellos must match for certain parameters.


Adjacent (fully adjacent)—Two neighbors that have completed the process of fully exchanging DD and LSU packets directly between each other.

and further (this is the big one)

if a DR is elected, the election occurs after the routers have become
neighbors, but before they send DD packets and reach the ExStart neighbor state. When an OSPF router reaches the 2-way state with the first neighbor on an interface, it has already received at least one Hello from that neighbor.

translation:

after neighbors but before adjacency:

hellos begin at init...

two-way is established upon hello reception NEIGHBORS

exstart determines master/slave

exchange (exchange dd)

loading compare dd... bring lsa's up to speed with lsr's... ACKNOWLEDGE

full = synchronization

eigrp/ospf packet types...

R3#sh ip eigrp traff
IP-EIGRP Traffic Statistics for AS 1
  Hellos sent/received: 55475/55473
  Updates sent/received: 26/29
  Queries sent/received: 3/0
  Replies sent/received: 0/1
  Acks sent/received: 13/17
  Input queue high water mark 2, 0 drops
  SIA-Queries sent/received: 0/0
  SIA-Replies sent/received: 0/0


DLS2#sh ip ospf traff

OSPF statistics:
  Rcvd: 50040 total, 0 checksum errors
        47851 hello, 35 database desc, 8 link state req
        979 link state updates, 1167 link state acks

  Sent: 53573 total
        50795 hello, 49 database desc, 8 link state req
        2154 link state updates, 570 link state acks



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

OSPF queue statistics for process ID 1:

                   InputQ     UpdateQ    OutputQ
  Limit            0          200        0        
  Drops            0          0          0        
  Max delay [msec] 17         210        0        
  Max size         3          3          2        
    Invalid        0          0          0        
    Hello          0          0          1        
    DB des         1          1          1        
    LS req         1          1          0        
    LS upd         1          1          0        
    LS ack         0          0          0   


and let's not forget bgp messaging

1	OPEN message	Used to open BGP sessions
2	UPDATE message	Carries route updates for established BGP sessions
3	NOTIFICATION   message	Notifies a peer router of an error condition
4	KEEPALIVE message	Sent between BGP peering routers to verify BGP session
5	ROUTE-REFRESH message	An optional message (negotiated during capability advertisement) that is sent to request dynamic BGP route updates from the Adj-RIB-Out table of a remote BGP speaker

eigrp rtp...

this one never goes away...

http://insearchofthecert.blogspot.com/2012/11/rtp-in-eigrp.html

In order to ensure that routing updates and queries are not lost, we need a way to make certain other routers have received these multicast packets intact and to recover from errors if they haven’t. For these reasons, updates and queries are handled by the reliable multicast transport in EIGRP.

like ospf, eigrp uses a protocol, 88 (ospf uses 89) and unlike bgp which uses tcp port 179...

these numbers are often referred to as ports in ospf and eigrp... they are protocols, not tcp or udp ports...

then of course, wendell has his say...

 RTP allows the Updates to be sent as multicasts. If any neighbors fail to acknowledge receipt of the multicasted update, RTP resends Updates as unicasts just to those neighbors.

this is a fine point, but russ and wendell appear to be agreeing here; differently...

 http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

you will authenticate everything...

it's one of those things you just have to suck up...  authenticate everything...

you can't fight it... can't afford to take a hit on something like that in time pressure...

the above video is a work of art...

md5 is the only authentication type available for eigrp... but don't trust me... put your faith in the doccd...

but arteq, why on earth then does md5 need to be specified in the configuration command...

right.........................................................................................................................

gre tunnel config...

in the ccie r&s cert guide wendell uses a configuration example whereby the source is a source interface, and the destination is an ip address... i can't imagine that this is some kind of best practice situation... at the end of this chapter he restates the configuration commands where again, the source for the tunnel is an interface, ie, loopback 0 (as if there are no other choices, see below), and the destination is an ip address...  i'm not clear why he is insistent on this point...

perhaps you save some typing, i don't know...  i like to always use an ip address for both source and destination... 

these are the facts...

DLS1(config-if)#tunn source ?
  A.B.C.D            ip address
  Async              Async interface
  Auto-Template      Auto-Template interface
  BVI                Bridge-Group Virtual Interface
  CTunnel            CTunnel interface
  Dialer             Dialer interface
  FastEthernet       FastEthernet IEEE 802.3
  Filter             Filter interface
  Filtergroup        Filter Group interface
  GigabitEthernet    GigabitEthernet IEEE 802.3z
  GroupVI            Group Virtual interface
  Lex                Lex interface
  Loopback           Loopback interface
  Null               Null interface
  Port-channel       Ethernet Channel of interfaces
  Portgroup          Portgroup interface
  Pos-channel        POS Channel of interfaces
  Tunnel             Tunnel interface
  Vif                PGM Multicast Host interface
  Virtual-Template   Virtual Template interface
  Virtual-TokenRing  Virtual TokenRing
  Vlan               Catalyst Vlans
  X:X:X:X::X         IPv6 address
  fcpa               Fiber Channel

so given a configuration task would it be incorrect if the question stated "use the loopback" as the tunnel source, and you used the ip address of the loopback instead...

for me they are equivalent...

classful, classless and default routing...

a whiter shade of pale...

does it ever piss you off that you know, or are supposed to know some of these ridiculous distinctions...

for instance, you know the difference between classful and classless... one has it's basis in the iron age and the other is the modern day default... the age of vlsm has made classful routing completely irrelevant...

with classless routing if there is not a prefix match in the routing table, the default route will be used... that's very nice... can you say gateway of last resort...

with classful routing, if the classful network does not exist in the routing table, the default route will be used... good, however, if any part of that classful network exists in the routing table, and the route doesn't match a subnet in that classful network, the default route will not be used; the packet will be dropped...

so much for the default friggin route in classful routing...

i'm very sorry i know this...

quest...

if you've come here looking for answers, you took a wrong turn in albuquerque...

there are no answers here, just more questions...

this is a quest, and the red knight lurks at every corner to slaughter you...

the answer you seek is in the mirror...

just ask Cord the Seeker...

kim ninja...

he's definitely worth a look...

http://noc-ninja.com/2013/01/

he's correct when he says it takes "balls of steel" to attempt this...  someone somewhere once said this is a marathon... it is...

i'm still delighted and impressed with the net academy lab manual... i went through a lot of pain to make the manual and the labs work for me, and they did to the nth degree... i don't give a shit if you're sick of hearing it; go somewhere else...  in all of ccnp that has been the best thing i've tortured myself with, bar none...

so i've been taking a breather from tshoot since yesterday, reading through the ccie cert guide, catching up on anki's and digging around the doccd...

what i mean by reading through is just that; a first pass as a yard stick measure... i actually bought the ccie pdf as a present for passing route, but i've been sitting on it... i'm in no rush to the tshoot exam as i'm discovering a lot of integration here... just like route and switch, tshoot is getting it's due from me...
and just like i did with switch and route, i peek into the abyss from time to time...

 last night it dawned on me just how valuable the tshoot labs have been when i looked at wendell's services chapter... it started to make sense how some say that the ccie cert guide has it all... it also made sense that others think of it as an outline, or elaborate blueprint...  my early take on it is this; it is a broad brush stroke... it is a pointer... it is an indicator...

the chapter on services is 20 pages and includes the following:

 Hot Standby Router Protocol (HSRP)
 Gateway Load Balancing Protocol (GLBP)
 Virtual Router Redundancy Protocol (VRRP)
 Dynamic Host Configuration Protocol (DHCP)
 Network Time Protocol (NTP)
 Web Cache Communication Protocol (WCCP)
 Network Management
 Logging and Syslog
 Troubleshoot Network Services
 Implement IP Service Level Agreement (IP SLA)
 Implement NetFlow
 Implement Router IP Traffic Export (RITE)
 Implement SNMP
 Implement Cisco IOS Embedded Event Manager
   (EEM)
 Implement Remote Monitoring (RMON)
 Implement FTP
 Implement TFTP
 Implement TFTP Server on Router
 Implement Secure Copy Protocol (SCP)
 Implement HTTP and HTTPS
 Implement Telnet
 Implement SSH

yeah, twenty pages... shit...

but back to the tshoot manual... almost all of the above is covered in the labs... i was thrilled... also most of that i have real world experience with over the years... but that's not enough...

so something like RITE is 2 pages... that ain't getting it... try looking up RITE in the doccd... in fact, look for each of the topics above on the doccd as an exercise... they are a bit scattered; it takes some effort

for me the ccie cert guide will not be enough... if you think it will be for you, good for you and have a nice day... 

by the way, I couldn't find RITE in the configuration guide... i found it here:

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html

as they say, good luck with your search...

sh run...

hit it wendell...

As in all CCIE exams, you should expect that the easiest or most direct ways to a solution might be unavailable to you. In troubleshooting, perhaps the easiest way to the source of most problems is through the show run command or variations on it. Therefore, we’ll institute a simple “no show run” rule in this section that will force you to use your knowledge of more in-depth troubleshooting commands in the Cisco IOS portion of this section.

and he's right...

sh run is for pussy's...

tshoot lab manual...

i thought i'd avoid much commentary about the tshoot net acad lab manual, but this is worth a mention...

look at this:

DLS1#sh run int f0/5
Building configuration...

Current configuration : 163 bytes
!
interface FastEthernet0/5
 description FE to R1
 no switchport
 ip address 10.1.2.1 255.255.255.252
 speed 100
 duplex full
 spanning-tree bpduguard enable
end

note this is a distribution switch... note it is connected to a router... it is a routed port and it has bpduguard on it...  i remember a long time ago watching an anthony sequiera (sic) video where he demonstrates how to errdisable a switchport using a router... about a week ago i was watching jeremy cioara vids on tshoot, where he had to troubleshoot a situation just like this...

like chucky says to the interviewers in Good Will Hunting, "you're suspect..."

DLS1#sh int f0/5 sw
Name: Fa0/5
Switchport: Disabled

DLS1#sh spann int f0/5
no spanning tree info available for FastEthernet0/5

DLS1#sh int f0/5
FastEthernet0/5 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0016.c706.96c2 (bia 0016.c706.96c2)
  Description: FE to R1
  Internet address is 10.1.2.1/30
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:03, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     26086 packets input, 2944859 bytes, 0 no buffer
     Received 10943 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 10899 multicast, 0 pause input
     0 input packets with dribble condition detected
     23227 packets output, 2507991 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

i hate to say it but sh run int f0/5 is your only detection...

this is how you do it...

R1(config)#bridge 1 protocol ieee
R1(config)#int f0/0
R1(config-if)#bridge-group 1

DLS1#sh int f0/5
FastEthernet0/5 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0016.c706.96c2 (bia 0016.c706.96c2)
  Description: FE to R1

DLS1(config)#int f0/5
DLS1(config-if)#sw
DLS1(config-if)#
.Jan 22 16:48:07.180: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down
DLS1(config-if)#do
.Jan 22 16:48:09.202: %LINK-3-UPDOWN: Interface FastEthernet0/5, changed state to up
.Jan 22 16:48:10.208: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up
DLS1(config-if)#do
.Jan 22 16:48:10.619: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/5 with BPDU Guard enabled. Disabling port.
DLS1(config-if)#do
.Jan 22 16:48:10.619: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/5, putting Fa0/5 in err-disable state
DLS1(config-if)#do
.Jan 22 16:48:11.634: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down
DLS1(config-if)#do
.Jan 22 16:48:12.632: %LINK-3-UPDOWN: Interface FastEthernet0/5, changed state to down

DLS1#sh int f0/5
FastEthernet0/5 is down, line protocol is down (err-disabled)
  Hardware is Fast Ethernet, address is 0016.c706.9687 (bia 0016.c706.9687)
  Description: FE to R1

that ain't nice...

speaking of wendell & co...

here is a video of the three authors of ccie cert guide v4, wendell, denise and russ... pay particular attention as they detail the challenges of writing it, vis a vis, their imposed limitations on content...

http://www.pearsonitcertification.com/podcasts/episode.aspx?e=343fb0d3-43f8-4b32-88be-fef8610829bf

i have heard many well placed individuals emphatically declare that for the written, cert guide v4 is all that's needed... that may well be, but i ain't buying it... i have a whole other plan that includes many supplements over the next year or so...

to my point:

if they were so fearful of their limitations why did they waste valuable pages on VTP... there are even several mentions of ISL sprinkled in there, to include a diagram of it's encapsulation!

for the most part i'm enjoying the read, but my eyes just glaze over when confronted with VTP... they also mention Lan Switching as a reference... hello? 1999, CatOs, bye bye... but to give CatOs some credit, those guys had the presence of mind to allow for actually shutting VTP off, unlike IOS where the best you can do is transparent...

urf...

altn, bkup, rapid-...

it is paramount to note that rapid-pvst+ not only defined a discarding port role to replace the ineffective blocking and listening port states from 802.1d (pvst+ for  cisco indoctrinates) but also the port roles of alt and bkup...

altn is simply an alternate root port on a non root switch that will take over in case of root port failure...

backup is the same idea for the dp of a segment...

this is an important distinction which allows for quick replacement in case of failure...

it's also worth noting that the fast's are built into the protocol (portfast, backbonefast and uplinkfast)

this was actually a segue to this seemingly silly command:

spanning-tree link-type point-to-point

what the hell is that?

by definition a full duplex port is point-to-point, and when would you ever need to declare something that is already declared by default... when connecting to a shared (half duplex port) or mst port perhaps...

here are some thoughts on this, er, thing:

http://cciepursuit.wordpress.com/2008/03/07/spanning-tree-link-type/ 

i find it very interesting that wendell and company blast through this in:

CCIE Routing and Switching
Certification Guide
Fourth Edition

Configuring RPVST+ is straightforward. In global configuration mode, issue the spanning-tree mode rapid-pvst command. Then, optionally, on an interface (VLAN, physical, or PortChannel), configure the spanning-tree link-type point-to-point command. This configures the port for fast changeover to the forwarding state.

this leads me to believe that the ccie cert guide v4 bears meticulous viewing for such loaded weapons...

tshoot net acad lab man...

that was impressive, tedious, very time consuming, but worth it...

33 labs in about two weeks... you will be amazed what you take away from the experience of this... i haven't posted much about these labs, and i'm glad i refrained... another great point is there are no answer sheets... this thing is all about discovery... you owe this to yourself...

if you are going through tshoot, you don't want to forget about this one... this is essential... in fact if you are going through ccnp, you should do each section's lab manual, switch and route included, no question...

you've seen the tshoot topologies; you can bet your ass their guts are based on this... the last lab is a very pleasant surprise by the way... i was actually moved by it... if you go through this you will understand what i'm talking about...

rest assured, i'll be doing these in the near future:

we'll see what ole marty brings...

whoa... INE and agnostic books...

INE often touts books that are not cisco, because, well, they are not cisco... their point is valid; reading vendor agnostic books is probably a good thing because you are not stuck with a single vendor's idea's and gear, and ideas about their gear, and gear about their ideas, and, ad nauseum... it is a valid point...

so here is a link to their recommended reading list:

http://www.ine.com/resources/cciebooks.htm

and because i do, i ventured over there to have a look... one of the agnostic books featured is this:

http://www.amazon.com/gp/product/0201398613

this is not a joke... look closely...

that's right... look again... that is one thousand fifty seven dollars and seventy six cents...

for a new copy... well since it's a new copy, of course... and it was written in 2001 which makes it almost modern for an industry that changes every eleven seconds... that's a little more than a buck a page... just for reference, the ccna program was 3 years old at the publication of this book...

i think the reason it costs so much is that it comes with an original floppy disk  chock full of word perfect documents...as an extra added bonus there's lots of chapters devoted to IPX...

port channel and interfaces...

this is a bit of a repeat from an earlier post, but it bears repeating... so i'm gonna repeat... and i don't care if you care... so there...

if you make a change to the hardware interfaces that are members of a portchannel they will fall out, or rather, get suspended...

it is too bad that the show interfaces command on a physical interface does not mention which portchannel they are members of... the show interfaces command on a port channel, however does show the member interfaces...

DLS2#sh int f0/2
FastEthernet0/2 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0016.479e.5f84 (bia 0016.479e.5f84)
  Description: Channel to ALS1
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:43, output 00:00:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     4685 packets input, 563671 bytes, 0 no buffer
     Received 2721 broadcasts (2465 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 2465 multicast, 0 pause input
     0 input packets with dribble condition detected
     17440 packets output, 1375217 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

see it anywhere? no... good...

DLS2#sh int po10
Port-channel10 is up, line protocol is up (connected)
  Hardware is EtherChannel, address is 0016.479e.5f85 (bia 0016.479e.5f85)
  Description: Channel to DLS1
  MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, link type is auto, media type is unknown
  input flow-control is off, output flow-control is unsupported
  Members in this channel: Fa0/3 Fa0/4
  ARP type: ARPA, ARP Timeout 04:00:00

can't have everything...   sh int trunk and etherchann summ is your antidote...

you love them...

DLS2#sh int trunk

Port        Mode             Encapsulation  Status        Native vlan
Po2         on               802.1q         trunking      900
Po10        on               802.1q         trunking      900

Port        Vlans allowed on trunk
Po2         10,20,30,100
Po10        10,20,30,50,100,200

Port        Vlans allowed and active in management domain
Po2         10,20,30,100
Po10        10,20,30,50,100,200

Port        Vlans in spanning tree forwarding state and not pruned
Po2         10,20,30,100
Po10        10,20,30,50,100,200
DLS2#sh etherch summ
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port


Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(SU)          -        Fa0/1(P)    Fa0/2(P)   
10     Po10(SU)         -        Fa0/3(P)    Fa0/4(P)

some bozack issued the command:

DLS2(config)#int rang f0/3 - 4
DLS2(config-if-range)#no sw noneg
DLS2(config-if-range)#end
DLS2#sh int trunk

Port        Mode             Encapsulation  Status        Native vlan
Po2         on               802.1q         trunking      900

Port        Vlans allowed on trunk
Po2         10,20,30,100

Port        Vlans allowed and active in management domain
Po2         10,20,30,100

Port        Vlans in spanning tree forwarding state and not pruned
Po2         10,20,30,100

that didn't sit too well with po10, so it bounced them...

DLS2#sh etherch summ

Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(SU)          -        Fa0/1(P)    Fa0/2(P)   
10     Po10(SD)         -        Fa0/3(s)    Fa0/4(s) 

he wasn't finished...

DLS2#sh int f0/3 sw
Name: Fa0/3
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: down (suspended member of bundle Po10)
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 999 (UNUSED)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: 10,20,30,50,100,200
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

the quick fix is to set everything good on the portchannel... that will insure uniformity across the interfaces...

DLS2(config)#int po10
DLS2(config-if)#sw trunk encap dot1q
DLS2(config-if)#sw mode trunk
DLS2(config-if)#sw trunk native vlan 900
DLS2(config-if)#sw noneg
DLS2(config-if)#end
DLS2#sh etherch summ

Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(SU)          -        Fa0/1(P)    Fa0/2(P)   
10     Po10(SU)         -        Fa0/3(P)    Fa0/4(P)   

you can use the interface range command with portchannels too...