Pete's Packet

Limitless

Archive for May, 2009

Day 114 Narbik IP services

Posted by Peter Kurdziel on May 22, 2009

I ma going through Narbiks IP Services workbook.

I ran into a problem with GLBP state flapping but that was due to the way the timers were set in the lab.

I have a mock lab scheduled for this Sunday. :)

Posted in Routing & Switching Lab | Leave a Comment »

Day 116

Posted by Peter Kurdziel on May 20, 2009

I completed Narbiks NAT labs and I read some notes on VLANS, Spanning Tree, OSPF, RIP and router management.

Posted in Routing & Switching Lab | Leave a Comment »

Troubleshooting BGP notes

Posted by Peter Kurdziel on May 18, 2009

Notes from Routing TC/IP

Troubleshooting BGP Neighbor Relationships

The following is the list of problems most commonly seen when forming BGP neighbor relationships.

  • Directly connected external BGP neighbors not initializing
  • Nondirectly connected external BGP neighbors not initializing
  • Internal BGP neighbors not initializing
    • The causes of this problem are identical to the previous problem of nondirectly connected external BGP neighbors not coming up:
      • The route to the nondirectly connected IBGP neighbor address is missing.
      • The update-source interface command is missing in BGP configuration.
  • BGP neighbors (external and internal) not initializing
    • Cause: Interface Access List Blocking BGP Packets

Troubleshooting BGP Route Advertisement /Origination and Receiving

The following is a list of problems discussed in this section related to BGP route originating and advertisement:

  • A BGP route not getting originated
    • Several causes in failure of BGP route origination exist, the most common of which are as follows:
      • The IP routing table does not have a matching route.
      • A configuration error has occurred.
      • BGP is autosummarizing to a classful/network boundary.
  • Problem in propagating/originating a BGP route to IBGP/EBGP neighbors
    • Cause: Misconfigured Filters
  • Problem in propagating a BGP route to an IBGP neighbor but not to an EBGP neighbor
    • Cause: BGP Route Was from Another IBGP Speaker
  • Problem in propagating an IBGP route to an IBGP/EBGP neighbor
    • Cause: IBGP Route Was Not Synchronized

Troubleshooting BGP Route Not Installing in Routing Table

Following is the list of all problems discussed in this section:

  • An IBGP-learned route is not getting installed in the IP routing table.
    • The most common causes of this problem are as follows:
      • IBGP routes are not synchronized.
      • The BGP next hop is not reachable.
  • An EBGP-learned route is not getting installed in the IP routing table.
    • The most common causes of EBGP routes not getting installed are as follows:
      • BGP routes are dampened.
      • The BGP next hop is not reachable in case of multihop EBGP.
      • The multiexit discriminator (MED) value is infinite.

Troubleshooting BGP Route-Reflection Issues

The most common problems in route-reflection networks are as follows:

  • Configuration mistakes
    • Cause: Failed to Configure IBGP Neighbor as a Route-Reflector Client
  • An extra BGP updated stored by a route-reflector client
    • Cause: Client-to-Client Reflection
  • Convergence time improvement for route reflectors and clients
    • Cause: Use of Peer Groups
  • Loss of redundancy between route reflectors and route-reflector clients
    • Cause: Cluster List Check in RR Drops Redundant Route from Other RR

Troubleshooting Outbound IP Traffic Flow Issues Because of BGP Policies

Here is the list of the most common problems encountered in managing outbound traffic flow:

  • Multiple exit points exist, but traffic goes out through one or a few exit routers.
    • Cause: BGP Policy Definition Causes Traffic to Exit from One Place
  • Traffic takes a different interface from what is shown in the routing table.
    • Cause: Next Hop of the Route Is Reachable Through Another Path
  • A multiple BGP connection exists to the same BGP neighbor, but traffic goes out through only one connection.
    • Cause: BGP Neighbor Is Influencing Outbound Traffic by Sending MED or Prepended AS_PATH
  • Asymmetrical routing occurs and it causes a problem especially when NAT and time-sensitive applications are used.
    • Cause: Outbound and Inbound Advertisement

Troubleshooting Load-Balancing Scenarios in Small BGP Networks

  • Problem: Load Balancing and Managing Outbound Traffic from a Single Router When Dual Homed to Same ISP
    • Cause: BGP Installs Only One Best Path in the Routing Table
    • Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network
      • Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist

Troubleshooting Inbound IP Traffic Flow Issues Because of BGP Policies

Some of the most common problems in managing inbound IP traffic in an AS using BGP are as follows:

  • Multiple connections exist to an AS, but all the traffic comes in through one BGP neighbor, X, in the same AS.
    • Cause: Either BGP Neighbor at X Has a BGP Policy Configured to Make Itself Preferred over the Other Peering Points, or the Networks Are Advertised to Attract Traffic from Only X
  • A BGP neighbor in AS 110 should just be a backup provider, but some traffic from Internet still comes through AS 110.
    • Cause: Route Advertisements for 100.100.100.0/24 in AS 109 Attract Internet Traffic Through That BGP Neighbor in AS 110
  • Asymmetrical routing occurs.
  • Traffic to a certain subnet should come through a particular connection, but it is coming from somewhere else.

Troubleshooting BGP Best-Path Calculation Issues

The following are the cases discussed in this section:

  • When the router ID (RID) selects the best path, BGP does not always select the lowest RID path as best, as described in the best-path algorithm.
  • Two BGP neighbors in the same AS advertise a different MED for the same prefix, but the lowest MED is not selected as best, as described in the best-path algorithm.

Troubleshooting BGP Filtering

Problem: Standard Access List Fails to Capture Subnets

  • Use extended access lists or prefix lists that support proper mask check of routes when received in BGP.

Problem: Extended Access Lists Fails to Capture the Correct Masked Route

  • Use an extended access list.
  • Use a prefix list.

Problem: AS_PATH Filtering Using Regular Expressions

Posted in BGP, Real World, Routing & Switching Lab | Leave a 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 | 1 Comment »

Troubleshooting RIP notes

Posted by Peter Kurdziel on May 18, 2009

Notes from Routing TCP/IP vol2

Problem: RIP Routes Not in the Routing Table

The possible causes for this problem are as follows:

  • Missing or incorrect network statement
  • Layer 2 down
  • Distribute list blocking the route
  • Access list blocking RIP source address
  • Access list blocking RIP broadcast/multicast
  • Incompatible version type
  • Mismatch authentication key (RIP-2)
  • Discontiguous network
  • Invalid source
  • Layer 2 problem (switch, Frame Relay, other Layer 2 media)
  • Offset list with a large metric defined
  • Routes that reached RIP hop-count limit
  • Sender problem

Problem: RIP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-path Command Restricts RIP from Installing More Than One Path

By default, Cisco routers support only four equal paths for the purpose of load balancing. The maximum-path command can be used for up to six equal-cost paths. If the command is not configured properly, it can cause a problem, as discussed in this section. When con-figured improperly, the maximum-path command allows only one path to the destination, even though more than one path exists. Configuring the command as maximum-path 1 should be done only when load balancing is not desired.

Troubleshooting RIP Routes Advertisement

Two of the most prevalent problems that can go wrong on the sender’s end deal with RIP route advertisement:

  • The sender is not advertising RIP routes.
  • Subnetted routes are missing.

Problem: Sender Is Not Advertising RIP Routes

causes of the problem

  • Missing or incorrect network statement
  • Outgoing interface that is down
  • distribute-list out blocking the routes
  • Advertised network interface that is down
  • Outgoing interface defined as passive
  • Broken multicast capability (encapsulation failure in Frame Relay)
  • Misconfigured neighbor statement
  • Advertised subnet is VLSM
  • Split horizon enabled

Problem: Subnetted Routes Missing from the Routing Table of R2—Cause: Autosummarization Feature Is Enabled

Solution: no auto-summary

Troubleshooting Routes Summarization in RIP

  • Autosummarization is off.
  • ip summary-address is not used

Problem: RIP-2 Routing Table Is Huge— Cause: Autosummarization Is Off

Solution: no auto-summary

Problem: RIP-2 Routing Table Is Huge— Cause: ip summary-address Is Not Used

Troubleshooting RIP Redistribution Problems

Any update with a metric greater than 15 will not be considered for entry into the routing table.

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

Day 118 Narbiks NAT labs – notes

Posted by Peter Kurdziel on May 18, 2009

notes

match-host  – translate to matching host ex x.x.x.10 = x.x.x.10
——

When someone tries to telnet to 131.1.14.1 (r1 s0/0.14) redirect it to 10.1.123.2 (r2 f0/0).

R1
ip nat inside source static tcp 10.1.123.2 23 interface s1/0.14 23
int f0/0
ip nat inside

int s0/0.14
ip nat outside

Posted in Routing & Switching Lab | Leave a Comment »

Day 120 started Narbiks NAT labs

Posted by Peter Kurdziel on May 16, 2009

Day 120 – I started Narbiks NAT labs.

Posted in Routing & Switching Lab | Leave a Comment »

Day 122 I reread “routing TCP/IP Vol 2′s” bgp section.

Posted by Peter Kurdziel on May 14, 2009

Day 122 – I reread “routing TCP/IP Vol 2′s” bgp section.
maximum-paths – changes the default number of parallel paths from 1 t o6.

keepalive default is 60 seconds , holdtime 180 seconds

you can write the as # two way was router bgp 111 or router bgp 111.111

aa:nn = as / community #
ex as 625 community value 70
625:70 convert to hex
625= 271 or 0×0271
70= 46 or 0×0046
now cisco’s community values use decimal
so 02710046 is 40960070 in decimal aka 625:70

Internet – no community value
NO_EXPORT – community value 4294967041 or 0xffffff01- not advertised to EBP of outside of a confederation
NO_ADVERTISE – community value 4294967042 or 0xffffff02 -not advertised to anyone.
LOCAL_AS – community value 4294967043 or 0xffffff03 -not advertised to EBGP, including peers in other AS’s within a confederation.

path
highest weight
highest local-pref
locally originated route
shortest as-path
lowest origin code IBPG vs EBGP vs incomplete
lowest MED
Prefer EBGP routers over confederation EBGP routes and prefer confederation EBGP routes over IBGP routes
shortest path to the next_hop
if maximum-paths is enabled install all equal cost paths into the Loc_RIB
if multipath is not enabled, prefer the route with the lowest BGP router ID

Community Description
Local-AS Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS).
no-export Do not advertise to external BGP (eBGP) peers. Keep this route within an AS.
no-advertise Do not advertise this route to any peer, internal or external.
none Apply no community attribute when you want to clear the communities associated with a route.
internet Advertise this route to the internet community, and any router that belongs to it.

rule of synchronization
routes learned by IBGP must also be in the IGP routing table. Synchronization prevents packets from being black holed by the transit AS because the IGP does not have the route.
With a full mesh synchronization stands in the way because all IBGP routers know about the route anyway and are using an IGP for BGP connectivity vs advertising the route via an IGP.

Tools for large scale BGP
peer groups – apply policies to a group of routers
communities – apply policies to a group of routes
route reflectors
confederations

RR rules
1. if a route was learned from a nonclient IBGP peer, it’s reflected to clients only.
2. if a route was learned from a client, it’s reflected to clients and non clients.
3. if a route was learned from an EBGP peer, it’s reflected to clients and non clients.

I am moving on to complete the BGP labs  I wanted to review yesterday.

Lab 11 task 6 =For ORF, don’t forget to config ADDRESS-FAMILY IPV4 UNICAST !!!!!!!!!!

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

Day 122 – lists and maps

Posted by Peter Kurdziel on May 14, 2009

I found this on groupstudy, posted by Jared from ipexpert.

1. distribute-list: filter routing updates for Distance Vector routing
protocols and BGP using an ACL. Filter updates from the OSPF database into
the routing table.

2. prefix-list: filter routing updates for BGP to neighbors or in a
route-map using a prefix-list. Filter OSPF announcements on an ABR into an
area.
3. filter-list: filter BGP updates between neighbors or in a route-map.

4. access-list: where do I begin? I’ll leave that one for you someone
else to explain as I don’t have the time. :)

5. as-path access-list: Same thing as number 3.

6. offset list: Adds to the metric of Distance Vector protocols.

7. advertise-list: conditional bgp routing

8. MQC: class map, policy map, service policy – classify types of
traffic, do something to the traffic, apply the policy

9. route-map: Used as input in a number of different functions. Broken
into statements that either permit or deny themselves to be processed. Each
statement matches traffic (explicitly or all if not specified) and can then
optionally set a parameter.

10. table-map: modifies BGP update information prior to copying it to the
appropriate RIB depending on address family (that’s how it works for IPv4
and should be designed for other protocols if it is not already)

11. advertise map: Advertises a specific network based on a conditional
statement being true.

12. unsuppress map: Takes a BGP update that is already suppressed
generally to all neighbors due to an aggregate-address and then allows it to
be sent to particular neighbors.

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

Day 123 Narbik BGP lab review

Posted by Peter Kurdziel on May 13, 2009

I want to do these labs again:

Lab 6 task 8 – community attributes

Lab 9 task 3

Lab 11 task 6

Lab 12

Lab 13 task 6

Short day today due to other obligations.

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

 
Follow

Get every new post delivered to your Inbox.