again with the beginning...

ccieordie.com is the new beginning... 

when i first launched this thing it was dedicated to the struggles in the trenches... that's where it hurts the most... i do not envy those starting the journey, but i do envy the excitement of discovery...

this place is about the pain of adversity...

ccieordie.com will be about the new pain... i thought all along if i ever survived CCNA, and God willing CCNP, that i would launch a new site...

that has happened...

i'm going after CCIE like i always knew i would and i don't care who gives a shit...

this place isn't going away, but my sorry ass ruminations will mostly be chronicled there...

remember that none of it matters until CCNA...

ccie or die...

i'm building a new site dedicated to my pursuit of ccie...

it can be found here:

http://ccieordie.com/

be patient, content is coming...

this is the logical continuation...

gre instead of virtual link...

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801ec9ee.shtml#using

this is borderline trivia, and i think bad design, however... a very good reason to not use a vl is due to the DNA (do not age) or no dead timer...

where am i...

as you might imagine, i am currently lost... i went through a bout of decompression yesterday after finally consolidating CCNP... this has been a dream of mine for a long time and now that it is here it will take some getting used to... but i'm sure i will get used to it...

the fact is there is no celebration going on here...  there is only the work, more consolidation, going back to the beginning to move forward again...

there is some relief that there is no test in the coming months... i plan to wait until the first of next year before sitting the CCIE written... and that was always the plan; yesterday has not changed that... 

pucker time is over and i am happy about the loneliness of the long distance run ahead... there is no immediate fight; there is no rush; there is only the battle with me now... and for that i am grateful...

back to squares...

but i do like having this to keep me company:

graduation present...

let's see what marty's got...

ccnp...

i'm official..

it's mine...

sid...

short for sid vicious because of his hair... a new friend of mine... he likes the chow here...

area 0...

that old ospf design guide is great...

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml#t6

The Backbone and Area 0

OSPF has special restrictions when multiple areas are involved. If more than one area is configured, one of these areas has be to be area 0. This is called the backbone. When designing networks it is good practice to start with area 0 and then expand into other areas later on.

The backbone has to be at the center of all other areas, i.e. all areas have to be physically connected to the backbone. The reasoning behind this is that OSPF expects all areas to inject routing information into the backbone and in turn the backbone will disseminate that information into other areas.

 contrast this with what jeff doyle wrote...

Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0. 

quote of the day, ospf design guide...

i never tire of rereading this... this is atrophy remover...

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

ospf multiple area, summarization, stubs...

i've been saying this for a long time... all of this is over-engineering... it's easily relegated to network trivia, or a "we do it because we can" philosophy... but nobody wants to hear me say it... listen to these guys then...

it is no wonder my mind glazes over when these discussions come up...

http://packetpushers.net/show-134-ospf-design-part-1-debunking-the-multiple-area-myth/

and we'll have an area here and here and here, and this will be a stub, and we'll summarize there, and that needs to be nssa because it sounds cool and we get to use it in a sentence... gimme a break...

passive interface, eigrp and ospf...

this command can certainly be a pain in the ass...

ospf gives you a decent way to detect it with:

R1#sh ip ospf int s1/0.12
Serial1/0.12 is up, line protocol is up
  Internet Address 10.1.1.1/30, Area 12, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    No Hellos (Passive interface)
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 12 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1

although you have to look; it doesn't jump out at you...

eigrp isn't as friendly...

R4#sh ip eigrp int
EIGRP-IPv4 Interfaces for AS(10)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/1                    1        0/0       0/0          19       0/0           84           0
R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router eigrp 10
R4(config-router)#no passive-int f0/0
R4(config-router)#
*Feb  9 09:45:59.609: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.1.4.6 (FastEthernet0/0) is up: new adjacency
R4(config-router)#do sh ip eigrp int
EIGRP-IPv4 Interfaces for AS(10)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/1                    1        0/0       0/0          19       0/0           76           0
Fa0/0                    1        0/0       0/0          19       0/0           76           0
R4(config-router)#do sh ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(10)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.1.4.6                Fa0/0                    11 00:01:17   19   114  0  814
1   10.1.4.10               Fa0/1                    14 00:28:05   19   114  0  788
R4(config-router)#router eigrp 10
R4(config-router)#passive-int f0/0
R4(config-router)#
*Feb  9 09:47:35.717: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.1.4.6 (FastEthernet0/0) is down: interface passive
R4(config-router)#do sh ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(10)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.1.4.10               Fa0/1                    11 00:28:32   18   108  0  788

the eigrp commands just show you that it's NOT there... debug doesn't help either...

trace and ttl...

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6057.shtml

The Traceroute Command

The traceroute command is used to discover the routes that packets actually take when traveling to their destination. The device (for example, a router or a PC) sends out a sequence of User Datagram Protocol (UDP) datagrams to an invalid port address at the remote host.

Three datagrams are sent, each with a Time-To-Live (TTL) field value set to one. The TTL value of 1 causes the datagram to "timeout" as soon as it hits the first router in the path; this router then responds with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired.

Another three UDP messages are now sent, each with the TTL value set to 2, which causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams are trying to access an invalid port at the destination host, ICMP Port Unreachable Messages are returned, indicating an unreachable port; this event signals the Traceroute program that it is finished.

The purpose behind this is to record the source of each ICMP Time Exceeded Message to provide a trace of the path the packet took to reach the destination. For all the options about this command, see Trace (privileged).

R1#trace 10.2.1.4
Type escape sequence to abort.
Tracing the route to 10.2.1.4
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.1.2 16 msec 20 msec 20 msec
  2 10.1.1.6 28 msec 28 msec 16 msec
  3 10.1.1.10 64 msec 64 msec 60 msec
  4 10.1.4.6 60 msec 68 msec 64 msec
  5 10.2.1.4 64 msec 64 msec 72 msec
R1#
*Feb  9 09:22:22.349: ICMP: time exceeded rcvd from 10.1.1.2
*Feb  9 09:22:22.369: ICMP: time exceeded rcvd from 10.1.1.2
*Feb  9 09:22:22.389: ICMP: time exceeded rcvd from 10.1.1.2
*Feb  9 09:22:22.413: ICMP: time exceeded rcvd from 10.1.1.6
*Feb  9 09:22:22.453: ICMP: time exceeded rcvd from 10.1.1.6
*Feb  9 09:22:22.489: ICMP: time exceeded rcvd from 10.1.1.6
*Feb  9 09:22:22.569: ICMP: time exceeded rcvd from 10.1.1.10
*Feb  9 09:22:22.633: ICMP: time exceeded rcvd from 10.1.1.10
*Feb  9 09:22:22.693: ICMP: time exceeded rcvd from 10.1.1.10
*Feb  9 09:22:22.753: ICMP: time exceeded rcvd from 10.1.4.6
*Feb  9 09:22:22.829: ICMP: time exceeded rcvd from 10.1.4.6
R1#
*Feb  9 09:22:22.893: ICMP: time exceeded rcvd from 10.1.4.6
*Feb  9 09:22:22.965: ICMP: dst (10.1.1.1) port unreachable rcv from 10.2.1.4
*Feb  9 09:22:23.037: ICMP: dst (10.1.1.1) port unreachable rcv from 10.2.1.4
*Feb  9 09:22:23.117: ICMP: dst (10.1.1.1) port unreachable rcv from 10.2.1.4
 

rfc 3330...

years ago when i was dumber than i am now i used to refer to host addresses of 169.254.x.x as those stupid windows addresses that are dished out by microsoft when the host can't find a dhcp server...

they are actually dished out by IANA, kind of... 

IANA                         Informational                      [Page 2]

 
RFC 3330               Special-Use IPv4 Addresses         September 2002


   169.254.0.0/16 - This is the "link local" block.  It is allocated for
   communication between hosts on a single link.  Hosts obtain these
   addresses by auto-configuration, such as when a DHCP server may not
   be found.

as soon as you get one of those addresses on a host you think, O MY GOD, the dhcp server is down... that might be... however, and i'm sure you know, you also might be experiencing a connectivity problem in the path to the dhcp server...

and there is also the possibility of not getting the 169.254.x.x address although the dhcp server IS down... that's hardly fair... the client has no reason to broadcast for the address again once it has its lease... of course if you manually try to renew and ipconfig hangs up in the pursuit of a legit address, you've suddenly learned something...

for troubleshooting, before blaming the dhcp device, i vett l2 first...

on the client's switch...

sh int
sh vlan brief
sh int trunk
sh etherchannel summ
sh port-sec
and l3 checks if applicable...

generally speaking, if it's a l2 problem, sh int, sh vlan and sh int trunk will reveal most everything...

then onto the next switch in the path, which should eventually lead to the dhcp server...

granted this next guys link is not necessarily troubleshooting, and he may have some thoughts here that you might consider... however even for discovery purposes, i would not resort to his kind of bullshit below...

https://w.ntwk.cc/initial-ccie-lab-checks/

i am not going to pollute my pages with a sample of his, er, ideas...  go see for yourself...
 

quote of the day; jeff doyle on ospf...

jeff speaks...

Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.


Every link state router floods information about itself, its links, and its neighbors to every other router. From this flooded information each router builds an identical link state database. Each router then independently runs a shortest-path-first calculation on its database – a local calculation using distributed information – to derive a shortest-path tree. This tree is a sort of map of the shortest path to every other router.

One of the advantages of link state protocols is that the link state database provides a “view” of the entire network, preventing most routing loops. This is in contrast to distance vector protocols, in which route information is passed hop-by-hop through the network and a calculation is performed at each hop – a distributed calculation using local information. Each router along a route is dependent on the router before it to perform its calculations correctly and then correctly pass along the results. When a  router advertises the prefixes it learns to its neighbors it’s basically saying, “I know how to reach these destinations.” And because each distance vector router knows only what its neighbors tell it, and has no “view” of the network beyond the neighbors, the protocol is vulnerable to loops.

The second concept is this:

When link state domains grow large, the flooding and the resulting size of the link state database becomes a scaling problem. The problem is remedied by breaking the routing domain into areas: That first concept is modified so that flooding occurs only within the boundaries of an area, and the resulting link state database contains only information from the routers in the area.  This, in turn, means that each router’s calculated shortest-path tree only describes the path to other routers within the area.

The third concept is this:

OSPF areas are connected by one or more Area Border Routers (the other main link state protocol, IS-IS, connects areas somewhat differently) which maintain a separate link state database and calculate a separate shortest-path tree for each of their connected areas. So an ABR by definition is a member of two or more areas. It advertises the prefixes it learns in one area to its other areas by flooding Type 3 LSAs into the areas that basically say, “I know how to reach these destinations.”

Wait a minute – what that last concept described is not link state, it’s distance vector. The routers in an area cannot “see” past the ABR, and rely on the ABR to correctly tell them what prefixes it can reach. The SPF calculation within an area derives a shortest-path tree that depicts all prefixes beyond the ABR as leaf subnets connected to the ABR at some specified cost.

And that leads us to the answer to the question:

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.

arp...

resolving a known l3 address to an unknown l2 address...

i suggest you spend some time here, and with rfc 826... it is not enough to have familiarity...

from: http://www.tcpipguide.com/free/t_ARPMessageFormat.htm

Address resolution using ARP is accomplished through the exchange of messages between the source device seeking to perform the resolution, and the destination device that responds to it. As with other protocols, a special message format is used containing the information required for each step of the resolution process.

ARP messages use a relatively simple format. It includes a field describing the type of message (its operational code or opcode) and information on both layer two and layer three addresses. In order to support addresses that may be of varying length, the format specifies the type of protocol used at both layer two and layer three and the length of addresses used at each of these layers.

The ARP message format is designed to accommodate layer two and layer three addresses of various sizes. This diagram shows the most common implementation, which uses 32 bits for the layer three (“Protocol”) addresses, and 48 bits for the layer two hardware addresses. These numbers of course correspond to the address sizes of the Internet Protocol version 4 and IEEE 802 MAC addresses, used by Ethernet.

ccna to ccie...

i have always thought in the past without fully understanding why, that  ccie is  essentially turbo ccna...  i still believe that...

ccnp is  terribly important as it fills in the advanced technologies between... those who choose to make the leap directly from ccna to ccie are brave souls indeed...  ultimately they end up doing ccnp, without calling it exactly that... it is not possible to get there from here in any equation...

however, ccie is ccna without the creamy center of ccnp...

while i wouldn't say that any of them are fun, i will say that ccnp has been an adagio...

i see the entire thing as a play in three acts...

ccna is the first act of course, laying the foundation for the drama through exposition, character establishment and relationships...

ccnp is the rising action; the attempt to learn new things, character development and confrontation along the way...

ccie is the climax, the second turning point; the resolution of the problems set forth...

stp root switch...

from cisco's 3560/3750 guide which of course you can download...

If all switches in a network are enabled with default spanning-tree settings, (and when they come out of the box they are wearing their birthday suits) the switch with the lowest MAC address becomes the root switch.


that is gospel...

priority is default at 32768...

that is gospel...

this is the BID of this switch on vlan 10...

dsw1#sh spann                                                                 
                                                                              
VLAN0010                                                                      
  Spanning tree enabled protocol rstp                                         
  Root ID    Priority    32778        

32768 + 10 is 32778...

the priority can change all that ONLY if it has been configured to do so... and if it has been configured to do so, the mac doesn't matter...

again, that is if it has been configured to do so...

which means the priority is an afterthought, although we all know you want to be deterministic about the placement of the root switch...

out of the box, MAC is king...

your witness, counselor...

why ospf area's and other sundries...

these kinds of basic questions are tough on the spot...

why ospf areas? ospf areas are like, like life... yeah...



http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094aaa.shtml

Areas limit the scope of route information distribution. It is not possible to do route update filtering within an area. The link-state database (LSDB) of routers within the same area must be synchronized and be exactly the same; however, route summarization and filtering is possible between different areas. The main benefit of creating areas is a reduction in the number of routes to propagate—by the filtering and the summarization of routes.

which really came in handy back when routers had shitty processors and 1k of ram...

An autonomous system boundary router (ASBR) advertises external destinations throughout the OSPF autonomous system. External routes are the routes redistributed into OSPF from any other protocol. In many cases, external link states make up a large percentage of the link states in the databases of every router. A stub area is an area in which you don't allow advertisements of external routes, thus reducing the size of the database even more. Instead, a default summary route (0.0.0.0) is inserted into the stub area in order to reach these external routes. If you have no external routes in your network, then you have no need to define stub areas. 

no external routes equals no redistribution equals no stubs...

All areas in an OSPF autonomous system must be physically connected to the backbone area (area 0). In some cases where this physical connection is not possible, you can use a virtual link to connect to the backbone through a non-backbone area. As mentioned above, you can also use virtual links to connect two parts of a partitioned backbone through a non-backbone area. The area through which you configure the virtual link, known as a transit area, must have full routing information. The transit area cannot be a stub area.

good... and you use the area id virtual-link  command to accomplish this... then what ospf type is a virtual link... would someone please make up my mind...

doyle calls it a network type...

OSPF defines five network types:

Point-to-point networks
Broadcast networks
Nonbroadcast Multiaccess (NBMA) networks
Point-to-multipoint networks
Virtual links

reason number 65,535...

that you should be on cln...

if you don't know who terry slattery is, put yourself in a time out immediately...

like he says above, if you want to be a ccie because of money, there is no hope for you... your cause is lost out the gate...

of multiplexing and sockets...

http://www.inetdaemon.com/tutorials/internet/tcp/multiplexing.shtml

transport layer:

Multiplexing is the process of combining two or more data streams into a single physical connection. TCP provides multiplexing facilities by using source and destination port numbers. These port numbers allow TCP to set up a number of virtual connections over a physical connnection and multiplex the data stream through that connection.

session layer:

 http://www.tcpipguide.com/free/t_SessionLayerLayer5.htm

The primary job of session layer protocols is to provide the means necessary to set up, manage, and end sessions. In fact, in some ways, session layer software products are more sets of tools than specific protocols. These session-layer tools are normally provided to higher layer protocols through command sets often called application program interfaces or APIs.

Common APIs include NetBIOS, TCP/IP Sockets and Remote Procedure Calls (RPCs). They allow an application to accomplish certain high-level communications over the network easily, by using a standardized set of services. Most of these session-layer tools are of primary interest to the developers of application software. The programmers use the APIs to write software that is able to communicate using TCP/IP without having to know the implementation details of how TCP/IP works.

For example, the Sockets interface lies conceptually at layer five and is used by TCP/IP application programmers to create sessions between software programs over the Internet on the UNIX operating system. Windows Sockets similarly lets programmers create Windows software that is Internet-capable and able to interact easily with other software that uses that interface. (Strictly speaking, Sockets is not a protocol, but rather a programming method.)

what is a socket?

http://en.wikipedia.org/wiki/Network_socket

An Internet socket is characterized by a unique combination of the following:

• Local socket address: Local IP address and port number
• Remote socket address: Only for established TCP sockets. As discussed in the client-server section below, this is necessary since a TCP server may serve several clients concurrently. The server creates one socket for each client, and these sockets share the same local socket address.
• Protocol: A transport protocol (e.g., TCP, UDP, raw IP, or others). TCP port 53 and UDP port 53 are consequently different, distinct sockets.

joshua, at cln...

there is a new idea at cln... learn about it here:

https://learningnetwork.cisco.com/docs/DOC-16300#comment-34483

joshua has already done 2 and has another in the works...i suggest you watch them and make an honest assessment of yourself... you will see that something like this is the standard by which you will be measured...

if you think you have have the fundamentals cold, then you don't need this, however the question you must ask yourself, and you must keep asking yourself time and again, all throughout this experience is:

But do I really...

two steps forward, five steps back...

what is inalienable...

through the fog of time what one thought once inalienable, becomes muted...

back to the beginning again...

recent events have me reevaluating...

what is a trunk and what makes an etherchannel so very different...

from: http://www.ciscopress.com/articles/article.asp?p=29803&seqNum=3

A trunk port is by default a member of all the VLANs that exist on the switch and carry traffic for all those VLANs between the switches. To distinguish between the traffic flows, a trunk port must mark the frames with special tags as they pass between the switches. Trunking is a function that must be enabled on both sides of a link. If two switches are connected together, for example, both switch ports must be configured for trunking, and they must both be configured with the same tagging mechanism (ISL or 802.1Q).

good... an etherchannel does the same thing only it allows for the aggregation of ports into a bundle, thus increasing the total bandwidth available by a factor of the included ports...

from: http://en.wikipedia.org/wiki/EtherChannel

EtherChannel is a port link aggregation technology or port-channel architecture used primarily on Cisco switches. It allows grouping of several physical Ethernet links to create one logical Ethernet link for the purpose of providing fault-tolerance and high-speed links between switches, routers and servers. An EtherChannel can be created from between two and eight active Fast, Gigabit or 10-Gigabit Ethernet ports, with an additional one to eight inactive (failover) ports which become active as the other active ports fail. EtherChannel is primarily used in the backbone network, but can also be used to connect end user machines.

multiplexing...

i have always combined the ideas of encapsulation/deencapsulation with multiplexing... in fact i thought they were the same... no... see also tdm,sdm and cdm

from: http://www.mindregal.com/netfund.php?id=Encapsulation

Encapsulation is the process of adding header information by each layer to the original data as data goes down in the OSI layer. 

Once entire encapsulated information is reached at other end, de-encapsulation occurs and retrieve the original data from the encapsulated information.

De-encapsulation is the process of stripping off the header of the PDU information at each layer as the information is passed up from layer to layer of the OSI Reference Model.

that's a good explanation...

on to multiplexing...


here is a  link for those with the stomach to dig deeper...

http://books.google.com/books?id=On_Hh23IXDUC&pg=PA264&lpg=PA264&dq=osi+layers+and+multiplexing&source=bl&ots=pRafejp6zV&sig=gN6ZE0YAR5vNHhIpxkszFAIxtfk&hl=en&sa=X&ei=V9ESUfD4HurW0QGxg4CIAw&ved=0CFQQ6AEwBTgK#v=onepage&q=osi%20layers%20and%20multiplexing&f=false

more here...

http://en.wikipedia.org/wiki/OSI_model

and here...

http://www.tcpipguide.com/free/t_OSIReferenceModelLayerSummary.htm

have fun... 

boson's tshoot simulator...

119 bucks... is it worth it...

that depends on you... it certainly helps you, you have to give it that... it can't hurt either but it cuts you off at the knees in a lot of areas, especially if you are practicing for speed... yes speed... unfortunately speed is a factor in this thing...

where it helps:

anything that forces you to train, helps... yes virginia, this is training and training is not always fun so suck it up...

you get better simply by forcing yourself to pinpoint problems...

you get better by determining solutions to said pinpointed problems using a limited command set...

where it sucks:

in the limited command set specifically...

no tracert from the pc...

no interface trunk... that's a big one... that is my go to command at l2...

no piping... another big time saver...

you end up using show run an awful lot, which isn't troubleshooting... show run is hunting and pecking... show run does not help you... 

but at least if they are going to make you rely on show run, make available show run interface... no show run interface...

face it, it's not real troubleshooting, it's a flash script... which makes me wary of the troubleshoot section in the ccie lab... if they (cisco) are going to use flash scripts for such an important test, they had better issue the limited command set that is supported on the test to the public ahead of time... anything less is dirty pool...

i cannot imagine sitting the ccie lab without benefit of piping... especially with the troubleshoot section which basically gives you ten minutes a ticket... gimme a friggin break here...

dhcp without rules...

what is important with the dhcp server if you happen to put it in a different subnet other than where the client lives, is that it supports the vlan where you want the address to be delivered with ip helper...

r4 is the dhcp server...

if you make r4 the default router of the pool, that will give the client THAT address as it's gateway...

R4#sh run | b dhcp pool cisco
ip dhcp pool cisco
 network 10.2.1.0 255.255.255.0
 default-router 10.1.4.5

note also there is no matching domain name, irrelevant...

R4#sh ip domain
lab.local

dsw1#sh ip domain                                                             
cisco         

r4 holds the binding for the pc off asw1...

R4#sh ip dhcp bind
Bindings from all pools not associated with VRF:
IP address      Client-ID/         Lease expiration     Type       State      Interface
        Hardware address/
        User name
10.2.1.3        01e8.9a8f.98a7.03       Feb 06 2013 08:19 AM    Automatic  Active     Unknown

ip helper must support the svi, however...

dsw1#sh run int vlan 10                                                       
Building configuration...                                                     
                                                                              
Current configuration : 158 bytes                                             
!                                                                             
interface Vlan10                                                              
 ip address 10.2.1.1 255.255.255.0                                            
 ip helper-address 10.1.4.5                                                   
 standby 10 ip 10.2.1.254                                                     
 standby 10 priority 110                                                      
 standby 10 preempt                                                           
end                         

for my money, i'd rather have the gateway for the pc as the virtual ip of the vlan it belongs to regardless of the router which is governing it... as long as ip helper can get to it, you're done...

R4#sh run | b dhcp
ip dhcp pool cisco
 network 10.2.1.0 255.255.255.0
 default-router 10.2.1.254

the client has as its gateway the hsrp virtual address and it can ping across to the far end...

if the ip helper points to it from the correct vlan on the switch, you can put the dhcp server in any domain, on any device... but for your own sanity, use the hsrp ip because that's it's reason for being...

R4#debug ip dhcp serv pack
DHCP server packet debugging is on.
R4#
*Feb  5 08:44:01.173: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:01.177: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:01.181: DHCPD: client's VPN is .
*Feb  5 08:44:01.181: DHCPD: DHCPRELEASE message received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:01.189: DHCPD: removing ARP entry (10.2.1.3 vrf default).
R4#
*Feb  5 08:44:09.773: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:09.773: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:09.773: DHCPD: client's VPN is .
*Feb  5 08:44:09.773: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:44:09.781: DHCPD: Saving workspace (ID=0x40000007)
*Feb  5 08:44:09.781: DHCPD: New packet workspace 0x6956B57C (ID=0xE5000008)
R4#
*Feb  5 08:44:11.781: DHCPD: Reprocessing saved workspace (ID=0x40000007)
*Feb  5 08:44:11.785: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:44:11.785: DHCPD: Sending DHCPOFFER to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:11.785: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
*Feb  5 08:44:11.785: DHCPD: Freeing saved workspace (ID=0x40000007)
*Feb  5 08:44:11.801: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:11.801: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:11.801: DHCPD: client's VPN is .
R4#
*Feb  5 08:44:11.801: DHCPD: DHCPREQUEST received from client 01e8.9a8f.98a7.03.
*Feb  5 08:44:11.801: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:11.801: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
R4#
*Feb  5 08:44:15.317: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:15.321: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:15.325: DHCPD: client's VPN is .
*Feb  5 08:44:15.325: DHCPD: DHCPINFORM received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:15.325: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:15.325: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
R4#
*Feb  5 08:45:28.553: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:28.553: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:28.553: DHCPD: client's VPN is .
*Feb  5 08:45:28.557: DHCPD: DHCPRELEASE message received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:28.557: DHCPD: removing ARP entry (10.2.1.3 vrf default).
R4#
*Feb  5 08:45:33.733: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:33.737: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:33.737: DHCPD: client's VPN is .
*Feb  5 08:45:33.737: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:45:33.737: DHCPD: Saving workspace (ID=0xE5000008)
*Feb  5 08:45:33.741: DHCPD: New packet workspace 0x67EA1BDC (ID=0xA6000009)
R4#
*Feb  5 08:45:35.745: DHCPD: Reprocessing saved workspace (ID=0xE5000008)
*Feb  5 08:45:35.745: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:45:35.745: DHCPD: Sending DHCPOFFER to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:35.745: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
*Feb  5 08:45:35.745: DHCPD: Freeing saved workspace (ID=0xE5000008)
*Feb  5 08:45:35.765: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:35.765: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:35.765: DHCPD: client's VPN is .
R4#
*Feb  5 08:45:35.765: DHCPD: DHCPREQUEST received from client 01e8.9a8f.98a7.03.
*Feb  5 08:45:35.765: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:35.765: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
R4#
*Feb  5 08:45:39.293: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:39.297: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:39.301: DHCPD: client's VPN is .
*Feb  5 08:45:39.305: DHCPD: DHCPINFORM received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:39.305: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:39.309: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.

troubleshooting, from the horse's mouth...

there are a number of links that provide troubleshooting flow charts at cisco.com

eigrp
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094613.shtml

ospf
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800949f7.shtml

bgp
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009478a.shtml

naturally, for just about any technology, you will find more of the same there...

native vlan and control traffic...

i got involved in a thread on cln here:

https://learningnetwork.cisco.com/message/279101#279101

on that link you can download a packet capture that i attached...

i've read recently some conflicting ideas about the tagging of control traffic when vlan 1 is not present... my original thought sided with marko that l2 control traffic belonged to the switch.. here is marko's post:

http://blog.ipexpert.com/2011/01/19/old-ccie-myths-vlan-1/

he explores this idea at length, but this idea is incorrect...

this idea is refuted here:

http://www.fragmentationneeded.net/2011/01/revisiting-vlan-1-myth-again.html

and from the horse's mouth here:

(from Cisco Lan Switching Fundamentals)

It is important to understand the significance of VLAN 1. By default, all switch ports are part of VLAN 1. VLAN 1 contains control plane traffic and can contain user traffic. It is recommended that user traffic be configured on VLANs other than VLAN 1, primarily to prevent unnecessary user broadcast and multicast traffic from being processed by the Network Management Processor (NMP) of the supervisor. Although VLAN 1 user traffic can be pruned from a trunk, it is not the case with control plane traffic. In fact, in older Cisco Catalyst Software versions (5.4 or earlier), VLAN 1 could not be removed at all from a trunk. Control plane traffic such as VTP, CDP, and PAgP protocols are tagged with VLAN 1 information and are forwarded on a trunk regardless if the trunk has pruned VLAN 1.


naturally, i wanted to do my own testing, but my caps never showed tagging... i was using a dhcp windows client for monitoring and in the back of my mind my thought was that i'd never see dot1q tags because my windows nic simply didn't support tagging, therefore wouldn't show in the cap...  well, breaking my current working topology was an annoying idea simply to prove that so i moved on with what i was currently working at the time...

this morning, of course, it was nagging me so i had to be sure... turns out that is correct... dot1q tags don't show up in my windows box caps, but they do with the linux caps...

note on dsw1 in the below output that vlan 1 is not included in trunking...

dsw1#sh int trunk                                                              
                                                                               
Port        Mode             Encapsulation  Status        Native vlan          
Po1         on               802.1q         trunking      200                  
Po2         on               802.1q         trunking      200                  
                                                                               
Port        Vlans allowed on trunk                                             
Po1         10,20,200                                                          
Po2         10,20,200                                                          
                                                                               
Port        Vlans allowed and active in management domain                      
Po1         10,20,200                                                          
Po2         10,20,200                                                          
                                                                               
Port        Vlans in spanning tree forwarding state and not pruned             
Po1         10,20,200                                                          
Po2         10,20,200               

in the cap below note that the control traffic is tagged with vlan 1...

in fact all of the control traffic in the cap is tagged 1... but see for yourself, download the cap from the link and draw your own conclusions... also note that the cap is from the tshoot topology, which means that all supported protocols are represented as they would appear in cisco's topology...  naturally it is my representation of that topology; it is not gospel...

have fun...

note about topology: vlan's 4 and 8 support the gns3 environment onto the switched network... so don't let those qinq's confuse you...

trap receiver...

is a free program that, guess what, receives snmp traps... this can be exciting for about 9 seconds...

you can download it here...

http://www.trapreceiver.com/

setting up snmp is easy...

dsw1#sh run | b snmp                                             
snmp-server community ccie RO                                    
snmp-server enable traps vlancreate                              
snmp-server host 10.2.1.3 snmp  vlancreate    

you can enable all traps or some, then send them to the collector...


dsw1(config)#snmp-server enable traps ?                          
  auth-framework    Enable SNMP CISCO-AUTH-FRAMEWORK-MIB traps   
  bgp               Enable BGP traps                             
  bridge            Enable SNMP STP Bridge MIB traps             
  cef               Enable SNMP CEF traps                        
  cluster           Enable Cluster traps                         
  config            Enable SNMP config traps                     
  config-copy       Enable SNMP config-copy traps                
  config-ctid       Enable SNMP config-ctid traps                
  copy-config       Enable SNMP config-copy traps                
  cpu               Allow cpu related traps                      
  dot1x             Enable SNMP dot1x traps                      
  eigrp             Enable SNMP EIGRP traps                      
  energywise        Enable SNMP ENERGYWISE traps                 
  entity            Enable SNMP entity traps                     
  envmon            Enable SNMP environmental monitor traps      
  errdisable        Enable SNMP errdisable notifications         
  event-manager     Enable SNMP Embedded Event Manager traps     
  flash             Enable SNMP FLASH notifications              
  hsrp              Enable SNMP HSRP traps                       
  ipmulticast       Enable SNMP ipmulticast traps 
  etc...

then look at your butterfly collector...

this is a real over simplification, and you already know this... nothing earth shattering here... go watch the superbowl or something...

ospf authentication...

every now and then i just have to force myself to do this again and again... can't make mistakes with stupid shit like this during pucker time... this'll kill you on the clock... it's gotta be automatic everywhere you can make it automatic... take no prisoners...

R4#debug ip ospf adj
OSPF adjacency debugging is on
R4#
Feb  3 12:42:38.416: OSPF-1 ADJ   Se1/0.34: Send with youngest Key 1
R4#debug
Feb  3 12:42:47.548: OSPF-1 ADJ   Se1/0.34: Send with youngest Key 1
R4#debug ip ospf pack
OSPF packet debugging is on
R4#
Feb  3 12:42:57.440: OSPF-1 ADJ   Se1/0.34: Send with youngest Key 1
R4#
Feb  3 12:42:58.688: OSPF-1 PAK  : rcv. v:2 t:1 l:48 rid:3.3.3.3 aid:0.0.0.34 chk:0 aut:2 keyid:1 seq:0x510E5419 from Serial1/0.34
R4#
Feb  3 12:43:07.004: OSPF-1 ADJ   Se1/0.34: Send with youngest Key 1
R4#
Feb  3 12:43:08.044: OSPF-1 PAK  : rcv. v:2 t:1 l:48 rid:3.3.3.3 aid:0.0.0.34 chk:0 aut:2 keyid:1 seq:0x510E5422 from Serial1/0.34
R4#un all
All possible debugging has been turned off

version:ospfv2 t:1 hello l:48 length rid: router id aid: area id chk: checksum aut: authentication type keyid: md5 key seq: sequence number

http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_i2g.html#wp1055528

R4#sh ip ospf int s1/0.34
Serial1/0.34 is up, line protocol is up
  Internet Address 10.1.1.10/30, Area 34, Attached via Network Statement
  Process ID 1, Router ID 10.1.4.9, Network Type POINT_TO_POINT, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 5, maximum is 5
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 3.3.3.3
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1
R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int s1/0.34
R4(config-subif)#no ip ospf authenti mess
R4(config-subif)#no ip ospf message-digest-key 1 md5 cisco
R4(config-subif)#
Feb  3 12:56:56.259: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0.34 from FULL to DOWN, Neighbor Down: Dead timer expired
R4(config-subif)#do sh ip ospf int s1/0.34
Serial1/0.34 is up, line protocol is up
  Internet Address 10.1.1.10/30, Area 34, Attached via Network Statement
  Process ID 1, Router ID 10.1.4.9, Network Type POINT_TO_POINT, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 5, maximum is 5
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)
  (no messass digest crap here where it's supposed to be)

R4(config-subif)#ip ospf authen mess
R4(config-subif)#ip ospf message-digest-key 1 md5 cisco
R4(config-subif)#end
Feb  3 12:57:42.875: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0.34 from LOADING to FULL, Loading Done
R4(config-subif)#end
R4#
Feb  3 12:57:45.391: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip ospf int s1/0.34
Serial1/0.34 is up, line protocol is up
  Internet Address 10.1.1.10/30, Area 34, Attached via Network Statement
  Process ID 1, Router ID 10.1.4.9, Network Type POINT_TO_POINT, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 5
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 3.3.3.3
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1