Pete's Packet

Limitless

Archive for November, 2008

r RIB-failure

Posted by Peter Kurdziel on November 13, 2008

Q. What does r RIB-Failure mean in the show ip bgp command output?bestpath prefix into Routing Information Base (RIB) (for example, the IP Routing table), RIB might reject the BGP route due to any of these reasons:

 

R1> show ip bgp
BGP table version is 5, local router ID is 200.200.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
r> 6.6.6.0/24       10.10.13.3               0    130      0 30 i
*> 7.7.7.0/24       10.10.13.3               0    125      0 30 i

When BGP tries to install the

  • Route with better administrative distance already present in IGP. For example, if a static route already exists in IP Routing table.
  • Memory failure.
  • The number of routes in VPN routing/forwarding (VRF) exceeds the route-limit configured under the VRF instance.

In such cases, the prefixes that are rejected for these reasons are identified by r RIB Failure in the show ip bgp command output and are not advertised to the peers. This feature was first made available in Cisco IOS Software Release 12.2(08.05)T.

 

reference: BGP FAQ

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#twenty-three

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

what is the bgp rule of synchronization

Posted by Peter Kurdziel on November 12, 2008

With synchronization enabled, BGP will not advertise routes to an EBGP speaker unless that route is also known via the IGP protocol.

 

Synchronization

When an AS provides transit service to other ASs and if there are non-BGP routers in the AS, transit traffic might be dropped if the intermediate non-BGP routers have not learned routes for that traffic via an IGP. The BGP synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP. The topology shown in demonstrates the synchronization rule.

Figure 12-6 Synchronization

 

 

In , Router C sends updates about network 170.10.0.0 to Router A. Routers A and B are running IBGP, so Router B receives updates about network 170.10.0.0 via IBGP. If Router B wants to reach network 170.10.0.0, it sends traffic to Router E. If Router A does not redistribute network 170.10.0.0 into an IGP, Router E has no way of knowing that network 170.10.0.0 exists and will drop the packets.

If Router B advertises to AS 400 that it can reach 170.10.0.0 before Router E learns about the network via IGP, traffic coming from Router D to Router B with a destination of 170.10.0.0 will flow to Router E and be dropped.

This situation is handled by the synchronization rule of BGP, which states that if an AS (such as AS 100 in ) passes traffic from one AS to another AS, BGP does not advertise a route before all routers within the AS (in this case, AS 100) have learned about the route via an IGP. In this case, Router B waits to hear about network 170.10.0.0 via an IGP before it sends an update to Router D. In some cases, you might want to disable synchronization. Disabling synchronization allows BGP to converge more quickly, but it might result in dropped transit packets.

You can disable synchronization if one of the following conditions is true:

Your AS does not pass traffic from one AS to another AS.

All the transit routers in your AS run BGP.

shows a topology in which it is desirable to disable synchronization.

Figure 12-7 Disabled Synchronization

 

 

The following commands configure Routers A, B, and C:

!Router A

network 150.10.0.0

neighbor 3.3.3.4 remote-as 100

neighbor 2.2.2.1 remote-as 300

no synchronization

!Router B

router bgp 100

network 150.10.0.0

neighbor 1.1.1.2 remote-as 400

neighbor 3.3.3.3 remote-as 100

no synchronization

!Router D

router bgp 400

neighbor 1.1.1.1 remote-as 100

network 175.10.0.0

The no synchronization router configuration command causes Router B to put 170.10.0.0 in its IP routing table and advertise it to Router D without learning network 170.10.0.0 via an IGP.

Reference: Using the Border Gateway Protocol for Interdomain Routing http://www.cisco.com/en/US/docs/internetworking/case/studies/icsbgp4.html#wp19382

 

Posted in BGP, Routing & Switching Lab | 3 Comments »

Narbiks’ CCIE routing and switching bootcamp

Posted by Peter Kurdziel on November 12, 2008

I can not say enough good things about Narbik and his bootcamp. I think he has hit the nail on the head with this course. He is very knowledgeable and a real funny guy. There is a lot of material that Narbik covers and tons and tons of labs. The material is presented in a way that is easy to understand. No bs and straight to the point. Take each technology and explore it in depth.

I have worked through various vendors workbooks and they are all similar. How many different ways can they ask you the same questions (Lot’s I know but after a while you start to see similarities and no doubt the actual lab is the same thing).

Narbik’s can charge over double if not triple for his bootcamp but his goal is to help you pass without spending too much money.  You can see how he goes out of his way on the forums, via email and over the phone to help you succeed. ( some vendors want to charge you for that. )

If everyone was a generous forthright as Narbik is then the world would be a better place. I can’t sleep at night waiting in anticipation for the next day. 

Job well done Narbik.

Posted in Routing & Switching Lab | 1 Comment »

%BGP-3-NOTIFICATION: received from neighbor 183.1.17.1 2/2 (peer in wrong AS) 2 bytes 0064

Posted by Peter Kurdziel on November 7, 2008

*Mar  1 03:25:26.251: BGP: 183.1.17.7 bad OPEN, remote AS is 100, expected 200
*Mar  1 03:25:26.251: BGP: 183.1.17.7 went from OpenSent to Closing
*Mar  1 03:25:26.251: %BGP-3-NOTIFICATION: sent to neighbor 183.1.17.7 2/2 (peer in wrong AS) 2 bytes 0064 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0064 00B4 9601 0707 1002 0601 0400 0100 0102 0280 0002 0202 00
*Mar  1 03:25:26.255: BGP: 183.1.17.7 send message type 3, length (incl. header) 23
*Mar  1 03:25:26.363: BGP: 183.1.17.7 local error close after sending NOTIFICATION
*Mar  1 03:25:26.367: BGPNSF state: 183.1.17.7 w
Rack1R1#ent from nsf_not_active to nsf_not_active
*Mar  1 03:25:26.367: BGP: 183.1.17.7 went from Closing to Idle
*Mar  1 03:25:26.367: BGP: 183.1.17.7 closing
*Mar  1 03:25:27.383: BGP: 183.1.17.7 went from Idle to Active
*Mar  1 03:25:27.395: BGP: 183.1.17.7 open active delayed 27694ms (35000ms max, 28% jitter)
Rack1R1#
*Mar  1 03:25:55.091: BGP: 183.1.17.7 open active, local address 183.1.17.1
*Mar  1 03:25:55.275: BGP: 183.1.17.7 went from Active to OpenSent


TYPO WAS CORRECTED

*Mar  1 03:25:55.279: BGP: 183.1.17.7 sending OPEN, version 4, my as: 200, holdtime 180 seconds
*Mar  1 03:25:55.287: BGP: 183.1.17.7 send message type 1, length (incl. header) 45
*Mar  1 03:25:55.355: BGP: 183.1.17.7 rcv message type 1, length (excl. header) 26
*Mar  1 03:25:55.359: BGP: 183.1.17.7 rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 03:25:55.359: BGP: 183.1.17.7 rcv OPEN w/ OPTION parameter len: 16
*Mar  1 03:25:55.363: BGP: 183.1.17.7 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 03:25:55.363: BGP: 183.1.17.7 OPEN has CAPABILITY code: 1, length 4
*Mar  1 03:25:55.367: BGP: 183.1.17.7 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 03:25:55.367: BGP: 183.1.17.7 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 03:25:55.367: BGP: 183.1.17.7 OPEN has CAPABILITY code: 128, length 0
*M
Rack1R1#ar  1 03:25:55.367: BGP: 183.1.17.7 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 03:25:55.367: BGP: 183.1.17.7 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 03:25:55.367: BGP: 183.1.17.7 OPEN has CAPABILITY code: 2, length 0
*Mar  1 03:25:55.367: BGP: 183.1.17.7 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 183.1.17.7 rcvd OPEN w/ remote AS 200
*Mar  1 03:25:55.367: BGP: 183.1.17.7 went from OpenSent to OpenConfirm
*Mar  1 03:25:55.367: BGP: 183.1.17.7 went from OpenConfirm to Established
*Mar  1 03:25:55.367: %BGP-5-ADJCHANGE: neighbor 183.1.17.7 Up

Solution: typo on switch.
This is some good stuff here showing the BGP message states. (see the bold)

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

CCIE ROUTING AND SWITCHING TRACK Lab Study and Exam Tips

Posted by Peter Kurdziel on November 7, 2008

Please review the Lab Exam Overview for general information about the lab exam. The information below is meant to help you prepare for the lab exam.

STUDY TIPS

Assessing Strengths
Using the content blueprint, determine your experience and knowledge in the major topic areas. For areas of strength, practicing for speed should be your focus. For weak areas, you may need training or book study in addition to practice.

Study Materials
Choose lab materials that provide configuration examples and take a hands-on approach. Look for materials that are approved or provided by Cisco and its Learning Partners.

Hands-On Practice
Build and practice lab scenarios on a per topic basis. Go beyond the basics and practice additional features. Learn the show and debug commands along with each topic. If a protocol has multiple ways of configuring a feature, practice all of them.

Cisco Documentation CD
Make sure you can navigate the Cisco documentation CD with confidence because this is the only resource you will be allowed during the lab. Make the CD part of your regular study; if you are familiar with it, you can save time during the exam. As of March 2006, the documentation can only be navigated using the index; the search function has been disabled.

Home Labs
Although acquiring a personal home lab is ideal, it can be costly to gather all the equipment you will need. For the hardware devices that are costly to obtain, you may be able to rent the equipment online at a more reasonable cost.

TEN TIPS FOR TAKING THE LAB EXAM

  1. Read the entire exam first and check for addressing issues. Do not skip any details or sections.
  2. Manage your time. Make a plan to cover all the sections in the time provided. Work out how much time you will spend on each section, keeping in mind the point value of the questions. Don’t forget to allow time at the end to verify your solutions.
  3. Clarify the requirements of each question. Don’t assume requirements that aren’t mentioned in the question. During the lab, if you are in any doubt, verify your understanding of the question with the proctor.
  4. Do each question as a unit. Configure and verify before moving to the next question. You may want to redraw the topology with all the details available. This will help you visualize and map the network.
  5. Troubleshoot. You must know how to troubleshoot using the tools available. Although troubleshooting is important, don’t lose too much time working on a 2- or 3-point question. If you’re caught off-guard by an unfamiliar topic, don’t let it absorb too much time. Work on the things you are more comfortable with and go back to difficult items later.
  6. Keep a list. During the exam, make notes on configurations and settings as you move through the exam. Make a separate list for items you have not been able to address or where you have not achieved the desired result which you’ll need to revisit.
  7. Test your work. Never rely on a configuration done in the early hours of the exam. There is a possibility that an item you configured a few sections earlier can become broken and non-functional. Keep in mind that points are awarded for working configuration only.
  8. Save your configurations often.
  9. Don’t make any drastic changes in the last half hour of the exam.
  10. Speed is vital on the exam. Review and practice core material the week before the exam to ensure you can move quickly through the less challenging questions.

Reference: http://www.cisco.com/web/learning/le3/ccie/rs/lab_exam_tips.html

Posted in Routing & Switching Lab | Leave a Comment »

Reasons why people Fail the Lab Exam!

Posted by Peter Kurdziel on November 7, 2008

Reasons why people Fail the Lab Exam!

Reason 1: “I was on no/little sleep!”
• Nerves
• Caffeine
• Abnormal routine
• Cramming
• Abnormal environment

Reason 2: “I ran out of time!”
• Practice, Practice, Practice
• Speed drills
• Overall strategy approach
• Specific strategies
• Adherence to time management practices

Reason 3: “The proctor was not helpful at all!”
• Be Nice!
• Demonstrate knowledge
• Be specific
• Communicate you are not looking for an answer – request clarification
• Try another – try again

Reason 4: “I got tons of topic XYZ!”
• FOCUS ON YOUR WEAK AREAS!!!!!!!

Reason 5: “Too stressed out at that point in my life!”
• Stress mitigation techniques
• Rescheduling the lab

Reason 6: “I was physically sick for the lab!”
• Stress mitigation techniques

Reason 7: “I had absolutely no chance to pass that lab!”
• Formalized CCIE training!

Reason 8: “I HAVE NO IDEA WHY I FAILED!!!!”
• Task misinterpretation
• Poor verification techniques

reference:http://freeiestuff.com/fail.aspx

Posted in Routing & Switching Lab | Leave a Comment »

OSPF stuck on Init

Posted by Peter Kurdziel on November 7, 2008

I ran into a problem with a neightbor stuck in Init.

The problem was when I loaded my lab in GNS3. I had some dynamic frame-relay mappings even through I had no shut that off in my config.  I cleared them with clear frame in and made sure my configs were correct. The neighbor came up and all is well.

For some reason GNS3 is pulling an old config from somewhere. I noticed lots of weird stuff with GNS3/dynamips. I spent hours tweaking things and I think I have it working the way it’s supposed to now.

Posted in Routing & Switching Lab | Leave a Comment »

redistribute connected

Posted by Peter Kurdziel on November 6, 2008

What is the difference between these two.

redistribute connected metric 10000 100 255 1 1500 route-map CONNECTED->EIGRP

redistribute connected route-map CONNECTED->EIGRP metric 10000 100 255 1 1500

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

Nothing, both will do the samething,=.

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

BGP notes

Posted by Peter Kurdziel on November 6, 2008

  1. BGP is designed to perform next-hop AS packet forwarding.
  2. BGP path selection is based upon policy-routing.
  3. A BGP speaker must never advertise a prefix it does not know to get to.

The advertising EBGP speaker sets the next hop attribute and prepends the as path list.

By default the advertising IBGP speaker does not set the next hop attribute or prepend the as path list.  You can make the IBGP speaker set the next hop attribute by configuring the ” neightbor x.x.x.x next-hop-self” command.

Some useful commands:

  • debug bgp all events
  • debug bgp ipv4 unicast
  • debug bgp ipv4 unicast keepalives
  • debug ip error
  • debug ip bgp updates

EBGP – not directly connected:

  • nei x.x.x.x ebgp-multihop <hop>

or

  • nei x.x.x.x ttl-security hop <hop>
  • do I need the nei x.x.x.x update-source Y{z} command?

neigh x.x.x.x ttl-security hops 3 < — external neighbor maybe up to 3 hops away. (255-3 = max 252 hops away.

on the neighbor: nei x.x.x.x ebgp-multihop 255 – don’t forget ttl decrements. Use 255 for neighors of ttl sec

To originate a prefix in BGP:

network x.x.x.x mask y.y.y.y

By default, advertising EBGP speaking routers set the BGP next-hop attribute.

By default, advertising IBGP speaking routers DO NOT set the BGP next-hop attribute.

Route reflector:

RR servers propagate routes inside the AS based on the following rules:

  • If a route is received from nonclient peer, reflect to clients only.
  • If a route is received from a client peer, reflect to all nonclient peers and also to client peers, except the originator of the route.
  • If a route is received from an EBGP peer, reflect to all client and nonclient peers.

Setting the cluster-id with the IOS.

  1. use the BGP router-id x.x.x.x command.
  2. use the BGP cluster-id x.x.x.x command.

* when both commands are used the BGP cluster-id x.x.x.x takes precedence.

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

IOS bug: ROM: 3600 Software (C3640-JK9O3S-M), Version 12.3(14)T7, RELEASE SOFTWARE (fc2)

Posted by Peter Kurdziel on November 5, 2008

Rack1SW2(config)#int range f1/7 , f1/9 , f1/10 – 11
Rack1SW2(config-if-range)#sw    <—– cmd didn’t take!!
Rack1SW2(config-if-range)#sw mo tr
Command rejected: Fa1/9 not a switching port.
Command rejected: Fa1/10 not a switching port.
Rack1SW2(config-if-range)#sw tr en dot
Command rejected: Fa1/9 not a switching port.
Command rejected: Fa1/10 not a switching port.
Rack1SW2(config-if-range)#
Rack1SW2(config-if-range)#int f1/9
Rack1SW2(config-if)#sw <— took it now.

Posted in Uncategorized | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.