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.

27 May 2008

“Still to do” list

Filed under: EIGRP, General, HSRP, IP Routing Protocols, OSPF, Spanning-Tree Protocol, VTP — dorreke @ 10:00

Someone asked me recently what I was going to do now I have my digits … would I go for a second one?  Well, not just yet.  I may have got my digits, but there are still too many things in R&S that take me by surprise.  I have found out that you can be a CCIE and still not know everything yet. :-). So expect about a year of consolidation and blogging before I move to pastures new.

Knowing what
Thou knowest not
Is in a sense
Omniscience

Piet Hein, “Grooks”

Some of the stuff that Keith Tokash has been logging recently on the “CCIE Candidate” blog has pointed the way to some interesting investigations.  Furthermore, there have been a few questions on NetPro that have made me think.  It might even be the case to go to one of Narbik’s boot camps when he is in London.  (Or maybe I’m just looking for an excuse to go back to my home city. 😉  So this page will be a working list of things to do.  Pian piano.

EIGRP 

  1. EIGRP uses the metrics at which end of each link: the transmit end or the receive end.  Is it possible to provoke asymmetric routing by configuring different metrics at either end of a link?  Can this result in any unstable topologies?  See NetPro context.
  2. Someone on the NetPro forum tells me that EIGRP uneven load balancing is always process switched.  I thought it was handled by CEF using a weighted hash algorithm.  I have to lab this.  Here is a document I based my belief on.

OSPF

  1. OSPF uses the cost at which end of each link?  Actually, I already know the answer to this one: each router advertises an LSA for each network it is attached to, along with the outgoing metric of the link.  So, looking at the path of a packet from source to destination, the cost is the sum of the transmit costs on the path.
  2. There are two ways of putting a link into are area: with ip ospf 100 area 0 on the interface, and with network x.x.x.x area 0 in the router section.  In the event of a conflict, which takes precedence?
  3. Ask the same question of ip unnumbered interfaces.

HSRP and Routing protocols

  1. I still need to understand fully the interaction between HSRP and routing protocols.  Hereis a situation where HSRP appears to cause unexpected results from a routing protocol.

LAN Control Protocols

  1. When you have a dot1q trunk, which of the control protocols are send on VLAN 1 and which are sent on the native VLAN (assuming these are different).  I answered a question on NetPro about this and apparently got it wrong.  I need to lab it.

Spanning Tree

  1. Spanning-Tree.  I guess I should ask the same question for Spanning-Tree, which after all is a sort of Distance-Vector algorithm.  Which end of each link is significant.

VTP

  1. I keep telling people to beware that a VTP client can update a domain, and so it can.  But it is not as easy as I had once thought.  I need to write up the experiment properly.  I wonder whether the behavior is version dependant.
  2. Furthermore, I really want to investigate VTP transparent.  How transparent is VTP transparent?  Can a transparent switch pass through VTP information, and if so, does the domain name need to match?  How does VTP pruning react to encountering a VTP transparent switch?

There is a load of lab work to do on this.

25 May 2008

EIGRP timers – solution

Filed under: EIGRP — dorreke @ 11:04

A couple of days ago I posted a blog entry about EIGRP timers, but I didn’t have time to explain it properly.  So I just dumped the console logs of the experiment, and left it as a “guess what” challenge.  Now is the time to reveal all.

What I am trying to do is to look at a common misconception about EIGRP hello timers.  By default, the EIGRP hello-interval on most networks is 5 seconds, and the hold-time is 3 times that: 15 seconds.  These values are configurable, but how should they be configured?

The story you read in the books is that the hold-timer must be more than the hello-timer, and preferably 3 times as much.  What the books generally don’t tell you is that:

  • The hello mechanism works independently in each direction.  Hellos from router R1 to router R2 do not necessarily have to use the same parameters as hellos from R2 to R1.
  • The hold time is transmitted to the neighbor in the hello packet.  R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.  This has profound implications if you really want to understand the EIGRP Hello timers.

Let us illustrate this with an experiment:

Now, observe the EIGRP timers.  R1 has a hello-interval of 3 seconds, and a configured hold-time of 10 seconds.  R2 has a hello-time of 30 seconds, and a hold-time of 100 seconds.  At first sight, this looks as though it should be unstable; it looks as if the adjacency should stay up for 10 seconds, then go down, stay down for 20 seconds, come up for 10, etc.  But it doesn’t.  Why not?

Let us look at R1’s view of this relationship:

R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.2             Fa0/0.12          74 00:00:25   12   200  0  6

See the hold time?  The neighbor relationship has been up for 25 seconds, and the hold time is 74 seconds, not something less than 10 as we would expect.  What has happened is that R2 has sent a Hello with 100 seconds of hold time.  “Hello, I am R1, if you don’t hear from me in the next 100 seconds, assume I am dead”.

And at R2:

R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.1             Fa0/0              8 00:00:35    8   200  0  9

Here we see the hold timer that was configured in R1.

Conclusions: The EIGRP Hello mechanism works independently in each direction.  Each router does not use its locally configured hold time, but the hold time determined by its neighbor.

The really cool thing about this is that if I want to change the interval at which I send out hellos, I don’t need to touch the hold time of any of my neighbors; I just need to configure it locally.

23 May 2008

EIGRP timers

Filed under: EIGRP — dorreke @ 19:15

Well, anyone can see that this blog entry is incomplete.  I am just dumping the console logs here so I can format them up and explain them later.  Anyone care to hazard a guess as to what I am trying to show?  😉

R1:

R1#show run int f0/0.12
Building configuration...
Current configuration : 197 bytes
!
interface FastEthernet0/0.12
 encapsulation isl 12
 ip address 172.16.12.1 255.255.255.0
 no ip redirects
 ip hello-interval eigrp 200 3
 ip hold-time eigrp 200 10
 no snmp trap link-status
end
R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.2             Fa0/0.12          74 00:00:25   12   200  0  6

And R2:

R2#show run int f0/0
Building configuration...
Current configuration : 156 bytes
!
interface FastEthernet0/0
 ip address 172.16.12.2 255.255.255.0
 ip hello-interval eigrp 200 30
 ip hold-time eigrp 200 100
 duplex auto
 speed auto
end
R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.1             Fa0/0              8 00:00:35    8   200  0  9

So there you have it …

 

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.

 

20 Apr 2008

NMC DOiT 16.5 EIGRP

Filed under: EIGRP, IP Routing Protocols — dorreke @ 09:10

I did have a momentary panic in the EIGRP section over “16.5.2 Send a summary for the entire Class B range from R2 to CAT2 only.”

For a start, I misinterpreted it as meaning 160.60.0.0/16, the major network of the pod.  So I did an ip summary-address eigrp 1 160.60.0.0 255.255.0.0 on R2-F0/0.  Of course, the summary turned up not only in CAT2, but in R1 and everywhere else as well.  I could have filtered it toward R1, but that seemed like too much work.  What I wanted to do was to get rid of the discard route on R2.  Could I remember how to do it?  No!  So it took some research to remind myself of ip summary-address eigrp 1 160.60.0.0 255.255.0.0 255.  Setting the AD to 255 stops the discard route getting into the routing table, and so stops it getting redistributed into OSPF.

All well.  But futile.  On reconsideration, what they wanted was a range that covered all the Class-B addresses.  In other words, ip summary-address eigrp 1 128.0.0.0 192.0.0.0 255.  Later, I checked it against the SHOWiT, and found they did not put in the AD=255.  So, doesn’t that make the /2 summary route turn up in R1?  Instead of putting AD=255, they take the precaution  of filtering it during the redistribution from EIGRP to OSPF.  The difference my AD=255 makes is whether the discard route gets installed in R2.

 

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!

Older Posts »

Blog at WordPress.com.