Kevin Dorrell, CCIE #20765

15 Mar 2010

The BGP Decision Process

Filed under: BGP, IP Routing Protocols — dorreke @ 12:29

As it is coming up to re-certification time, I have dusted off my copy of Wendell Odom’s CCIE R&S Certification Exam Guide. I have the second edition, which is a little out of date but the information in it is still relevant.  With that, and the addition of sample chapters from the 3rd edition about MPLS and IPv6 courtesy of the CiscoPress web site, I hope to get by without forking out for the new 4th edition.   (That is one advantage of not registering my copy until 3 years after I bought it: CiscoPress gave me two sample chapters from the 3rd edition to try to persuade me to buy it, even though that too is now out of print.  But I digress.  Who knows, I may crack and  buy the 4th edition anyway.  I’m a glutton for books.)

I am looking at the BGP Decision Process on page 444, and I am having an issue with steps 3 and 5.  Just as a reminder, here are the steps as explained in the book:

3. Locally injected routes – Pick the route injected into BGP locally; if multiple routes exist, prefer ORIGIN I routes first, then ORIGIN E routes, and finally ORIGIN ? routes.  (This step is seldom needed, and is sometimes omitted from other BGP references.)

5. ORIGIN PA – IGP (I) routes are preferred over EGP (E) routes, which are in turn preferred over incomplete (?) routes.

Now, I may be being thick, but I don’t see the difference between these two steps, and I am suspecting that the explanation of step 3 is incomplete.  I suspect step 3 has nothing to do with the ORIGIN PA, but has all to do with whether the route was generated by a network command or by redistribution on this router.  Or maybe it means that the ORIGIN PA values are compared, but only if the routes are locally generated.  As he points out later in the chapter, the step is largely redundant because locally generated routes would get a weight of 32768, and so would have won outright at step 1.  But my confusion is compounded on page 456, which insists that the step is related to the ORIGIN PA.

OK, the way I think it probably works is this: step 3 gives preference to routes generated in this router by a network or redistribute command.  In fact, they have already been given preference by virtue of the weight of 32768 that they were given,  but just suppose for a moment that they are competing with an incoming update that has been artificially given a weight of 32768.  The locally generated ones take preference, discarding the incoming route.

Now suppose we generated the route locally twice, once by a redistribute by a network command.  Both of these will drop through step 4 since the AS_PATH is still empty.  So even in this case, it is step 5 that decides between I, E, or ?.

I think I’ll have to write to him to ask about it.

Advertisements

04 May 2008

NMC Sample lab

Filed under: BGP, IPv6, IPv6 BGP — dorreke @ 10:18

Since we had a couple of holidays this week (week 18), and having given up on lab 18, I thought I would have a go at the sample lab.  Being a showpiece, I thought it might be interesting and representative.

  • S7.7 – BGP auto-summary
     
  • S.8 – In IPv6, redistribute ospf 1 include-connected does not redistribute the externals by default.  You have to do redistribute ospf 1 match internal external 1 external 2 include-connected.
     
  • S.8 – Learned the proper syntax for ipv6 BGP validation commands (instead of guessing) 
    • show bgp ipv6 unicast
    • show bgp ipv6 unicast summary
    • show bgp ipv6 unicast neighbor
       
  • S.8 – IPv6 – Redistributing BGP <–> OSPF

 

27 Apr 2008

NMC Lab 9.8 BGP

Filed under: BGP — dorreke @ 09:34

Following a posting on DISCUSSiT, I reloaded my configs for Lab 09 to investigate the BGP question.  Here are my notes:

Start with default from FRS:

R3#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:03:25 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:03:25 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700
R4#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:03:28 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:03:28 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700

Shut down Lo107:

FRS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
FRS(config)#int Lo107
FRS(config-if)#shut

This is what happens on R3 and R4:

R3#
*Apr  8 17:20:36: RT: del 0.0.0.0 via 172.16.34.7, bgp metric [20/0]
*Apr  8 17:20:36: RT: delete network route to 0.0.0.0
*Apr  8 17:20:36: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:36: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:37: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: is directly connected
*Apr  8 17:20:37: RT: add 0.0.0.0/0 via 0.0.0.0, static metric [250/0]
*Apr  8 17:20:37: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:37: RT: default path is now 0.0.0.0 via 0.0.0.0
*Apr  8 17:20:37: RT: new default network 0.0.0.0
*Apr  8 17:20:37: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:37: RT: delete route to 172.16.107.0 via 172.16.34.4, eigrp metric [90/158720]
*Apr  8 17:20:37: RT:
R3#SET_LAST_RDB for 172.16.107.0/24
  OLD rdb: via 172.16.34.4, FastEthernet0/1
*Apr  8 17:20:37: RT: no routes to 172.16.107.0
*Apr  8 17:20:37: RT: NET-RED 172.16.107.0/24
*Apr  8 17:20:37: RT: delete subnet route to 172.16.107.0/24
*Apr  8 17:20:37: RT: NET-RED 172.16.107.0/24
R3#
.Apr 27 10:22:55: RT: recursion error routing 172.16.107.0 - probable routing loop
.Apr 27 10:22:55: RT: del 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:22:55: RT: delete subnet route to 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 0.0.0.0/0
R3#
R3#
R3#
R3#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 250, metric 0 (connected), candidate default path
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

And on R4:

R4#
*Apr  8 17:01:33: RT: del 0.0.0.0 via 172.16.34.7, bgp metric [20/0]
*Apr  8 17:01:33: RT: delete network route to 0.0.0.0
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:33: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: is directly connected
*Apr  8 17:01:33: RT: add 0.0.0.0/0 via 0.0.0.0, static metric [250/0]
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:33: RT: default path is now 0.0.0.0 via 0.0.0.0
*Apr  8 17:01:33: RT: new default network 0.0.0.0
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:34: RT: delete route to 172.16.107.0 via 172.16.34.7, eigrp metric [90/156160]
*Apr  8 17:01:34: RT:
R4#SET_LAST_RDB for 172.16.107.0/24
  OLD rdb: via 172.16.34.7, FastEthernet0/0
*Apr  8 17:01:34: RT: no routes to 172.16.107.0
*Apr  8 17:01:34: RT: NET-RED 172.16.107.0/24
*Apr  8 17:01:34: RT: delete subnet route to 172.16.107.0/24
*Apr  8 17:01:34: RT: NET-RED 172.16.107.0/24
R4#
.Apr 27 10:22:55: RT: recursion error routing 172.16.107.0 - probable routing loop
.Apr 27 10:22:55: RT: del 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:22:55: RT: delete subnet route to 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 0.0.0.0/0
R4#

Now bring back Lo107:

FRS(config-if)#
FRS(config-if)#no shut
FRS(config-if)#
*Mar  1 01:13:15: %LINK-3-UPDOWN: Interface Loopback107, changed state to up
*Mar  1 01:13:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback107, changed state
 to up

This is R3:

R3#
.Apr 27 10:23:44: RT: SET_LAST_RDB for 172.16.107.0/24
  NEW rdb: via 172.16.34.4
.Apr 27 10:23:44: RT: add 172.16.107.0/24 via 172.16.34.4, eigrp metric [90/158720]
.Apr 27 10:23:44: RT: NET-RED 172.16.107.0/24
R3#
.Apr 27 10:23:46: RT: closer admin distance for 0.0.0.0, flushing 1 routes
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: via 172.16.34.7
.Apr 27 10:23:46: RT: add 0.0.0.0/0 via 172.16.34.7, bgp metric [20/0]
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: default path is now 0.0.0.0 via 172.16.34.7
.Apr 27 10:23:46: RT: new default network 0.0.0.0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
R3#
.Apr 27 10:23:51: RT: network 172.16.0.0 is now variably masked
.Apr 27 10:23:51: RT: SET_LAST_RDB for 172.16.0.0/16
  NEW rdb: via 172.16.107.0
.Apr 27 10:23:51: RT: add 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:23:51: RT: NET-RED 172.16.0.0/16
.Apr 27 10:23:51: RT: NET-RED 0.0.0.0/0
R3#
Apr 27 10:23:55: RT: NET-RED 0.0.0.0/0
R3#
R3#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:00:24 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:00:24 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700

And R4:

R4#
.Apr 27 10:23:44: RT: SET_LAST_RDB for 172.16.107.0/24
  NEW rdb: via 172.16.34.7
.Apr 27 10:23:44: RT: add 172.16.107.0/24 via 172.16.34.7, eigrp metric [90/156160]
.Apr 27 10:23:44: RT: NET-RED 172.16.107.0/24
R4#
.Apr 27 10:23:46: RT: closer admin distance for 0.0.0.0, flushing 1 routes
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: via 172.16.34.7
.Apr 27 10:23:46: RT: add 0.0.0.0/0 via 172.16.34.7, bgp metric [20/0]
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: default path is now 0.0.0.0 via 172.16.34.7
.Apr 27 10:23:46: RT: new default network 0.0.0.0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
R4#
.Apr 27 10:23:51: RT: network 172.16.0.0 is now variably masked
.Apr 27 10:23:51: RT: SET_LAST_RDB for 172.16.0.0/16
  NEW rdb: via 172.16.107.0
.Apr 27 10:23:51: RT: add 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:23:51: RT: NET-RED 172.16.0.0/16
.Apr 27 10:23:51: RT: NET-RED 0.0.0.0/0
R4#
Apr 27 10:23:55: RT: NET-RED 0.0.0.0/0
R4#
R4#
R4#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:00:17 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:00:17 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700
R4#

Shows BGP route does pre-empt the static.

 

 

25 Apr 2008

NMC 17.8 BGP – Routing loop

Filed under: BGP — dorreke @ 20:02

The BGP in this lab is definitely worth a mention.  I allowed myself 40 minutes in the time plan, but that was not nearly enough given the complexity of the topology.  It was the only task in that lab I overran on, taking slightly over an hour, and still not being sure I was all right.

Even though routes are truning up in all the routers, and meeting the spec, I still do not have complete pingability.  Most inconveniently, the NMC pingability chart does not cover the BGP addresses in this lab, so I wonder if reachability is really required.  Let us assume it is for the moment.

There are four things that are likely to affect pingability in this sort of topology:

  1. Is synchronisation switched on.  No it isn’t; I disabled it on the CATs.
  2. Does every router have a reachable next-hop to the NLRI of each prefix?
  3. Does the path to any next-hop that is through a router that doesn’t speak BGP?
  4. Do we have any circular next-hop paths?

One thing that should sound alarm bells is “Do we have any BGP peerings that are not direct neighbors?”  Yes we do.  We have R1 and R2 which are peered in AS 100, but which are not directly connected.  To make matters worse, the route between R1 and R2 goes through R3, which is in AS 10.  This sounds like a recipe for a forwarding loop.

In fact, let us try and trace from R1 to 140.10.5.1:

R1#trace
Protocol [ip]:
Target IP address: 140.10.5.1
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]: 8
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 140.10.5.1
  1 170.18.123.3 8 msec 12 msec 12 msec
  2 170.18.134.4 24 msec 24 msec 28 msec
  3 170.18.134.1 24 msec 24 msec 28 msec
  4 170.18.123.3 20 msec 20 msec 25 msec
  5 170.18.134.4 40 msec 36 msec 40 msec
  6 170.18.134.1 36 msec 36 msec 36 msec
  7 170.18.123.3 36 msec 32 msec 32 msec
  8 170.18.134.4 48 msec 52 msec 52 msec
R1#

Mmm, we seem to have a loop R1, R3, R4, R1, R3, R4, R1, etc.  According to the peerings, we should be going R1, R2, R5, CAT1.  SHOWiT does not support the trace command, so I shall do a trace by hand according to the SHOWiT routing tables:

R1 to 140.10.5.1, via 170.18.25.5, recursively via 170.18.123.2.  So the next hop is R2.  Or is it?  In fact, it is via DLCI 103, so the next hop is actually R3.

R3 to 140.10.5.1, via 170.18.134.1.  The next IP hop is R1, but that is via DLCI 304, so via R4.

So it looks rather like they have the same loop as I have.  In fact, I think the only way to make this address reachable is to build a tunnel to make up for the missing R1 <–> R2 link.  To traffic to pass between R1 and R2 without being intercepted by R3.  It took a lot of experimentation, but this is what I ended up with:

R1#show run int Tu21
Building configuration...
Current configuration : 132 bytes
!
interface Tunnel21
 ip unnumbered Loopback101
 ip ospf cost 19
 tunnel source Serial0/0.123
 tunnel destination 170.18.123.2
end
R2#show run int Tu21
Building configuration...
Current configuration : 132 bytes
!
interface Tunnel21
 ip unnumbered Loopback102
 ip ospf cost 19
 tunnel source Serial0/0.123
 tunnel destination 170.18.123.1
end

That’s better.  I ran a full pingability check on all routers, and found everything was OK … drat! … except R5 could not reach 140.10.1.1 to 140.10.4.1.  That is because R5’s next hop is 1.1.2.10 so it is sourcing the ping from 1.1.2.5.  That’s fine for CAT1, but CAT2 does not have a route back to it.  If I source the ping from Lo105 instead, (170.18.105.1 –> 140.10.1.1), then I get a response.

 

15 Apr 2008

NMC Lab 15

Filed under: BGP, IP Routing Protocols — dorreke @ 22:16

It is already week 16 and I have not started Lab 15 yet.  But I had a great weekend back in blighty at a retirement party for one of my old school friends who I had not seen for 15 years or so.   So this evening I went for lab 15.  Fortunately I am getting more confident as time goes on.  I am beginning to count the things that delay me rather than the things that don’t.  I got as far as the end of section 10 (of 13) in about 3 hours.  Here are the things that I must revise:

  1. I had to look up how to configure a static neighbor in IPv6 OSPF.  (On the interface)
  2. When I redistributed connected Lo103 into OSPF on R3 (15.6.3), I was prepared for the other connecteds to stop being injected, so I compensated with a route-map.  This is the sort of issue that I am pleased I can spot in advance now.  They give the game away a bit by putting this requirement in 15.6.3 with the redistribution.  It would have been meaner to put it in as 15.3.5 with the OSPF.
  3. I stumbled a bit on the BGP, taking 45 minutes when it should have taken 30 – 40.  My access list for the route filter was not fluent.  At first, I forgot to specify the update-source on the neighbors, so I could have configured much more efficiently if I had thought about it in advnace.
  4. I cheated by looking at the answer key for the as_path regular expression, even though it was a very simple one.  I must read that up in Wendell Odom again.
  5. When I did the NAT – 15.8 – it took me by surprise when the 11.1.1.0/24 route turned up in R1.  (I keep “ip debug routing” on all the time.)  I should not have been surprised, given my solution to 15.6.3 (see #2 above).
  6. I wimped out of 15.9.  I recognise it as EEM, but I did not have the courage to tackle it.  Domani.  Magari.

I have to be in work very early tomorrow, so I shall call it a day now.  I shall try and get round to writing up the solution to my VTP problem tomorrow, once I have got Lab 15 out the way.

Am I really getting faster, or am I just getting used to the NMC format?  Maybe I need to try labs from a variety of different vendors.

 

02 Apr 2008

Gobsmacked : BGP route selection algorithm

Filed under: BGP — dorreke @ 10:44

I’m gobsmacked.  (For non-speakers of London English, “gobsmacked” literally means “punched in the mouth”, but is used as a metaphor for “severely taken aback”.  In case you were wondering.) UPDATE.  Apparently my etymology was wrong, and the word originated in Liverpool, with a possible Scottish Gaelic origin for the word “gob”, or “gab” in Irish.  See here.)

I thought I knew the BGP path selection algorithm, but I have just read something that has turned my world upside down.  (OK, now I’m exaggerating a bit.)

I had always thought the BGP path selection algorithm whittles down the alternative paths by elimination until only one candidate remains.  But according to Wendell Odom’s CCIE Certification Guide, page 445, that is not so.  It appears that each of the 12 steps (or however many there are) is considered separately.  If any step fails to produce a unique clear winner, then all the paths are carried forward to the next step.  That is, unless there is a clear winner, the “non-best” paths are not eliminated.  To quote the book:

For example, imagine that R1 has five routes to 9.0.0.0/10, two with AS_PATH length 3 and the others with AS_PATH length 5. The decision process did not determine a best route before reaching step 4 (AS_PATH length). Step 4’s logic can determine that two routes are better than the others because they have a shorter AS_PATH length. However, because this step does not produce the single winner, the process moves on to the next step, and all five routesare still considered as candidates to be the best route. Each step either produces a winner or moves on to the next step, examining all routes to that NLRI at the next step.

This has some strange consequences that I would like to test.  Suppose we have two paths:

  • Path A, LOCAL_PREF = 100, AS_PATH length = 3
  • Path B, LOCAL_PREF = 80, AS_PATH length = 2

Now, according to the decision algorithm, Path A wins on local preference.  Now, suppose we get a new path coming in:

  • Path C, LOCAL_PREF = 100, AS_PATH length = 4

According to the algorithm as described by Wendell Odom, what should happen?

Well, at the LOCAL_PREF stage, there are two candidates that should win: A and C.  So, according to the algorithm, all 3 paths get passed on to the next step.  Let us suppose that none of them are locally injected.  So we arrive at the AS_PATH step.  Which path does it choose?  Path B, because that has the shortest AS_PATH.

So …. the arrival of path C has caused us to discard path A, and install path B in its place.  Is that fair?

P.S.

After a long discussion on NetPro, we came to the conclusion that this was a mistake in the book.  The algorithm works just as I thought it did up to now.  I am honoured that Russ White joined in the conversation.  Russ is Cisco’s “Mr. Routing”.  So that is pretty conclusive.  Phew!

01 Mar 2008

Wendell Odom’s CCIE R&S Certification Guide

Filed under: BGP, General, IP Routing Protocols — dorreke @ 20:04

Took my 15-year-old to his Blues School (guitar club) in Differdange.  It wasn’t worth driving all the way home again and then all the way back to collect him, so I sat in the car for a couple of hours reading Wendell Odom’s CCIE Cert Guide.  What a great book it is!  When I was doing my CCNA back in 1999 I wasn’t such a fan of his CCNA Cert Guide.  But the CCIE book is one of the most relevant, pithy, and challenging books I have on my bookshelf.  No doubt the CCNA guide has also improved in the intervening 8 years.

I have the second edition of the CCIE book.  Every time I dip into the book it comes up with a new way of looking at something I thought I knew.  Today’s subjects were:

  • Default routes and the various ways to introduce them into RIP, EIGRP, OSPF (pages 345 – 251) and BGP (pages 381 – 382).  It goes into the differences in behavior between the different protocols with the different techniques.  For example, whether the default route must already be in the table for default-information originate to work.  (RIP: yes, but not if static; OSPF: yes, unless you have keyword always; EIGRP: not supported; BGP: yes for global version of the command, no for neighbor specific command)
      
  • QoS MQC for marking.  I didn’t realise that a class-map can have multiple match lines for the same attribute.  For example, you could accidentally have match cos 3 and match cos 5 in the same match-all class definition, which would match nothing at all.  That’s a good gotcha!
     
  • BGP Route Reflectors (pages 404 – 409).  I hadn’t appreciated the rules about what happens when you have some RR clients and some non-RR clients on the same hub, and more importantly, why.  The answer is that all routes are reflected except non-RR-client to non-RR-client.  For the why, you’ll have to read the book.  Suddenly the concept of cluster-ids became crystal clear. 

[Warning! Off Topic! Warning!] 

Next week, he wants me to go into the Blues School with him, which would mean I would miss all that reading.  Or am I just afraid of revealing how rusty my guitar technique really is?

Talking of guitars, isn’t Andy McKee incredible?  I was lucky enough to see him in concert here in Luxembourg a few weeks ago, and he really can play this stuff:

Amazing!  There are so many great guitarists around at the moment that I don’t know who gets my vote for the best guitarist in the world today: Andy McKee, Antoine Dufour, or Don Ross.

I also wanted to see if I could embed a YouTube clip in my blog.  Seems I can.

20 Feb 2008

NMC Lab 8

Filed under: BGP, Frame Relay, IP Routing Protocols, PPP, Redistribution, RIP, WAN — dorreke @ 14:31

Took a day out of work today to see what I could get out of Lab 8.  Once again, the lab caught me unawares in several places.  Here are some of the lessons:

8.1.4. PPP over Frame Relay

I had not done a PPP over Frame Relay before.  It is an interesting technique involving configuring a Virtual-Template interface that then spawns a Virtual-Access interface when it connects.  Here for the Cisco Configuration guide.

One configuration “gotcha” caught me out.  I have tripped over so many “gotchas” in the past that I have decided to make a list of them (top right, under “pages”) and write a small posting on each.

It is interesting that the example in the Cisco doument has three levels of interface: a physical interface, a point-to-point subinterface that defines the DLCI, and the PPP Virtual-Template.  The NMC answer key has only two: they go straight from the physical interface to the Virtual-Template.  Pros and Cons of each approach? 

One thing I did not manage to do: to get R3 and R4 to ping their own addresses on the PPP link.  They could each ping their partner’s address, but not their own.  I spent a long time trying to get this to work before giving up and looking at the AK.  Then I find that their solution doesn’t reach those addresses either.  They might have said so!  I have asked the question on the DISCUSSiT forum, but there seems to be less and less activity there.

Redistribution into RIP

Beware any border router that has two interfaces in the RIP domain; there could be an internal loop within the RIP domain.  In particular, beware of injecting any external route that has an AD more than 120.  The injected route will go round the loop, and appear at the other interface with a greater hop count, but an AD of 120, where it will overwrite the original injected route.  The route can thrash.  Or not … if you are lucky, the updates will go both ways round the loop and meet on some other non-border router, where they are safe.  There is a similar lesson in Lab 23, but with a rather simpler loop.

8.7. BGP

I have already had a good rant about the apalling contradictory requirements of this section.  Now I must concentrate of what I can learn from this section:

  • A BGP speaker, even if a route reflector, will not send a prefix to a neighbor that is in that same cluster as the one he learned it from.  The scenario leverages this behavior in an unusual way by deliberately using the feature to break reachability.
  • A route reflector will not touch next-hop information.  Eeven if it has next-hop-self configured, that does not apply to reflected routes.  (The scenario was not intended to teach that but a screw-up in my topology led me down that path.)
  • Interestingly, because next-hop is not touched as the route propagates along the AS 100 chain, the traffic itself takes a shortcut CAT1-R3-R4-CAT2.

I implemented the solution proposed in the AK, and it seemed to work OK.  Then, just to be perverse, I looked around for other solutions that ignored various bits of the requirements.  (Well, their solution ignores requirement 8.7.4., so I felt at liberty to keep 8.7.4 and to ignore something else instead.)  BTW, this section won’t make much sense unless you have the scenario in front of you.

I thought I would try peering R3-CAT2 and R4-CAT1.  That should inject the routes into AS 100 by two different ways, and is not expressly forbidden by the scenario.  My problem was which addresses to peer.  I had no luck peering the loopback addresses, because those have multiple paths, some going back the way you came.  I tried peering with the addresses on the 172.16.34.0/24 link, but had not luck with that either.  For some reason it does not like peering from a Virtual-Template address:

R3# 
Feb 20 15:57:15.760: BGP: 172.16.46.20 active open failed - update-source Virtual-Template1 
is not available, open active delayed 25730ms (35000ms max, 28% jitter)

So, I settled on these peerings:

  • CAT1 (172.16.38.10) <–> R4 (172.16.46.4)
  • CAT2 (172.16.46.20) <–> R3 (172.16.38.3)

Really perverse, I know.  It almost worked as well.  The only thing that didn’t work was that if I take down the peering R5<–>R3, then R5 can no longer reach 100.100.100.1.  Conversely, if I take down the peering R2<–>R4, then R2 can no longer reach 200.200.200.1.  R2 is rejecting the route to 200.200.200.0/24 because it has the same cluster-id.  Or maybe FRS is not sending it, I’m not sure.

I’ve had enough of this BGP scenario for now.  If I get time I shall try some other techniques.  I thought of making AS100 a confederation with a different AS on each router in the chain, and give R2 and R5 the same AS number.  That should do the 8.7.7. trick.  Another possiblity is to mark the route with a community that would make R2 / R5 drop it.  But that’s enough for now.

8.8. VPN

Got this bit OK, but 20 minutes was a little longer than I should have taken over it.  I must be geting tired.  The issue was to keep the infrastructure RIP routes seperate form the VPN RIP routes in R3.  (I thought they were going to implement virtual routers at some point?)  They defined the infrastructure routes as everything except the sepcific VPN routes.  I defined the infrastructure as 172.16.0.0/16 and the VPN as 10.10.0.0/16.  Six of one and half-a dozen of the other I suppose.

 

 

15 Feb 2008

NMC Lab 7.7 – BGP (Part 2)

Filed under: BGP — dorreke @ 21:39

Well, I put the question about the BGP dampening in NetPro, and I go three answers back.  Isn’t NetPro marvellous!  Anyway, it seems that if you are using a route-map to specify the dampening, then you have to specify the dampening parameters with a “set” in the route-map.  It will not assume the defaults.  So, my  route map should have looked like this:

route-map BGP-damped permit 10
 match ip address prefix-list BGP-damped
 set dampening 15 750 2000 60

The default parameters for bgp dampening are:

  • half-life = 15 mins
  • re-use = 750 seconds
  • suppress = 2000
  • max-suppress = 60 mins

That is, if you are applying dampening across the board, you can specify just bgp dampening and it will take those values.  Or you can supply your own values.

If, on the other hand, you want to apply dampening selectively, you must supply a route-map instead, but you must specify the values in the route-map.  There are no defaults.

BTW, you cannot dampen a locally generated aggregate.  Even if it flapping because the prefixes making it up are flapping, it does not appear in the show ip bgp dampening flap-statistics.

NMC Lab 7.7 – BGP

Filed under: BGP — dorreke @ 05:22

So on to the BGP, and this presented some real challenges.   So much so that it took up most of the afternoon.

7.7.1 – The first challenge was to peer AS100 on R1 and AS300 on R3 through VLAN 10.  This VLAN had two subnets; each router had a primary address and a secondary address with the rôles reversed at each end.  The peering was not allowed to refer to the secondary address.  This was actually a straightforward matter of each router connecting the other router’s primary, while sourcing from its own primary address.  In my usual manner I tried to make it a lot more complicated by using the loopback addresses, which of course were in different routing domains, so the connection went twice around the houses to get there.  “Keep It Simple Stupid”.

I’m proud to say I eventually did hit on the correct solution without looking it up in the AK.  What still I don’t understand is why the AK suggests you need ebgp-multihop for this peering.  Each router has only one hop to get to the partner’s primary address.  I have asked that on the DISCUSSiT forum, but no reply yet.  But several other people have commented on it in the past.  It rather makes 7.8.1. a null-requirement.

7.7.4. I didn’t understand how VLAN 21 and 22 should “destabilize” the BGP domain.  Even single link flapping gets added and taken away continuously, but that is hardly “destabilize”, especially with the delays inherent in BGP.  The solution I would have gone for was the dampening – I wouldn’t have thought of the aggregate.  In any case, the aggregate doesn’t protect you from both flapping together, which is what the question seemed to imply.

But I am having some problems configuring the dampening.  I keep getting an error message, and I cannot work out where if have gone wrong:

router bgp 300 
 no synchronization 
 bgp router-id 172.16.103.1 
 bgp log-neighbor-changes 
 bgp dampening route-map BGP-damped 
 network 172.16.13.0 mask 255.255.255.0 
 network 172.16.31.0 mask 255.255.255.0 
 neighbor 172.16.31.1 remote-as 100 
 neighbor 172.16.31.1 transport connection-mode active 
 neighbor 172.16.31.1 update-source FastEthernet0/0.10 
 neighbor 172.16.36.6 remote-as 600 
 neighbor 172.16.102.1 remote-as 300 
 neighbor 172.16.102.1 update-source Loopback103 
 neighbor 172.16.105.1 remote-as 300 
 neighbor 172.16.105.1 update-source Loopback103 
 no auto-summary 
: 
ip prefix-list BGP-damped seq 5 permit 172.16.21.0/24 
ip prefix-list BGP-damped seq 10 permit 172.16.22.0/24 
: 
route-map BGP-damped permit 10 
 match ip address prefix-list BGP-damped      

:      

Jan  5 23:49:54.144: %BGP-3-BADROUTEMAP: Bad parameters in the route-map BGP-damped applied for Dampening

7.7.6. For some reason I wasn’t aware of the command bgp default local-preference.  Some time I’m going to have to read the BGP command reference from cover to cover; there are so many geek-knobs.  there seems to be a slight difference between using this command and setting the local-preference in a route-map on the incoming EBGP routes: the local router does not see the local-preference.  That is, the command applies to the routes outgoing to the IBGP peers.

7.8.2. is about using a peer-session template.  I included the remote-as command in the template as well, and it seems to work OK.  I wonder why the SHOWiT does not do that.

By the way, where does it say in the scenario that CAT1 Lo110 does not have to be reachable from the other routers?

Create a free website or blog at WordPress.com.