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.