Pete's Packet

Limitless

  • Catagories

  • Global visitors

    free counters
  • RSS CCIE Jobs – Metro NY area

Archive for the ‘OSPF’ Category

%OSPF-5-ADJCHG 2WAY to DOWN, Neighbor Down: Dead timer expired

Posted by Peter Kurdziel on October 19, 2009

I am seeing the below error message on the OSPF router. What is causing this and what action should I take?
006805: May 13 21:14:11: %OSPF-5-ADJCHG: Process 65182, Nbr 172.16.1.252 on FastEthernet1 from 2WAY to DOWN, Neighbor
Down: Dead timer expired

you need to check few things:

  • both neighbors have the same hello and dead timers
  • both neighbors use the same subnet mask
  • both neighbors use the same authentication password (if it’s used)
  • make sure the MTU matches on both sides or add ip ospf mtu-ignore
  • debug ospf adj

Posted in OSPF, Q&A, Real World, Troubleshooting | Leave a Comment »

How do I advertise the true subnet mask of loopbacks

Posted by Peter Kurdziel on June 19, 2009

1.) redistribute connected (external) (acl / route-map)
2.) area x range (internal)
3.) ip ospf network type point-to-point (internal)

I am testing in my lab.

2 +3 worked.
Once have specified a proper network instead of using ” network 0.0.0.0 0.0.0.0” # 1 worked.

Posted in OSPF, Routing & Switching Lab | Leave a Comment »

OSPF stub notes

Posted by Peter Kurdziel on June 12, 2009

Stub area’s block type 5 LSA’s making type 4 LSA’s unnecessary; these LSA’s are also blocked. ref: Routing TCP/IP vol I second editon, page 386.
Totally Stubby also block type 3 lsa’s.
NSSA – allows external routes to be advertised into OSPF while retaining the characteristics of a stub area.

ASBR’s are not allowed in stub area’s.  They are allowed in NSSA areas.
stub – blocks 4,5
stub no-summ blocks 3,4,5
nssa – blocks 4,5 – originates type 7 LSA’s to advertise to external destinations. An ABR will block type 7 LSA’s ( will not advertise outside of the area) UNLESS the the P-bit is set to 1 = nssa translate type7 – YOU NEED TO ADD default-info originate for a default route.
nssa no-sum = blocks 3,4,5

With a stub area, no external routes can be propagated into it. You could use a stub area, for example, for a branch office that has no connection other than to head office. In that case, you might make it totally stubby, that is, give it only a default route.

An NSSA is a bit like a stub as far as the internal OSPF topology is concerned, but it is allowed to connect to the outside world. In other words, it is allowed to have an ASBR border router. Imagine you had a branch office that had an external link, say, to the Internet. You could run that as an NSSA, but not as a stub.

allowed LSA’a
area type 1&2 3 4 5 7
Backdone -Area 0 Yes Yes Yes Yes No
Non-Backdone, non-stub Yes Yes Yes Yes No
Stub Yes Yes No No No
Totally Stubby Yes No*& No No No
Not so stubby Yes Yes No No Yes
*single type3 per ABR, advertising a default route.

More info on nssa translate type7
The following example causes OSPF to translate Type-7 LSAs from area 1 to Type-5 LSAs, but not place the Type-7 forwarding address into the Type-5 LSAs. OSPF places 0.0.0.0 as the forwarding address in the Type-5 LSAs.

router ospf 2
network 172.19.92.0 0.0.0.255 area 1
area 1 nssa translate type7 suppress-fa

Posted in OSPF, Routing & Switching Lab | 2 Comments »

Passive-interface command behavior in RIP, EIGRP & OSPF

Posted by Peter Kurdziel on June 5, 2009

Passive-interface command behavior in RIP, EIGRP & OSPF

from http://networkers-online.com/blog/2008/08/how-to-avoid-dns-lookup-when-mistyping-a-command/

Passive-interface command is used in all routing protocols to disable sending updates out from a specific interface. However the command behavior varies from o­ne protocol to another.

In RIP this command will disable sending multicast updates via a specific interface but will allow listening to incoming updates from other RIP speaking neighbors.

This simply means that the router will still be able to receive updates o­n that passive interface and use them in the routing table.

In EIGRP the passive-interface command stops sending outgoing hello packets, hence the router can not form any neighbor relationship via the passive interface. This behavior stops both outgoing and incoming routing updates.

In OSPF the passive-interface has a similar behavior to EIGRP. The command suppresses hello packets and hence neighbor relationships.

I have o­nly o­ne final note here regarding sending unicast updates:

If you used the neighbor command under the RIP process, the router will send unicast updates as well as multicast updates.The passive-interface command must be used disable multicast updates and allowing o­nly unicast.

In EIGRP the neighbor command disables multicast updates o­n an interface by default and allows o­nly unicast updates.

Posted in EIGRP, OSPF, RIP, Routing & Switching Lab | Leave a Comment »

OSPF Path Types

Posted by Peter Kurdziel on May 27, 2009


Path Types

Intra-area
Destinations within the area

Inter-area (IA)
Destinations in another area but within the OSPF AS

Type 1 external (E1)
Destinations outside the OSPF AS
Total cost = external cost + cost to the ASBR

Type 2 external (E2)
Destinations outside the OSPF AS
Total cost = external cost

Posted in OSPF, Routing & Switching Lab | 1 Comment »

OSPF ABR default route (if a match is made in the route-map)

Posted by Peter Kurdziel on May 27, 2009

In this case, the ABR will only generate a default if some subnet within 10.1.1.0/24 is in the local routing table

default-information originate route-map default
route-map default permit 10
match ip address 10
!
access-list 10 permit 10.1.1.0 0.0.0.255

Posted in OSPF, Routing & Switching Lab | Leave a Comment »

OPSF Can Filter Routes in Three Places:

Posted by Peter Kurdziel on May 27, 2009

OPSF Can Filter Routes in Three Places:

When redistributing into OSPF, using route maps.
Filter received routes from the routing table (local only – still in database)

At the area border, using an ABR type 3 filter.
Filter routes advertised via Type 3 LSAs on an ABR (between areas)

On any router, between the OSPF database and the local routing table.
Filter routes on an ASBR (redistributed from another protocol)

OSPF can filter external routes at the ASBR redistributing the routes
Use a route map to permit or deny the correct routes
Prefix lists will also work in this application
router ospf 100
redistribute connected route-map externals subnets
….
route-map externals permit 10
match ip address 10
….
access-list 10 permit 10.1.0.0 0.0.1.0

An OSPF ABR can filter the routes inserted into a Summary LSA (Type 3)
Use a prefix list to permit the ABR to insert routes into the Summary LSA (Type 3) generated into Area 0

router ospf 100
area 1 filter-list prefix area1 out
….
ip prefix-list area1 seq 10 permit 10.1.0.0/24
ip prefix-list area1 seq 20 permit 10.1.1.0/24

Posted in OSPF, Routing & Switching Lab | Leave a Comment »

OSPF Stub Area’s

Posted by Peter Kurdziel on May 27, 2009

Stub Area = allows intra+inter LSA types but does not allow external. replace the Type 5 with a default route (use a summary default created by the ABR)
“area XX stub”

Total Stub Area = No Inter-Area routes allows intra routes and replaces summary(LSA3) and external with a default route (use the summary created by the ABR)
“area XX stub no-summary”

NSSA Area = Stub area with an ASBR in it allows intra + inter area routes but does not allow external (LSA5). Does allow redistribution and LSA 7. (only external routes are from the ASBR)
“area XX nssa”

NSSA Total Stub Area = Total Stub Area with an ASBR in it. Allows intra + adds a default route for summary. does not allow external but does allow redistribution.
“area XX nssa no-summary”

type
cmd

lsa
default route injected without :default-info originate?
stub area xx stub 1,2,3,4 yes
totally stubby area x stub no-summary 12, default of 3 yes
nssa area x nssa 1,2,3,4,7 no
not so totally stubby area x nssa no-summary 1,2, default of 3, 7 yes

=========
Stub areas don’t receive summary LSAs (type 3) from their ABR

Totally Stub areas don’t receive summary LSAs (type 3)  or external routing information (types 4 or 5) from their ABR

Not So Stubby Areas (NSSA)
Routes redistributed into OSPF are generated as NSSA externals (type 7) by the ASBR
The ABR converts these routes to externals (type 5)
The ABR generates a border router (type 4) LSA for the ASBR
The ABR does not flood any summary (type 3) LSAs into the area

Totally Not So Stubby Areas (Totally NSSA)
Routes redistributed into OSPF are generated as NSSA externals (type 7) by the ASBR
The ABR converts these routes to externals (type 5)
The ABR generates a border router (type 4) LSA for the ASBR
The ABR does not flood any summary (type 3) LSAs into the area
The ABR does not flood any external routing information (type 5) or border router (type 4) LSAs into the area

With a stub area, no external routes can be propagated into it. You could use a stub area, for example, for a branch office that has no connection other than to head office. In that case, you might make it totally stubby, that is, give it only a default route.

An NSSA is a bit like a stub as far as the internal OSPF topology is concerned, but it is allowed to connect to the outside world. In other words, it is allowed to have an ASBR border router. Imagine you had a branch office that had an external link, say, to the Internet. You could run that as an NSSA, but not as a stub.

=======

allowed LSA’a
area type 1&2 3 4 5 7
Backdone -Area 0 Yes Yes Yes Yes No
Non-Backdone, non-stub Yes Yes Yes Yes No
Stub Yes Yes No No No
Totally Stubby Yes No*& No No No
Not so stubby Yes Yes No No Yes
*single type3 per ABR, advertising a default route.

Posted in OSPF, Routing & Switching Lab | 1 Comment »

Troubleshooting OSPF notes

Posted by Peter Kurdziel on May 18, 2009

Troubleshooting OSPF notes from Routing TCP/IP vol2

Troubleshooting OSPF Neighbor Relationships

OSPF neighbor relationship problems can be of any of these types:

  • The OSPF neighbor list is empty.
  • An OSPF neighbor is stuck in ATTEMPT.
  • An OSPF neighbor is stuck in INIT.
  • An OSPF neighbor is stuck in 2-WAY.
  • An OSPF neighbor is stuck in EXSTART/EXCHANGE.
  • An OSPF neighbor is stuck in LOADING.

Problem: OSPF Neighbor List Is Empty

The most common possible causes of this problem are as follows:

  • OSPF is not enabled on the interface.
  • Layer 1/2 is down.
  • The interface is defined as passive under OSPF.
  • An access list is blocking OSPF Hellos on both sides.
  • A subnet number/mask has been mismatched over a broadcast link.
  • The Hello/dead interval has been mismatched.
  • The authentication type (plain text versus MD5) has been mismatched.
  • An authentication key has been mismatched.
  • An area ID has been mismatched.
  • Stub/transit/NSSA area options have been mismatched.
  • An OSPF adjacency exists with secondary IP addressing.
  • An OSPF adjacency exists over an asynchronous interface.
  • No network type or neighbor is defined over NBMA (Frame Relay, X.25, SMDS, and so on).
  • The frame-relay map/dialer map statement is missing the broadcast keyword on both sides

Problem: OSPF Neighbor Stuck in INIT

The most common possible causes of this problem are as follows:

  • An access list on one side is blocking OSPF Hellos.
  • Multicast capabilities are broken on one side (6500 switch problem).
  • Authentication is enabled on only one side (virtual link example).
  • The frame-relay map/dialer map statement on one side is missing the broadcast keyword.
  • Hellos are getting lost on one side at Layer 2.

Problem: OSPF Neighbor Stuck in 2-WAY—Cause: Priority 0 Is Configured on All Routers

Problem: OSPF Neighbor Stuck in EXSTART/EXCHANGE

The most common possible causes of this problem are as follows:

  • Mismatched interface MTU
  • Duplicate router IDs on neighbors
  • Inability to ping across with more than certain MTU size
  • Broken unicast connectivity because of the following:

- Wrong VC/DLCI mapping in Frame Relay/ATM switch

- Access list blocking the unicast

- NAT translating the unicast

  • Network type of point-to-point between PRI and BRI/dialer

Problem: OSPF Neighbor Stuck in LOADING

The most common possible causes of this problem are as follows:

  • Mismatched MTU
  • Corrupted link-state request packet

Troubleshooting OSPF Route Advertisement

The most common reasons for OSPF to not share the database information about a specific link are as follows:

  • The OSPF neighbor is not advertising routes.
  • The OSPF neighbor (ABR) is not advertising the summary route.
  • The OSPF neighbor is not advertising external routes.
  • The OSPF neighbor is not advertising the default route.

Problem: OSPF Neighbor Is Not Advertising Routes

The most common possible causes of this problem are as follows:

  • OSPF is not enabled on the interface that is supposed to be advertised.
  • The advertising interface is down.
  • The secondary interface is in a different area than the primary interface.

Problem: OSPF Neighbor (ABR) Not Advertising the Summary Route

The most common possible causes of this problem are as follows:

  • An area is configured as a totally stubby area.
  • An ABR is not connected to area 0.
  • A discontiguous area 0 exists.

Problem: OSPF Neighbor Is Not Advertising External Routes

The most common possible causes of this problem are as follows:

  • The area is configured as a stub or NSSA.
  • The NSSA ABR is not translating Type 7 into Type 5 LSA.

Problem: OSPF Neighbor Not Advertising Default Routes

The most common possible causes for an OSPF router not to advertise the default route are as follows:

  • The default-information originate command is missing.
  • The default route is missing from the neighbor’s routing table.
  • A neighbor is trying to originate a default into a stub area.
  • The NSSA ABR/ASBR is not originating the Type 7 default.

Troubleshooting OSPF Route Installation

The most common reasons for OSPF failing to install routes in the routing table are as follows:

  • OSPF is not installing any routes in the routing table.
  • OSPF is not installing external routes in the routing table.

Problem: OSPF Not Installing Any Routes in the Routing Table

The most common possible causes of this problem are as follows:

  • The network type is mismatched.
  • IP addresses are flipped in dual serial-connected routers or a subnet/mask mismatch has occurred.
  • One side is a numbered and the other side is an unnumbered point-to-point link.
  • A distribute list is blocking the routes’ installation.
  • There is a broken PVC in a fully meshed Frame Relay network with the broadcast network type.

Problem: OSPF Not Installing External Routes in the Routing Table

The most common causes of this problem are as follows:

  • The forwarding address is not known through the intra-area or interarea route.
  • The ABR is not generating Type 4 summary LSAs.

Troubleshooting Redistribution Problems in OSPF

The following are problems that can happen during redistribution:

  • ASBR is not advertising redistributed routes.
  • OSPF is not installing external routes in the routing table.

Problem: OSPF Neighbor Is Not Advertising External Routes

The most common causes of this problem are as follows:

  • The subnets keyword is missing from the ASBR configuration.
  • distribute-list out is blocking the routes.

Troubleshooting Route Summarization in OSPF

OSPF can use two types of summarization:

  • Interarea summarization that can be done on the ABR
  • External summarization that can be done on the ASBR

Two common problems related to summarization in OSPF are as follows:

  • A router is not summarizing interarea routes.
  • A router is not summarizing external routes.

Problem: Router Is Not Summarizing Interarea Routes

Cause: area range Command Is Not Configured on ABR

Problem: Router Is Not Summarizing External Routes

Cause: summary-address Command Is Not Configured on ASBR

Troubleshooting CPU HOG Problems

The CPUHOG messages usually appear in two significant stages:

  • Neighbor formation process
  • LSA refresh process

This section discusses the possible solutions for these two instances of SPF:

  • CPUHOG messages during adjacency formation
  • CPUHOG messages during LSA refresh period

Problem: CPUHOG Messages During Adjacency Formation

—Cause: Router Is Not Running Packet-Pacing Code

Problem: CPUHOG Messages During LSA Refresh Period

—Cause: Router Is Not Running LSA Group-Pacing Code

Troubleshooting SPF Calculation and Route Flapping

The problem of SPF running constantly in the network for the following reasons:

  • Interface flap within the network
  • Neighbor flap within the network
  • Duplicate router ID

Common OSPF Error Messages

“Unknown routing protocol” Error Message = the software or the hardware does not support OSPF

OSPF: “Could not allocate router id” Error Message =

This message appears in two situations:

  • No up/up interface with a valid IP address
  • Not enough up interfaces with a valid IP address for multiple OSPF processes

“%OSPF-4-BADLSATYPE: Invalid lsa: Bad LSA type” Type 6 Error Message

This is normal if the neighboring router is sending the multicast OSPF (MOSPF) packet. For more information on MOSPF, refer to RFC 1584. Cisco routers do not support MOSPF, so they simply ignore it

ignore lsa mospf

“OSPF-4-ERRRCV” Error Message

Three common types of this message can occur:

  • Mismatch area ID
  • Bad checksum
  • OSPF not enabled on the receiving interface

Posted in OSPF, Real World, Routing & Switching Lab | Leave a Comment »

some redistribution tips

Posted by Peter Kurdziel on May 5, 2009

 

advertise l0 into rip w/o the net cmd and a metric of 10
r1
interface Loopback0
 ip address 150.1.1.1 255.255.255.0
 ip ospf network point-to-point
end
route-map CONNECTED>RIP permit 10
 match interface Loopback0
 
router rip
 version 2
 redistribute connected metric 10 route-map CONNECTED>RIP
 network 140.1.0.0
 no auto-summary
r4
Rack1R4(config-router)#   do sho ip route rip
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:00, Ethernet0/0
==================================================
r5 rip routes = 500  / r4 routes = 400
Rack1R5(config)#router os 1  
Rack1R5(config-router)#$bute rip metric 500 subnets route-map OSPF>RIP       
Rack1R5(config-router)#no route-map OSPF>RIP
Rack1R5(config)#route-map RIP>OSPF
Rack1R5(config-route-map)#set metric 500
Rack1R5(config-route-map)#router ospf 1
Rack1R5(config-router)#redistribute rip subnets route-map RIP>OSPF
Rack1R5(config-router)#
this did not work right because  I was limiting what routes were tagged with 500 because in the first route mp OSPF>RIP is matched the interface.

advertise loop0  into rip w/o the net cmd and a metric of 10

r1

interface Loopback0

 ip address 150.1.1.1 255.255.255.0

 ip ospf network point-to-point

end

 

route-map CONNECTED>RIP permit 10

 match interface Loopback0

 

router rip

 version 2

 redistribute connected metric 10 route-map CONNECTED>RIP

 network 140.1.0.0

 no auto-summary

 

r4

Rack1R4(config-router)#   do sho ip route rip

     150.1.0.0/24 is subnetted, 10 subnets

R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:00, Ethernet0/0

 

 

==================================================

 

r5 rip routes = 500  / r4 routes = 400

 

Rack1R5(config)#router os 1  

Rack1R5(config-router)#$bute rip metric 500 subnets route-map OSPF>RIP       

Rack1R5(config-router)#no route-map OSPF>RIP

Rack1R5(config)#route-map RIP>OSPF

Rack1R5(config-route-map)#set metric 500

Rack1R5(config-route-map)#router ospf 1

Rack1R5(config-router)#redistribute rip subnets route-map RIP>OSPF

Rack1R5(config-router)#

this did not work right because  I was limiting what routes were tagged with 500 because in the first route mp OSPF>RIP it was matching the interface.

Posted in OSPF, Redistribution, RIP, Routing & Switching Lab | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.