CCIE Pursuit Blog

May 6, 2008

Fun With ISPs

Filed under: BGP,Cisco,Work — cciepursuit @ 9:57 am
Tags:

Michael Morris recently vented a bit about CO techs (‘No Love For Central Office Techs’).  While I can’t agree with him about the value of unions (my father was in the IBEW and my mother is in the UAN, both of which saved our family’s ass when times were tough) I do agree with him about the flippant attitude one often encounters with carriers/LECs.  I had an interesting experience about a month ago.

A DS3 link was up and up but the BGP peering was idle.  I bounce the interface, cleared the BGP adjacency, deleted and re-added the BGP configuration, and I (eventually) reloaded the router.  Nothing changed.  The interface was up and up (I could see traffic flowing in and out of the interface) but the BGP peering would not establish. I brought our ATM subject matter expert (my ATM skills are weak) to look at the issue and he verified that ATM was working correctly.  I even looped the interface and was able to ping my interface IP address.  For whatever reason I had no layer 3 connectivity to the PER.

So I opened a ticket with AT&T and pushed them to get their BGP team involved.  They successfully tested the circuit to the CO.  Since this was a DS3 they did not have an NIU to loop at our premises.  I told them that they needed to get someone to verify the PER’s configuration (especially the BGP configuration).  They eventually verified the PER configuration.  I opened a TAC case to get the DS3 card replaced.  While the RMA was cooking, I put up a loop on my interface and asked ATT to test to it.  They successfully tested to the loop.  I dropped my loop.  Luckily, that’s when the break came.

“Thanks for your time, I’ll get Cisco to replace our card.”
“No problem.  I just ran another pattern to your loop and it was good as well.”
“Huh?”
“I just ran another pattern to your loop…”
“My loop?”
“Yes.”
“I dropped my loop 15 minutes ago.”
“Umm….”
“Are you testing the right circuit.”
“Yes.”
“Can you send a loopdown code.”
“I just did and I can still see your loop.”
“Is there a loop in the CO?”
“We’ll contact the LEC to look at that.”

Two hours later I get a call from an AT&T tech…well kind of.  The LEC for this area is SBC.  SBC recently bought AT&T.  So now the (follow me here) SBC LEC technicians refer to themselves as AT&T.  The US telecom industry can make your head explode if you try to follow it too closely. 🙂  So the call was actually from the CO technician who called me by accident and thought that I was AT&T (the carrier).  The other twist to this tale, is that my company (large enterprise) does not interface directly with the LEC.  We only interface with the carrier/ISP. 

Anyhoo…the LEC tech told me that there was a loop in the CO towards the customer’s (my!) equipment and asked if I wanted it dropped (again, he thought I was the carrier and not the customer).  I asked him why the circuit was looped.

“I have no fucking idea.”
“Really?  You guys looped a DS3 for no good reason.”
“Yup.”
“Drop the loop please.”

The loop dropped, the BGP peering established, and our site was back to 100% of their bandwidth capacity.  When I called AT&T (the carrier) to get a reason for outage, they gave me the tired old “cleared while testing”.  Nice.

Actually, there was another twist to this tale.  Our NOC missed the BGP alert.  We have separate routers connected to two different carriers (AT&T and MCI) at each of our sites.  So we still had a DS3 connection to the MCI cloud.  I don’t remember how the BGP issue eventually came to light, but it had been down for nearly a week when I got involved.  It’s a testament to our bandwidth allocation (but not our network monitoring) that the site never noticed the loss of 50% of its available bandwidth.  I have NO idea how this didn’t affect their VoIP.  Anyhoo…once I finally got an AT&T BGP technician to look at this issue, he had the balls to annotate the ticket (we can view their tickets online) with “BGP has been down for a week and they’re just now opening a ticket?”  When I spoke with him I told him that we have dual carriers and that MCI hadn’t fucked up our circuit and that he should probably keep comments like that out of our tickets.  This was before we discovered that the issue was not our equipment.  Now it was my turn to be a douchebag.  When AT&T told me “cleared while testing” I told them to open a post mortem (a ticket review process) on the ticket.  Then I jumped down the throat of our ATT account manager at our next weekly meeting.

“So you’re telling me that our circuit was looped at the CO and that it took you nearly two days to figure this out AND you lied to us about the RFO?  During this time our MCI circuit handled the load.  Why should we maintain you as a carrier?”

We pay tens of millions (maybe more) dollars for our bandwidth.  Even hinting that we might axe one or our carriers in favor of the other is kind of dirty, but it makes the account managers shit their pants and jump into action anytime we mention it.  By the end of the meeting my boss got AT&T refund us for 3 months worth of charges for that DS3.  It’s good to be king.  🙂

 

May 5, 2008

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 100.1.11.2 remote-as 1
 no auto-summary

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

Will these two routers establish a BGP peering?

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 02 May, 2008 

Topic: IP Services

Configure r1 to see all possible logs to a server with the IP address of 10.1.1.100.

Answer:

logging 10.1.1.100
logging trap debugging

logging host

logging trap

r1(config)#logging 10.1.1.100
r1(config)#logging trap ?
  <0-7>          Logging severity level
  alerts         Immediate action needed           (severity=1)
  critical       Critical conditions               (severity=2)
  debugging      Debugging messages                (severity=7)
  emergencies    System is unusable                (severity=0)
  errors         Error conditions                  (severity=3)
  informational  Informational messages            (severity=6)
  notifications  Normal but significant conditions (severity=5)
  warnings       Warning conditions                (severity=4)
  <cr>

Logging severity levels include all log alerts in that severity level as well as the levels below it.  So if you specify logging severity level 4, you will log alerts from severity level 0 – 4.  We want ‘all possible logs’ so we want to specify the highest severity level:

r1(config)#logging trap debugging

or

r1(config)#logging trap 7 

It will end up in the configuration the same:

r1(config)#do sh run | i logging
logging trap debugging

logging 10.1.1.100

 

April 29, 2008

Internetwork Expert Volume II: Lab 5 – Section 6

IPv6 – 12 Points

6.1 IPv6 Addressing

Very basic IPv6 addressing task.

6.2 IPv6 over Frame Relay

Easy IPv6 over Frame Relay task. 

The IE solution configured a link-local address on r1 and r3.  I did not.  This is a point-to-point connection so I saw no need for a link-local address.

Task 6.2

I did configure the link-local addresses on r2, r3, and r4 (along with frame maps) but it looks like those addresses and maps were not needed (actually, they used them later in the BGP IPv6 sections).

6.3 IPv6 BGP Advertisements

6.4 IPv6 BGP Summarization

6.5 IPV6 BGP

Since IPv6 BGP is not on the exam I simply read the solution guide for task 6.3 – 5 and configured my routers to match.

April 28, 2008

Internetwork Expert Volume II: Lab 5 – Section 5

Exterior Gateway Routing – 10 Points

4.1 BGP Peering

Basic peering task.  Keep in mind that sw3 and sw4 don’t have an IGP running.

I’m still having problems with know when to apply ‘next-hop-self’.  I need to do some more work on BGP. 😦

Task 4.1 – BGP Next-Hop-Self

4.2 AS-Path Manipulation

We need to make sure that the private AS’s do not get outside of AS 300:

Before:
r4#sh ip bgp quote _650.._
BGP table version is 10, local router ID is 150.1.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 150.1.9.0/24     162.1.0.3                              0 300 65002 65034 i
*> 150.1.10.0/24    162.1.0.3                              0 300 65002 65034 i
*> 162.1.7.0/24     162.1.0.2                              0 300 65001 i
*> 162.1.18.0/24    162.1.0.3                              0 300 65002 i

r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   162.1.0.4                              0 100 54 i
*> 28.119.17.0/24   162.1.0.4                              0 100 54 i
*> 150.1.9.0/24     162.1.38.8                             0 65002 65034 i
*> 150.1.10.0/24    162.1.38.8                             0 65002 65034 i
*>i162.1.7.0/24     162.1.27.7               0    100      0 65001 i
*> 162.1.18.0/24    162.1.38.8               0             0 65002 i
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 9

r3(config)#ip as-path access-list 42 perm _650.._
r3(config)#route-map TASK_42 deny 10
r3(config-route-map)# match as-path 42
r3(config-route-map)#route-map TASK_42 perm 1000
r3(config-route-map)#router bg 300
r3(config-router)#neigh 162.1.0.4 route-map TASK_42 out
r3(config-router)#neigh 162.1.13.1 route-map TASK_42 out

After:
r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 3

r4#sh ip bgp
BGP table version is 14, local router ID is 150.1.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i
*> 205.90.31.0      162.1.0.3                              0 300 200 254 ?
*> 220.20.3.0       162.1.0.3                              0 300 200 254 ?
*> 222.22.2.0       162.1.0.3                              0 300 200 254 ?

My solution works (umm…technically 🙂  ), but I’m actually filtering off the routes (which I did not think broke the task).  There’s a much easier way:

neighbor remove-private-as

Usage Guidelines
This command is available for external BGP (eBGP) neighbors only.

When an update is passed to the external neighbor, if the autonomous system path includes private autonomous system numbers, the software will drop the private autonomous system numbers.

If the autonomous system path includes both private and public autonomous system numbers, the software considers this to be a configuration error and does not remove the private autonomous system numbers.

If the autonomous system path contains the autonomous system number of the eBGP neighbor, the private autonomous system numbers will not be removed.

If this command is used with confederation, it will work as long as the private autonomous system numbers follow the confederation portion of the autonomous path.

The private autonomous system values are from 64512 to 65535.

There is a much better solution.  The prefixes are still advertised to the eBGP neighbor but do not show up on the neighbor:

r3#sh ip bgp neigh 162.1.0.4 adv
BGP table version is 10, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   162.1.0.4                              0 100 54 i
*> 28.119.17.0/24   162.1.0.4                              0 100 54 i
*> 150.1.9.0/24     162.1.38.8                             0 65002 65034 i
*> 150.1.10.0/24    162.1.38.8                             0 65002 65034 i

*>i162.1.7.0/24     162.1.27.7               0    100      0 65001 i
*> 162.1.18.0/24    162.1.38.8               0             0 65002 i
*> 205.90.31.0      162.1.13.1                             0 200 254 ?
*> 220.20.3.0       162.1.13.1                             0 200 254 ?
*> 222.22.2.0       162.1.13.1                             0 200 254 ?

Total number of prefixes 9

r4#sh ip bgp neigh 162.1.0.3 routes
BGP table version is 20, local router ID is 150.1.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 150.1.9.0/24     162.1.0.3                              0 300 i
*> 150.1.10.0/24    162.1.0.3                              0 300 i
*> 162.1.7.0/24     162.1.0.2                              0 300 i
*> 162.1.18.0/24    162.1.0.3                              0 300 i
*> 205.90.31.0      162.1.0.3                              0 300 200 254 ?
*> 220.20.3.0       162.1.0.3                              0 300 200 254 ?
*> 222.22.2.0       162.1.0.3                              0 300 200 254 ?

Total number of prefixes 7

4.3 BGP Filtering

Configure a new loopback interface on r5 and advertise it into BGP.  r4 should not pass this prefix on.  Configure this on r5.

Use the ‘no-advertise’ BGP community.

set community

(Optional) Well know communities can be specified by using the following keywords:

•internet
•local-as
•no-advertise
•no-export

ip prefix-list TASK_43 seq 5 permit 162.1.15.0/24
!
route-map TASK_43 permit 10
 match ip address prefix-list TASK_43
 set community no-advertise
!
route-map TASK_43 permit 1000
!
router bgp 500
 neighbor 150.1.4.4 send-community  <- don’t forget this line
 neighbor 150.1.4.4 route-map TASK_43 out

r4#sh ip bgp 162.1.15.0
BGP routing table entry for 162.1.15.0/24, version 22
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0x880
  Not advertised to any peer 
  500
    150.1.5.5 (metric 66) from 150.1.5.5 (150.1.5.5)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-advertise

IE used an as-path access-list matching ^$ instead of a prefix-list matching the network.  Both methods work, but the IE method would match any additional networks that you decide to advertise on r5 in the future.

4.4 BGP Table Stability

Pretty simple task using BGP dampening on routes learned from BB3 with the variables specified in the task.

bgp dampening

half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: 4 times half-life

We are asked to set the max-suppress-time to 30 minutes.  This can be usually be done two ways.  Set the max-suppress-time to number of minutes specified, or set the half-life to 1/4 of that amount.  In this task we cannot use 1/4 of the max-suppress-time (30 minutes) for the half-life because it is not a whole number (7.5).

(Optional) Maximum time (in minutes) a route can be suppressed. The range is from 1 to 20000; the default is 4 times the half-life. If the half-life value is allowed to default, the maximum suppress time defaults to 60 minutes. When the max-suppress-time is configured, the maximum penalty will never be exceeded, regardless of the number of times that the prefix dampens. The maximum penalty is computed with the following formula:

Max penalty = reuse-limit *2^(maximum suppress time/half time)

I applied the dampening only to routes from AS 54:

r4(config)#ip as-path access-list 44 permit ^54$
r4(config)#route-map TASK_44 permit 10
r4(config-route-map)#match as-path 44
r4(config-route-map)#set dampening 15 1000 3000 30
r4(config-route-map)#router bgp 100
r4(config-router)#bgp dampening route-map TASK_44

The IE solution applied BGP dampening to all prefixes on r4???

Task 4.4

r4#sh ip bgp dampening parameters
 dampening 15 1000 3000 30 (route-map TASK_44 10)
  Half-life time      : 15 mins       Decay Time       : 370 secs
  Max suppress penalty:  4000         Max suppress time: 30 mins
  Suppress penalty    :  3000         Reuse penalty    : 1000

 

April 12, 2008

Internetwork Expert Volume III: Lab 5 – Section 5

Exterior Gateway Routing – 7 Points

5.1 BGP Peerings

IE solution is missing the peerings r4-sw3 and r4-sw4.

5.2 BGP Path Manipulation

“Using local-preference within AS 200, ensure that r4 is used as the exit point for all BGP prefixes learned from AS 100.”

To affect OUTBOUND routing (weight and local_pref) we will create a route-map and apply it INBOUND.

r4:
route-map LOCAL_PREF permit 10
 set local-preference 1000
!
router bgp 200
 neighbor 128.1.14.1 route-map LOCAL_PREF in

“AS 100 should use r5 as the entyr point for any routes advertised by AS 200.”

Basically the same thing as the first task, but configured on the peering between r1 (AS 100) and r5 (AS 200):

r1(config)#route-map LOCAL_PREF perm 10
r1(config-route-map)#set local-pre 1000
r1(config-route-map)#router bgp 100
r1(config-router)#neigh 128.1.125.5 route-map LOCAL_PREF in

5.3 Redistribution

“Redistribute sw2’s lo0 network (150.1.8.0/24) into EIGRP on r4.”
“Do not redistribute any other BGP routes into EIGRP.”

Yuck.

I really screwed this task up.  Here’s the IE solution:

ip prefix-list SW2_LOOPBACK seq 5 permit 150.1.8.0/24
!
route-map BGP->EIGRP permit 10
 match ip address prefix-list SW2_LOOPBACK
!
router eigrp 10
 redistribute bgp 200 metric 1 1 1 1 1 route-map BGP->EIGRP
!
router bgp 200
 bgp redistribute-internal

I did everything except “bgp redistribute-internal”

bgp redistribute-internal

Usage Guidelines
The bgp redistribute-internal command is used to configure iBGP redistribution into an IGP. The clear ip bgp command must be entered to reset BGP connections after this command is configured.

When redistributing BGP into any IGP, be sure to use IP prefix-list and route-map statements to limit the number of prefixes that are redistributed.

 

April 5, 2008

Internetwork Expert Volume II: Lab 6 – Section 4

Exterior Gateway Routing – 11 Points

4.1 BGP Peering

Easy task as there are not a lot of devices running BGP and all but one peering is on r6.

“All BGP traffic between r4 and r6 should traverse the VPN tunnel.”

Easy enough,  just make the neighbor addresses 191.1.46.x.  This also save me from configuring ‘ebgp multihop’ for the r4 <-> r6 peering.

4.2  BGP Bestpath Selection

Send all traffic for prefixes learned from AS 54 on r6 to BB1.  Don’t use local_pref.

What about weight?

Best Path Selection Table:

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

Just set the weight from routes learned from BB1 to something greater than the default of 0 (IE used 100, I used 65000):

r6(config-router)#do sh ip bgp | i 54.1.3.254
*> 112.0.0.0        54.1.3.254               0         65000 54 50 60 i
*> 113.0.0.0        54.1.3.254               0         65000 54 50 60 i
*> 114.0.0.0        54.1.3.254               0         65000 54 i
*> 115.0.0.0        54.1.3.254               0         65000 54 i
*> 116.0.0.0        54.1.3.254               0         65000 54 i
*> 117.0.0.0        54.1.3.254               0         65000 54 i
*> 118.0.0.0        54.1.3.254               0         65000 54 i
*> 119.0.0.0        54.1.3.254               0         65000 54 i

4.3 BGP Filtering

Configure r6 so that AS 100 will not accept any prefixes from as 54 with a mask longer than /20.  Use a single-line prefix-list.

The prefix-list bit is easy:

r6(config)#ip prefix-list LESSTHANTWENTY perm 0.0.0.0/0 le 20

There’s a really nice breakdown on prefix-lists in general in the IE solution guide.

I was thrown off by the SET_WEIGHT route-map in the IE solution guide, but it’s same route-map name they used in the previous task (I had named mine ‘WEIGHT’) with an additional line.  So your final route-map should look similar to this:

route-map WEIGHT permit 10
 match ip address prefix-list LESSTHANTWENTY
 set weight 65000

task 4.3

4.4 BGP Summarization

Configure a summary of 191.1.0.0/16 and 150.1.0.0/20 but do not use aggregate-address.  You are allowed to use two static routes on r3 to accomplish this.

I had NO CLUE on this one.  I peeked the solution guide and then slapped my big, dumb forehead.  The ip routes are to NULL0.  You then redistribute the static routes.  DOH!!!

r3(config)#ip route 150.1.0.0 255.255.240.0 null0
r3(config)#ip route 191.1.0.0 255.255.0.0 null0
r3(config)#router bgp 200
r3(config-router)#redist static

r6#sh ip route bgp | i 150|191.1.
     191.1.0.0/16 is variably subnetted, 21 subnets, 4 masks
B       191.1.0.0/16 [20/0] via 204.12.1.3, 00:01:00         
     150.1.0.0/16 is variably subnetted, 10 subnets, 3 masks
B       150.1.0.0/20 [20/0] via 204.12.1.3, 00:01:00 

4.5 BGP Table Stability

Configure r6 to not advertise 112.0.0.0/8 and 113.0.0.0/8 if they are “consistently unstable.”

bgp dampening

Usage Guidelines
The bgp dampening command is used to enable BGP route dampening. This command can be entered without any arguments or keywords. The half-life, reuse, suppress, and max-suppress-time arguments are position-dependent; meaning that if any of these arguments are entered, then all optional arguments must be entered.

When BGP dampening is configured and a prefix is withdrawn, BGP considers the withdrawn prefix as a flap and increases the penalty by a 1000. If BGP receives an attribute change, BGP increases the penalty by 500. If then the prefix has been withdrawn, BGP keeps the prefix in the BGP table as a history entry. If the prefix has not been withdrawn by the neighbor and BGP is not using this prefix, the prefix is marked as dampened. Dampened prefixes are not used in the BGP decision process and not installed to the routing table.

router bgp 100
 bgp dampening route-map FLAPPERS
!
ip prefix-list FLAPPERS seq 5 permit 112.0.0.0/8
ip prefix-list FLAPPERS seq 10 permit 113.0.0.0/8
!
route-map FLAPPERS permit 10
 match ip address prefix-list FLAPPERS

I missed on important piece though:

r6(config-router)#
*Mar  6 18:15:27.386: %BGP-3-BADROUTEMAP: Bad parameters in the route-map FLAPPERS applied for Dampening

You MUST specify dampening parameters in the route map.  Just use the defaults:

Defaults
BGP dampening is disabled by default. The following values are used when this command is enabled without configuring any optional arguments:

half-life: 15 minutes
reuse: 750
suppress: 2000
max-suppress-time: 4 times half-life

r6(config-router)#route-map FLAPPERS perm 10
r6(config-route-map)#set dampening 15 750 2000 60

r6#sh ip bgp dampening parameters
 dampening 15 750 2000 60 (route-map FLAPPERS 10)
  Half-life time      : 15 mins       Decay Time       : 2320 secs
  Max suppress penalty: 12000         Max suppress time: 60 mins
  Suppress penalty    :  2000         Reuse penalty    : 750

 

April 4, 2008

Internetwork Expert Volume II: Lab 3 – Section 5

Exterior Gateway Routing – 16 Points

5.1 BGP Peering

This was an easy section but there were a lot of AS’s and peerings.  There are two separate AS 100.

Remember ebgp-multihop between r4 and r5.

There is no need for RR in area 100 (r1, r6, r3) as there is a full mesh.

I did miss ‘neigh 136.1.109.10 next-hop-self’ on sw3  ARGH!!!!

5.2 BGP FIltering

AS100 cannot be used a transit to reach AS54.  Configure this only on r6.

I tried to filter the traffic with an as-path access-list and a route map.  IE has a better solution: use the no-export community.

set community

(Optional) Well know communities can be specified by using the following keywords:

•internet
•local-as
•no-advertise
•no-export

r6(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community)
  local-AS        Do not send outside local AS (well-known community)
  no-advertise    Do not advertise to any peer (well-known community)
  no-export       Do not export to next AS (well-known community)
  <cr>

Nice break down of the BGP communities in the IE solution guide.  This is good because I am still shaky on BGP communities.

r3#sh ip bgp 114.0.0.0
BGP routing table entry for 114.0.0.0/8, version 25
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)  <-
Flag: 0x880
  Advertised to update-groups:
     2
  54
    54.1.3.254 (metric 2560002816) from 136.1.136.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export

5.3 BGP Bestpath Selection

Advertise VLAN3 on r3 into BGP.  AS400 should route through AS300 to get to this prefix.  Do this configuration in AS100.

Best Path Selection Table:

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

Before:
r5#sh ip bgp 136.1.3.0
BGP routing table entry for 136.1.3.0/24, version 27
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1          2
  300 100
    136.1.245.2 from 136.1.245.2 (150.1.2.2)
      Origin IGP, localpref 100, valid, external
  100
    136.1.15.1 from 136.1.15.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external, best

I went with MED….:-(

“To affect inbound traffic flow you must either prepend the AS-path attribute or set the MED value as the prefix is adveritised outside the AS.  However, since MED is only compared by default on prefixes learned from the SAME AS, AS-path prepending must be used in this case.”

ip prefix-list 53 seq 5 permit 136.1.3.0/24
!
route-map TASK_53_ASPATH permit 10
 match ip address prefix-list 53
 set as-path prepend 100 100
route-map TASK_53_ASPATH permit 1000
!
router bgp 100
 neigh 136.1.15.5 route-map TASK_53_ASPATH out

After:
r5#sh ip bgp 136.1.3.0
BGP routing table entry for 136.1.3.0/24, version 28
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1          2
  100 100 100
    136.1.15.1 from 136.1.15.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external
  300 100
    136.1.245.2 from 136.1.245.2 (150.1.2.2)
      Origin IGP, localpref 100, valid, external, best

5.4 BGP Attribute Manipulation

Advertise VLAN 29  on r2.

r5 should see this:

r5#sh ip bgp | i 136.1.29.0|Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 136.1.29.0/24    136.1.245.2                          100 300 i

Here’s what we currently see:

r5#sh ip bgp | i 136.1.29.0|Net
   Network          Next Hop            Metric LocPrf Weight Path
*  136.1.29.0/24    136.1.15.1                             0 100 300 i
*>                        136.1.245.2              0             0 300 i

I looks like we’re going to set the weight to 100 and filter the other route?

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

bgp router 200
 neighbor 136.1.245.2 route-map TASK_54_WEIGHT in
!
ip prefix-list 54 seq 5 permit 136.1.29.0/24
!
route-map TASK_54_WEIGHT permit 10
 match ip address prefix-list 54
 set weight 100
route-map TASK_54_WEIGHT permit 1000

Hmmm….not quite what I got.

   Network          Next Hop            Metric LocPrf Weight Path

*  136.1.29.0/24    136.1.15.1                             0 100 300 i  <-not shown in IE
*>                             136.1.245.2              0           100 300 i

IE solution was the same as mine…kinda bad question.

5.5 BGP Bestpath Selection

YIKES!!!!

Nice breakdown though.

r2#sh ip bgp neigh 136.1.245.5 | i Cond
  Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Withdraw

5.6 BGP AS Path

Advertise the EtherChannel subnet on sw3 into BGP.  Make sure that r3 and sw3 will accept BGP updates with AS100 in the AS-path.  Don’t alter r2’s configuration to accomplish this.

This is where our two AS100’s come back to haunt us.

neighbor allowas-in

March 28, 2008

ATTACK BY PROCTOR!!!

Every few months on GroupStudy there will be a story about a CCIE candidate going to lunch and coming back to find out that the proctor has messed with their configuration.  I always figured that this was just an urban legend, but then I experienced an ATTACK BY PROCTOR firsthand.

On Wednesday I took one of Internetwork Expert’s Graded Mock Labs.  I had successfully completed IGP redistribution  and had verified that I had end-to-end connectivity via TCL scripts.  I hurried up and applied the basic BGP peerings.  Then I consoled into each device and wrote the configuration.  Just before I went to lunch (actually just a 20 minute break to pick up my son) I reloaded all of the devices. 

When I got back I ran my TCL script again and noticed that my connectivity was broken.  Between IGP redistribution and basic BGP peering my network somehow “broke”.  I figured that I must have really messed something up with my BGP configuration since everything was fine after IGP redistribution.  I went back and verified my BGP configuration and peering on each device.  Maybe I lost some configuration when I reloaded – even though I was careful to make sure that I wrote each device before reloading.  All of my BGP configuration was there so I obviously wrote each device as that was the last configuration I had completed.  All of the BGP peerings were up and I was seeing routes coming in on the peerings (the ones that should be sending routes at least).  WTF?

I didn’t want to waste a ton of time troubleshooting this mess, so I soldiered on with the exam and made a note to run the TCL scripts again later.  When I did eventually run the scripts again, my network was still broken.

I finally started to look at the individual routes that were missing.  My issue seemed to be between the hub and spokes on one of the Frame Relay networks.  I still could not find an issue with BGP.  I took a look at my OSPF neighbors and I found that my OSPF adjacencies from my hub to my spokes were gone.  I still had some routes coming in via a virtual link between my hub and one of my spokes.  How the hell did that happen?

I looked at my OSPF configuration on my hub and found that my neighbor statements to the spokes were missing.  I added them back into the configuration and then ran my TCL scripts again.  Hallelujah!!!  I had full connectivity once again.  Although I had written my configurations after each task I must have somehow not written r5’s configuration after I finished my first OSPF task?  I continued on with the lab as I only had about 20 minutes left at that point.  I did not reload the routers again before finishing the test.  I did make sure that I wrote my configurations on each device and saved out my configurations to textfiles on my desktop.  I probably verified that those neighbor statements were still on r5 about 10 times before the lab ended.  🙂

Thinking back about this issue later I realized that since my BGP configuration was still on r5 I had definitely written the configuration on that device.  The neighbor statements must have been removed when I reloaded that router.  Somehow those devious bastards at IE must have removed my configuration.  They probably have a script that somehow removes those two lines of configuration whenever r5 is reloaded.  I had experienced the dread ATTACK BY PROCTOR!!!

Or not…. 🙂

I went to ccie-in-3-months to see if Tassos had experienced any similar issues with his mock lab and found this:

…I decided to reload all routers! What was even more disastrous, was the fact that i reloaded them all at the same time and i didn’t look at their logs while booting.

The result? After the reload, something wasn’t working as expected. After a quick search I found one router which seemed not to be running OSPF. I checked its configuration (thank god I had saved all my session locally) and I found that there were two “neighbor” commands missing! I added them and reloaded again. This time I watched the logs and there was an error message saying that this particular command is not supported on this kind of topologies (a bug? command is accepted while configuring, but it’s rejected after reloading). So i saved my configuration and warned (through email) the proctor about this behavior.

Here’s his post on the Internetwork Expert Mock Lab 1 forum:

Task 4.1

After reload:

Cisco 3640 (R4700) processor (revision 0x00) with 111616K/19456K bytes of memory.
Processor board ID 13831044
R4700 CPU at 100MHz, Implementation 33, Rev 1.0
2 Ethernet interfaces
2 Serial interfaces
DRAM configuration is 64 bits wide with parity disabled.
125K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks

Press RETURN to get started!

Like I said, I didn’t reload the router a second time.  I also would not have thought to watch the reload output.  So the good news is that it was not ATTACK BY PROCTOR but I was the victim of a bug.  [My network type on the hub and spoke was NBMA per the task].

This was actually a good experience as I got to do some troubleshooting under pressure.  I did fuck up my troubleshooting as I assumed that the issue was with BGP and did not troubleshoot outside of BGP until much later.  This was also a potentially disastrous experience as I would have lost an untold number of points due to not having end-to-end connectivity.  I am a bit disappointed that IE had not addressed this bug.

Oh, and the ATTACK BY PROCTOR rumor?  It’s exactly that – a rumor:

Hi Maruilio,

Thanks for the reply!!!

Could you please give a clarity on proctor’s behaviour during the Lab exam? I’ve heard that proctor’s occasionally changes the configuration while the exam is on eg- erase passwords, erase configurations, shutting down the interface, changing the IP addreses, etc. I am not sure if that’s all true? If it is, is that justified? I’ve also heard that you should not be too fast even if you know are pretty confident of your configurations because proctor’s probability of changing the configurations increases. Is that also true?

If the above is true, I also want to know to what extent are proctor’s authorised to play with the configurations during the exam?

My second query is – when the lab starts do we get all the devices with zero configurations or we have to first erase all the pre-configured inappropriate configuration on the devices?

My third query is out of curiosity – what method does proctor’s use for checking the lab created by the student?
Regards,
Saurabh Garg

Hi Saurabh,

These are all rumors and do not reflect the CCIE Lab environment.

Proctors do not touch any of the candidate’s devices during the exam.The only exception will be if a candidate thinks that something is not working because a possible failure on your rack the Proctor will ver[if]y it, but the candidate will be aware of it. Proctors do not touch or play with candidate’s configuration during or after the exam.

When you start the exam your routers and switches will have an initial configuration such IP addresses, hostnames, passwords. Depending of the exam you may have more pre-configuration. The ‘General Guidelines’ of the exam will state what you can change and what not can be changed.

We do have a process to development each question of the exam and it is based on results. By the end of the exam Proctors use an automatic tool to save the candidate’s configuration into our database and to verify some questions and do some connectivity tests like pings, verify routing tables, and so on. Then Proctors will manually verify the results and all remaining questions to come up with the final score.

Regards,
Maurilio

March 27, 2008

Cool Command 2: Verify Your BGP Regular Expressions

Here’s a great command for verifying (or just practicing) your BGP regular expression filters.  In the example below, I want to only see the routes where AS54 is the last AS in the AS path*.  I’m pretty sure that my regular expression is correct, but I want to verify it by running it against my BGP database.

Here’s the full BGP database:

r6(config)#do sh ip bgp | b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i
*> 112.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.3.254               0             0 54 i
*> 115.0.0.0        54.1.3.254               0             0 54 i
*> 116.0.0.0        54.1.3.254               0             0 54 i
*> 117.0.0.0        54.1.3.254               0             0 54 i
*> 118.0.0.0        54.1.3.254               0             0 54 i
*> 119.0.0.0        54.1.3.254               0             0 54 i
*> 205.90.31.0      204.12.1.3                             0 200 254 ?
*> 220.20.3.0       204.12.1.3                             0 200 254 ?
*> 222.22.2.0       204.12.1.3                             0 200 254 ?

Here’s the results of filtering with ^54_ :

r6(config)#do sh ip bgp regex ^54_
BGP table version is 14, local router ID is 150.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i
*> 112.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.3.254               0             0 54 i
*> 115.0.0.0        54.1.3.254               0             0 54 i
*> 116.0.0.0        54.1.3.254               0             0 54 i
*> 117.0.0.0        54.1.3.254               0             0 54 i
*> 118.0.0.0        54.1.3.254               0             0 54 i
*> 119.0.0.0        54.1.3.254               0             0 54 i

show ip bgp regexp

*Thanks to apep for the correction.  See comment section for details.

March 20, 2008

Cisco IOS Hints and Tips: Filtering Gotcha With ‘neighbor local-as’

Cisco IOS Hints and Trickshas a nice post concerning one of the possible “gotchas” of using the neighbor local-as command (without the no-prepend option):

Local-AS has to be matched by incoming filter-list
 
In a previous post I’ve described how you can use neighbor local-as feature to fix AS-number mismatch between adjacent autonomous systems. However, without additional options, the local-as is inserted in the AS-path of incoming BGP updates before any inbound filters. Your inbound filters thus have to match the local-as as well.

—Read The Rest Here—

Cisco Command Reference:

neighbor local-as

To customize the AS_PATH attribute for routes received from an external Border Gateway Protocol (eBGP) neighbor, use the neighbor local-as command in address family or router configuration mode. To disable AS_PATH attribute customization, use the no form of this command.

neighbor ip-address local-as as-number [no-prepend [replace-as [dual-as]]]

no neighbor ip-address local-as as-number

« Previous PageNext Page »

Create a free website or blog at WordPress.com.