CCIE Pursuit Blog

May 6, 2008

Question Of The Day: 06 May, 2008

Topic: EIGRP

Limit r1’s FastEthernet0/0 interface to only be able to use up to 3Mbps for EIGRP traffic.

router eigrp 100
 no auto-summary
interface FastEthernet0/0
 ip address
 speed 100
 duplex full

Click Here For The Answer

Yesterday’s Question

Question Of The Day: 05 May, 2008 

Topic: BGP

Routers r1 and INET1 are directly connected via their respective FastEthernet interfaces.  Here are their BGP configurations:

r1#show run | sec router bgp
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 timers bgp 15 45
 neighbor remote-as 1
 no auto-summary

INET1#show run | sec router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor remote-as 65001
 no auto-summary

Will these two routers establish a BGP peering?

Answer: Yes.

The ‘trick’ to this question was that there is a bgp timers mismatch between the two routers.

bgp timers

keepalive: 60 seconds
holdtime: 180 seconds

r1 is using a keepalive timer of 15 seconds and a hold-time of 45 seconds.  INET1 has the default bgp timers of 60 seconds (keepalive) and 180 seconds (hold-time).  This is causing a bgp timers mismatch, BUT this will not cause the BGP neighbor relationship to fail:

BGP uses a keepalive timer to define how often that router sends BGP keepalive messages, and a Hold timer to define how long a router will wait without receiving a keepalive message before  resetting a neighbor connection. The Open message includes each router’s stated keepalive timer. If they do not match, each router uses the lower of the values for each of the two timers,respectively. Mismatched settings do not prevent the routers from becoming neighbors.

Reference: Page 352 of CCIE Routing and Switching Exam Certification Guide (3rd Edition)


  1. […] Question Of The Day: 06 May, 2008  […]

    Pingback by Question Of The Day: 12 May, 2008 « CCIE Pursuit — May 12, 2008 @ 9:13 am | Reply

  2. […] Click Here For The Answer […]

    Pingback by Question Of The Day: 05 May, 2008 « CCIE Pursuit — May 24, 2008 @ 3:38 pm | Reply

  3. […] engineers “solved” the problem by having AT&T set their BGP timers to match ours (see this QoD for an explanation of why that did not work) the issue came to me.  I suggested that we disable bgp fast-external-fallover and see if that at […]

    Pingback by Some Of This Crap Really Has Real World Implications :-) « CCIE Pursuit — May 24, 2008 @ 3:39 pm | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: