CCNP Recertification

Posted on Saturday, 17th December 2005 by sean

Every so often I get books in the mail from publishers for review. I love doing it, not only for the free books, but also because people are always asking me which books are worth buying.

Normally I try to do a detailed review of the good ones, but sometimes I get backed up. Here are three books that I’ve been through recently.

Cisco IOS in a Nutshell, 2ed

View this on O’Reilly.

Cisco IOS in a Nutshell is a great reference for those that don’t spend a lot of time in the IOS CLI. It has information on absolutely everything (in varying degrees of detail). Going over the features that I frequently use (LAN switching, EIGRP, troubleshooting) showed that the level of detail would be appropriate for most people.

I was pleased with the examples and the layout of the book. It’s very how-to oriented, with a solid coverage of the basics, and a look at the really complex stuff. It’s current as of the 12.3T train, so the shelf live of this book is excellent.

The IOS guru would probably be best to look elsewhere, since they’ll know a lot of the content, and a search on cisco.com will pull up the detail you’re looking for. However if you use IOS infrequently, this 800 page volume will be a time saver.

TCP/IP Guide – A Comprehensive, Illustrated Internet Protocols Reference

View this on O’Reilly.

I’m not even sure where to begin with this book. It’s huge (1650 pages). It covers everything from networking to TCP/IP to routing protocols and the major layer 7 protocols in detail. Packet formats, common uses, everything.

While it’s tempting to drone on about the topics covered, I think it’s more helpful to look at a few of the outstanding features instead. The diagrams explaining the protocols are excellent. The author’s diagrams really make sense of the protocols. Case in point — the TCP FSM. Have you ever tried to follow the one out of the RFC? It’s brutal. The one here adds some text and shading, making it clear as day. Trying to remember how IP fragmentation works? There’s an example all worked out for you here.

For the topics themselves:

Basic networking stuff and routing protocols
Layer 3: IPv4, IPv6, PPP, ARP, NAT, IPSEC, Mobile IP, ICMP
Layer 4: TCP, UDP,
Layer 5-7: DNS, NFS, BOOTP/DHCP, SNMP, FTP/TFTP, SMTP, POP, IMAP, HTTP, NNTP, Gopher (heh)

There’s also a great deal of background information. When talking about email, there’s a look at MIME and the encoding. For HTTP, there’s a discussion of URIs.

This is an outstanding reference book for anyone involved in networking, or managing applications such as email and web. It has an incredible level of detail and will make RFC reading almost unnecessary. As a network guy who often finds himself trying to find documentation on a protocol’s behaviour, this book will come in handy.

Optimal Routing Design

View this at Cisco Press

This book is a rewrite of the 1999 title Advanced IP Network Design, which was a CCIE professional development book. The focus is on desiging large scale networks by efficient use of the routing protocols, and advanced features of the protocols.

Optimial Routing Design picks up where the Doyle books (Routing TCP/IP Vols 1&2) leave off. It assumes you have a detailed understanding of EIGRP, OSPF, IS-IS, and BGP (though the appendices and sitebars provide a lot of this if you don’t), and then really gets into the details of how to use them in a large network.

After looking at how to scale the core routing protocols, the book goes on to look at how to improve convergeance time, both by tweaking the routing protocols themselves and the layer 2 technologies. Security, VPNs, MPLS, and other tunneling techniques are also investigated toward the end.

While the topic is about scaling huge networks, the examples distill the techniques into a few routers, so that you can try them yourself. Just in the EIGRP chapter alone I found a few examples that after trying, I was able to put to use in my own network.

I found a few problems with the diagrams in the first few chapters, where the diagram and explanatory text didn’t line up. Other than that, it’s a good read. There’s liberal use of humour in what could otherwise be a dry subject.

This is a really advanced book, but a fascinating read if you like to understand the hows and whys of routing protocols. If you just put down Routing TCP/IP and are asing yourself “now what?”, this is the book you want.

Posted in Reviews | Comments (0)

Posted on Tuesday, 22nd November 2005 by sean

I’ve read and heard that there are some idiosyncrasities about connected routes and IS-IS when redistributing. Most recently while reading “Optimal Routing Design” and also when talking with a friend who was studying for the BCSI exam. When redistributing out of IS-IS, some routes are missing, notably connected routes. Let’s investigate.

A simple three-router network:

192.168.0.0/16 is in the EIGRP domain, and 10.0.0.0/8 is in IS-IS. Each router has a loopback or two just for fun. R1 will be doing redistribution.

R2:

router eigrp 1
 network 0.0.0.0
 no auto-summary
 no eigrp log-neighbor-changes

R1:

clns routing
interface Loopback5
 ip router isis
interface Ethernet0
 ip router isis
router eigrp 1
 network 192.168.0.0 0.0.255.255
 no auto-summary
!
router isis
 net 49.0001.0100.5000.0002.00

R3:

clns routing
interface Loopback5
 ip router isis
interface Ethernet0
 ip router isis
router isis
 net 49.0001.0100.5000.0003.00

Routing tables on R3:

     10.0.0.0/24 is subnetted, 3 subnets
i L1    10.1.1.0 [115/20] via 10.50.0.2, Ethernet0
C       10.3.3.0 is directly connected, Loopback5
C       10.50.0.0 is directly connected, Ethernet0

Routing tables on R2:

D    192.168.11.0/24 [90/40640000] via 192.168.5.1, 01:30:25, Serial0
C    192.168.5.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.2.2.0 is directly connected, Loopback5
C    11.0.0.0/8 is directly connected, Loopback6

On R1, redistribute mutually between IS-IS and EIGRP:

router eigrp 1
 redistribute isis level-2 metric 10000 100 255 1 1500
 network 192.168.0.0 0.0.255.255
 no auto-summary
!
router isis
 net 49.0001.0100.5000.0002.00
 redistribute eigrp 1 metric 5

Routing tables on R3:

i L2 192.168.11.0/24 [115/15] via 10.50.0.2, Ethernet0
i L2 192.168.5.0/24 [115/15] via 10.50.0.2, Ethernet0
     10.0.0.0/24 is subnetted, 4 subnets
i L2    10.2.2.0 [115/15] via 10.50.0.2, Ethernet0
i L1    10.1.1.0 [115/20] via 10.50.0.2, Ethernet0
C       10.3.3.0 is directly connected, Loopback5
C       10.50.0.0 is directly connected, Ethernet0
i L2 11.0.0.0/8 [115/15] via 10.50.0.2, Ethernet0

Hmm… Everything there seems to be in order.

Routing tables on R2:

D    192.168.11.0/24 [90/40640000] via 192.168.5.1, 01:33:23, Serial0
C    192.168.5.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 2 subnets
D EX    10.3.3.0 [170/40537600] via 192.168.5.1, 00:01:50, Serial0
C       10.2.2.0 is directly connected, Loopback5
C    11.0.0.0/8 is directly connected, Loopback6

Here, we’re missing 10.1.1.0 and 10.50.0.0 which are connected routes inside IS-IS. According to this TAC case, IS-IS connected routes don’t get redistributed:

When Intermediate System-to-Intermediate System (IS-IS) is redistributed into Open Shortest Path First (OSPF), some IS-IS routes may not be redistributed successfully. Specifically, routes advertised using IS-IS on the redistributing router are not redistributed. This behavior is expected. If a directly connected network is also advertised by IS-IS, the route is entered into the local routing table as a connected route and not as an IS-IS route. While redistributing IS-IS into OSPF, these directly connected routes are not injected into OSPF.

As I’ve shown, this also happens for EIGRP. The solution is to redistribute connected into EIGRP:

r1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r1(config)#router eigrp 1
r1(config-router)#redistribute connected 

r2#show ip route
...

D    192.168.11.0/24 [90/40640000] via 192.168.5.1, 01:43:24, Serial0
C    192.168.5.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 4 subnets
D EX    10.1.1.0 [170/40640000] via 192.168.5.1, 00:00:13, Serial0
D EX    10.3.3.0 [170/40537600] via 192.168.5.1, 00:11:50, Serial0
C       10.2.2.0 is directly connected, Loopback5
D EX    10.50.0.0 [170/40537600] via 192.168.5.1, 00:00:13, Serial0
C    11.0.0.0/8 is directly connected, Loopback6

The alternative would have been to turn on EIGRP for all interfaces and mark the two 10/8 networks as passive-interfaces. This would put the routes into EIGRP as internal routes.

So there you have it. When redistributing out of IS-IS, any locally connected routes that aren’t already in the destination protocol of the redistributing router don’t get carried over.

Posted in Routing | Comments (2)

Posted on Thursday, 17th November 2005 by sean

Build the Best Data Center Facility for Your Business
Douglas Alger
Cisco Press, 2005

Synopsis

This book is a must for anyone in charge of a datacenter, be they building, expanding, or just running the operation. It provides a solid grounding in HVAC, electrical, layout, and other concerns.

Working in IT, I’m quite familiar with the inside of a data center, but I’ll be the first to admit my knowledge of running one is quite superficial. So it was with great interest that I read this book, hoping to understand what goes into building and running a data center. Build the Best Data Center Facility for Your Business is written by the team lead of Cisco’s data center team, so I know the author is well qualified to write this.

Since this book is pretty specific, and I don’t see anything else out there in the topic, it doesn’t need a long review.

As the title implies, the book is about building a data center. It’s also about upgrading a data center, or making the most of the space you’ve already built. It’s also about how to run a data center properly so that it stays useful. The subtitle is then more descriptive: A comprehensive guide to designing and operating reliable server environments.

The book is divided into two sections. The first talks about building and upgrading a data center. This includes finding a site, choosing a layout, flooring, electrical, HVAC, and data cabling. It’s also got a chapter on things you can do to prolong the life of your current data center.

The second half of the book is about operating a data center. This includes everything from parts bins to signage and documentation.

I found that the writer assumed the reader had little knowledge of the topic, so he took the time to explain concepts. There were also dozens of anecdotes strewn about in sidebars which were not only very informative, but also somewhat entertaining. The writing addresses international issues which is not surprising given Cisco’s international reach. Most chapters end with a section on common problems which is an added benefit.

I must also stress this book is very practical. Much of the first chapter is written from the standpoint of someone preparing tender documents, based on the author’s years of experience. The companion site to the book even includes a complete set of documents that can be used should you have the need.

The one complaint I do have about the book is that some of the photos are pretty blurry, which doesn’t detract signifcantly from the quality, but is enough to mention.

Build the Best Data Center Facility for Your Business is a comprehensive guide to designing and operating reliable server environments. I highly recommend it to anyone who plays an active role in managing or designing their company’s present or future data centers.

Posted in Reviews | Comments (0)

Posted on Monday, 14th November 2005 by sean

A simple one to get the posts flowing…

BGP peer groups simplify the configuration of BGP neighbors by moving the template into a configuration. For example, look at R3:

 router bgp 1
  no synchronization
  bgp log-neighbor-changes
  network 10.3.3.0 mask 255.255.255.0
  network 10.50.0.0 mask 255.255.0.0
  neighbor 10.50.0.1 remote-as 1
  neighbor 10.50.0.2 remote-as 1
  neighbor 10.50.0.2 route-reflector-client
  neighbor 10.50.0.4 remote-as 1
  neighbor 10.50.0.4 route-reflector-client

There are two route reflector clients here with similar configuration. There are only two lines per client, but it is entirely possible that there could be more in the future.

router bgp 1
 neighbor rrclient peer-group
 neighbor rrclient remote-as 1
 neighbor rrclient route-reflector-client
 neighbor 10.50.0.1 remote-as 1
 neighbor 10.50.0.2 peer-group rrclient
 neighbor 10.50.0.4 peer-group rrclient

Here, I’ve defined defined a peer group called rrclient that has a remote-as of 1 and defines the peer as being a route-reflector client. At the neighbor level, I simply define it as being part of the peer group.

Behavior at the peer group level can be overridden. Take for example a peer group for eBGP peers, every one will have a different remote-as. The peer-group wouldn’t define the remote-as, but we’d have something like

  neighbor x.x.x.x peer-group ebgpclients
  neighbor x.x.x.x remote-as XXXX

A neighbor’s configuration can also override the peer-group on a per neighbor basis.

 neighbor filterme peer-group
 neighbor filterme route-map filtercustomers out
 neighbor x.x.x.x peer-group filterme
 neighbor x.x.x.x remote-as XXXX
 neighbor x.x.x.x route-map filternone out

Here, the x.x.x.x neighbor would have the filternone filter applied, while any other configured neighbors would have filtercustomers.

Peer groups are used to scale the configuration of BGP peers. They also reduce the possibility of errors.

Posted in Routing | Comments (1)

Posted on Tuesday, 18th October 2005 by sean

Network Administrators Survival Guide
Anand Deveriya
Cisco Press, 2006

Synopsis

A book covering the use of Open Source software to manage and document your Cisco network. Topics range from the traditional availablity and performance graphs, to more advanced security tools.

The Book

I was pretty happy when I received this book because a year ago I thought of the exact same thing but couldn’t get it off the ground. When I flipped through the index of Network Administrators Survival Guide (NASG) I thought “This is pretty much the book I wanted to write!” From that perspective, I’m glad that a book on Open Source network management and Cisco has finally hit the market.

The author’s philosophy is that while there are many good commercial packages out there, there’s also a lot of good free stuff. In an environment where you’re pressed to do more with less, Open Source starts to make great sense. The products he chose to discuss are those that he used himself in similar situations. Though Open Source is traditionally associated with Linux, the author recognizes not everyone is willing to adopt Linux, so Windows solutions for all the problems are also included with an equal level of detail. On the Cisco side, he covers IOS, CatOS, PIX, and VPN 3000 concentrators. Cisco’s line of commercial NMS products are also given a nod at the end of each chapter where appropriate, but unless you’ve used them before the descriptions don’t say much.

The basic flow of the book is pretty simple: Define the problem being solved; Survey the software available; Describe installation of the software under Linux; Describe installation of the software under Windows; Describe configuration of the Cisco equipment; Provide a summary. This pattern is repeated every chapter, which makes this a great how-to type book. The end of chapter summary is a simple table listing the tools, platforms they run on, and a URL which is a handy feature.

Within each topic the author picks one or two tools for each of Windows and Linux and goes over their basic configuration (this isn’t a hard and fast rule, since sometimes the same tool has both a Linux and Windows version). Having used most of the tools covered I can attest to their usefulness, though I feel the level of detail is less than I would have wanted. That said, at 500 plus pages getting to all the features I’d like to see would make this book several times its size. Instead, this book can be looked upon as an introduction to many tools with the instructions giving you enough to make the tool immediately useful. In most instances the tools are compared to help you choose. For example, in the Performance Monitoring section the author give some helpful limitations of the tools in terms of number of interfaces monitored, which will aid in the decision.

This book should not just be looked upon as a series of instructions on how to configure tools, there are also some good pointers on what to look for and how to interpret the results. Of particular note is the second chapter where many basic utilities, from ping to nslookup and even nbtstat are used to troubleshoot problems and perform common tasks like finding a host on the network.

Chapter Highlights

Chapter 3 – Access control. AAA is one of those features that isn’t well explained but allows for a great deal of flexibility when controlling access to network elements. This chapter covers both RADIUS and TACACS+, including the differences, along with the software to run it and how to implement it on your routers and switches. Not only do you learn how to set up the daemons, but you learn various ways to make use of it.

Chapter 4 – Syslog. Cisco devices generate a lot of helpful debugging output that most people ignore. This book covers two different Linux syslog servers (one is simple, the other more feature-rich but also complex) and one Windows server. On the Cisco side, the logging system is explained along with the parameters to tweak what gets logged.

Chapter 5- Monitoring Network Availability. Nagios and Big Brother are used, again each has different functionality which is well explained. Nagios is a very complex product, and this is one example of a situation where the book focuses on getting the basics going rather than trying to cover every feature.

Chapter 6- Network Performance Monitoring. MRTG and Cacti are the tools for this chapter, though some others get mentioned. MRTG is well explained, and even some recipes for advanced monitoring (such as CPU and firewall connections) are included. Cacti, like Nagios, is a complex product, so the author chooses to cover the basics of getting a device monitored rather than all the bells and whistles. That said, he makes a brief mention of where to get plugins, but never explains how to use them, which would have been helpful.

Buried deep in the end of this chapter is a mention of Service Assurance Agents as being a feature of IOS to measure performance. Unfortunately the author downplays their functionality, saying they only produce output in text format unless you buy Cisco IPM. Nothing could be further from the truth! In fact, Cacti has some helpful plugins to plot SAA data that I use with many of my routers to obtain useful data.

Chapter 7- Network Security Testing. The predictible tools (nmap and Nessus) are covered, but so are some Open Source packet analyzers, and the features in IOS to help them be useful (SPAN). This goes well with Chapter 8 – Router and Switch Security, where the security tools in IOS are used to lock down the network elements and enforce a baseline.

Chapter 9- Intrusion Detection System (IDS) has some good parts, like the use of Rancid to check for changes to configuration, but the topic of network IDS is so large it’s hard to do it justice in the 28 odd pages this chapter covers.

Chapter 10 – Virtual Private Networks goes over getting various Cisco products to speak with Linux and Windows VPN software. It seems somewhat out of place in this book, but would be a helpful reference if you ever have the need.

Chapter 11 – Network Documentation is something I’ve always taken for granted since I’ve always had Visio. But, for those companies that don’t want to shell out the cash for licences for the team, Anand has dug up both a Windows and a Linux replacement. In addition to showing off the software, he discusses the practice of diagraming your network (logical or physical? what do I include?) and how to best store your documentation for others to read.

Conclusion

I’m really impressed with this book. It’s perfect for anyone responsible for a Cisco network of any size who wants to know what’s going on. Even if you don’t need all the functionality described in this book, the time saved in implementing one or two of these will more than make the purchase worthwhile.

Posted in Reviews | Comments (1)

Posted on Thursday, 13th October 2005 by sean

Continuing on with route reflectors, here is an example.

The specifics of the topology don’t matter too much. R0, R1, R3, and R6 are all in AS1 and happen to be sitting on the same LAN segment. R1 connects to R2 over a serial line, and R2 is in AS2. R3 is the route reflector, R1 and R6 are clients. R0 is outside the cluster.

Configs:

r0#sh run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.50.0.3 remote-as 1
 no auto-summary

r1#sh run | begin router bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.50.0.3 remote-as 1
 neighbor 192.168.3.10 remote-as 2

r2#sh run | begin router bgp
router bgp 2
 bgp log-neighbor-changes
 network 10.2.2.0 mask 255.255.255.0
 network 11.0.0.0
 neighbor 192.168.3.9 remote-as 1

r3#sh run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 10.3.3.0 mask 255.255.255.0
 network 10.50.0.0 mask 255.255.0.0
 neighbor 10.50.0.1 remote-as 1
 neighbor 10.50.0.2 remote-as 1
 neighbor 10.50.0.2 route-reflector-client
 neighbor 10.50.0.4 remote-as 1
 neighbor 10.50.0.4 route-reflector-client

r6#sh run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.50.0.3 remote-as 1
 no auto-summary

Now, looking at the BGP entries for 11/8 which comes from R2.

From the route reflector itself:

r3#show ip bgp 11.0.0.0
BGP routing table entry for 11.0.0.0/8, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.50.0.1 10.50.0.4
  2, (Received from a RR-client)
    192.168.3.10 (metric 74) from 10.50.0.2 (10.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best

This says that we got the announcement from R1 (10.50.0.2), and are re-advertising it to 10.50.0.1 and 10.50.0.4. This is not normal iBGP behaviour, but since we’re a route-reflector, that’s ok. Look at the same prefix on r0, which is outside the cluster:

r0>show ip bgp 11.0.0.0
BGP routing table entry for 11.0.0.0/8, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  2
    192.168.3.10 (metric 74) from 10.50.0.3 (10.3.3.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.1.1.1, Cluster list: 10.3.3.1

We got it from 10.50.0.3, and see the Originator/Cluster List attributes have been added.

Looking from a client, the story is the same:

r6#show ip bgp 11.0.0.0
BGP routing table entry for 11.0.0.0/8, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  2
    192.168.3.10 (metric 74) from 10.50.0.3 (10.3.3.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.1.1.1, Cluster list: 10.3.3.1

So, we’ve reduced the number of iBGP sessions required by using route reflectors.

Posted in Routing | Comments (1)

Posted on Friday, 16th September 2005 by

One FAQ I see on CCIE lab lists is How do I load balance two paths in EIGRP without using the variance command?

It’s an interesting problem, because the solution illustrates how EIGRP works.

First of all, the variance command assigns a multiplier that says when two routes are “close enough” to load balance. Normally, when presented with a route of metric 100 and one of metric 200, routing protocols will choose the former and ignore the latter. With “variance 2″, both routes will be considered equal and make it to the routing table. Depending on the setting of “traffic-share”, the routes will be used proportionally to their metrics. How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP? describes it in detail.

Without using a variance, the only way to get multiple routes to be promoted to the routing table is to make their metrics the same. I know of two ways to do this:

1. Manipulate the components of the composite metric to make the route look the same
2. Add a static offset with the offset-list command

Consider two routers, r0 and r3, connected with both an Ethernet and a frame-relay connection out their serial interfaces.

r0#show ip eigrp neighbors
IP-EIGRP neighbors for process 42
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.1.2             Se0              166 00:00:13    1  5000  2  0
0   10.50.0.2               Et0               14 00:00:13   12   200  0  2

The 10.3.3.0/24 network is a loopback on R3, and is the one we’ll try to load balance. We can see that it uses Ethernet0 because the metric is better:

r0#show ip route 10.3.3.1
Routing entry for 10.3.3.0/24
  Known via "eigrp 42", distance 90, metric 409600, type internal
  Redistributing via eigrp 42
  Last update from 10.50.0.2 on Ethernet0, 00:00:39 ago
  Routing Descriptor Blocks:
  * 10.50.0.2, from 10.50.0.2, 00:00:39 ago, via Ethernet0
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

r0#show ip eigrp topology 10.3.3.0/24
IP-EIGRP (AS 42): Topology entry for 10.3.3.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
  Routing Descriptor Blocks:
  10.50.0.2 (Ethernet0), from 10.50.0.2, Send flag is 0x0
      Composite metric is (409600/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

Since the feasibility condition is not met, we only see the one route.

Method 1: Manipulate metric with bandwidth/delay

r0(config)#int s0
r0(config-if)#bandwidth 10000
r0(config-if)#delay 100

That makes the serial interface on R0 look like the ethernet interface. How do I know this?

r0#show int e0 | include DLY
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

(Don’t forget that the bandwidth command is in Kbits/sec, and Delay is in tens of usec)

The link properties are added on the receiving router (this is the difference between the feasible distance and the advertised distance), so if R3 is generating the route and we want to affect R0, the change goes on R0:

r0#show ip route 10.3.3.0
Routing entry for 10.3.3.0/24
  Known via "eigrp 42", distance 90, metric 409600, type internal
  Redistributing via eigrp 42
  Last update from 192.168.1.2 on Serial0, 00:01:10 ago
  Routing Descriptor Blocks:
  * 10.50.0.2, from 10.50.0.2, 00:01:10 ago, via Ethernet0
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    192.168.1.2, from 192.168.1.2, 00:01:10 ago, via Serial0
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Method 2: Use an offset-list

An offset-list adds a value to the metric of a given route from a given interface. The question is “how much is required?”. The easiest way is to write down the current metric (409600), artificially inflate the route so that the second route takes hold, then figure out the delta. Note that here we’re making the ethernet look worse by adding to the metric, where in the previous example the technique was to make the serial interface look better:

r0(config-router)#access-list 5 permit host 10.3.3.0
r0(config)#router eigrp 42
r0(config-router)#offset-list 5 in  2147483647 e0
r0#show ip route 10.3.3.0
Routing entry for 10.3.3.0/24
  Known via "eigrp 42", distance 90, metric 2297856, type internal
  Redistributing via eigrp 42
  Last update from 192.168.1.2 on Serial0, 00:02:00 ago
  Routing Descriptor Blocks:
  * 192.168.1.2, from 192.168.1.2, 00:02:00 ago, via Serial0
      Route metric is 2297856, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Now, 2297856-409600=1888256, so adjusting the offset-list gives

r0#show ip route 10.3.3.0
Routing entry for 10.3.3.0/24
  Known via "eigrp 42", distance 90, metric 2297856, type internal
  Redistributing via eigrp 42
  Last update from 10.50.0.2 on Ethernet0, 00:00:08 ago
  Routing Descriptor Blocks:
  * 192.168.1.2, from 192.168.1.2, 00:00:08 ago, via Serial0
      Route metric is 2297856, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    10.50.0.2, from 10.50.0.2, 00:00:08 ago, via Ethernet0
      Route metric is 2297856, traffic share count is 1
      Total delay is 79760 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Apply Offsets to Routing Metrics describes the use of offset-list . They can be done on all interfaces, some interfaces, and incoming or outgoing. Here we chose incoming on one interface.

Which one should I use?

Method #1 is the easiest, but is really only practical when the two routers are direct neighbours. That’s not to say it can’t be done (or you couldn’t manipulate k values to do the same thing).

Method #2 is more difficult, but is very precise. If the routers weren’t dually connected as they were in this example (say the ethernet link transited R1), this would be a good choice.

Posted in Routing | Comments (5)

Posted on Tuesday, 13th September 2005 by sean

Scaling Internal BGP can be a challenge. Every iBGP router must have a peer with every other iBGP router within an AS.

Why?

BGP uses the AS-PATH attribute for loop prevention. However, the AS is only prepended between eBGP neighbours, so it will never appear in iBGP.

However, this means that you must configure n-1 peers on every one of your n routers, for a total of n^2-n configuration statement.

Route reflectors (RR) reduce the peering by designating a route reflector (or multiple route reflectors) that are allowed to relay update messages between iBGP peers. Since it’s only the RR that has to worry about loop prevention, the peers themselves don’t know they’re connecting to an RR, and therefore don’t need any special configuration.

RFC 2796 – BGP Route Reflection – An Alternative to Full Mesh IBGP defines the behaviour of Route Reflectors.

Consider the following network:

If AS2 sends an update into AS1, the router receiving it sends an update to all its peers, who aren’t allowed to send it along to other peers (hence the full mesh requirement).

Now, remove some of the iBGP connections and turn the top two routers in AS1 into route reflector clients of the bottom right router as follows (note, I also added AS3 into the mix, ignore it for now):

The three routers in the route reflector arrangement form a route reflector cluster. From the perspective of an outside peer, such as the bottom left router in AS1, the RR cluster appears to be a single peer, also called a non client peer.

When AS2 sends in an update, the non client peer only has one neighbour to send it to, so it sends it to the route reflector server. The server knows where it received it from, and knows that it must relay this message to its clients, so it does. The clients are blissfully unaware that they are in a cluster, and follow the rules by not sending the message to anyone else.

Now, if AS3 sends an update to the RR client, it sends it to its only peer, the RR itself. The RR then sends the updates to the other client peers (following split horizon, it does not send it back to the peer that sent it to him), and to its non client peers.

This brings up three possible scenarios

Non client peer receives update – Sends an update to all its peers. This is the normal iBGP behaviour
Client peer receives update – Sends an update to all its peers who must be route reflectors. The RRs then relay this message to all the RR clients, and any configured non client peers
Route reflector receives update – sends to all its RR clients and non client peers.

Again, if you think of an RR cluster as a single iBGP router, the normal iBGP rules still apply.

In order to avoid routing loops, some new path attributes are added:

ORIGINATOR_ID – created by the route reflector, this specifies the routerid of the router that originated the route. This is needed because in iBGP, everyone knows who originated the route.

CLUSTER_LIST – contains the list of clusterids (ie route reflector groups) that the route has passed through. This is for loop prevention.

Next article will get into the configuration… Just have to retool my lab a bit.

Posted in Routing | Comments (0)

Posted on Friday, 2nd September 2005 by sean

Just finished an online lab through Cisco’s Learning Connection called “Advanced BGP Design with BGP Community Attribute – Challenge Lab – LabOps – IP – Accelerate (SE)”

The CLC has a lot of labs, I look forward to doing more

Start here: http://forums.cisco.com/eforum/servlet/PrepCenter?page=BigSnippet.PrepCenter.PrepCenter_freeTrial_learning_connection

In this lab the object was to learn communities and route-maps. Basically you are an ISP with a customer and upstream peers. The customers set some communities on the routes, and your job is to effect the desired behaviour across the network. For example, any route tagged with 1:80 was supposed to set localpref to 80 within your network and prepend 3 times to the upstream peers.

I was happy that I was able to do this lab without any help, though I’ll admit I didn’t score 100% the first crack at it. I blame this on not seeing the final task

The layout of the lab is very good. You are given a web page with various tabs such as a map of the network, and your task list. Click on the router opens up a telnet window to the real router. You then click on an “evaluate” button to grade you, and it gives a very good report, giving you hints where to fix the problems.

The only thing I didn’t like was the task list. Rather than giving me a list of tasks, it presented a long essay going through each task one by one, followed by some help. I would have preferred a summary of everything, followed by the breakdown.

Given that it’s all free, I highly recommend checking these labs out!

Posted in General | Comments (0)

Posted on Tuesday, 2nd August 2005 by sean

Last week I started in on BGP Route Aggregation, used to reduce the number of routes advertised in the global tables and to increase stability. This article will look at fine tuning the advertisements sent out when using the aggregate-address command.

First, I left off one method of advertising an aggregate, which is creating a local route to Null0 representing the aggregate, and advertise the route with the network statement. The Null0 route is required because the identical route must appear in the routing tables to advertise a network. For example, if you were advertising 10.0.0.0/16 with network 10.0.0.0 mask 255.255.0.0, you would need a statement like ip route 10.0.0.0 255.255.0.0 Null0.

The aggregate-address command behaves differently. If any component of the route (such as 10.0.1.0/24 in the above example) is available, the aggreate is advertised.

Back to our example network. Pretend for a moment that R0 and R2 had an eBGP peering, and R1 was advertising a /24 out of AS1′s allocation to both AS1 and AS3. AS1 aggregates all its address space into one /16. R0 gets a /16 from AS1 and a /24 from AS3, and will always choose the /24 since it’s a longer match.

What we need is a way to selectively punch holes in our advertisements, such as to advertise the /16 and the /24. While we could use a distribute-list at the peer level, it is easier to use a suppress-map at the same spot where we generate the aggregate.

Looking back on the config of R3 from last week:

router bgp 1
 aggregate-address 10.0.0.0 255.0.0.0 as-set

And looking at one of its neighbours:

r0#show ip bgp
BGP table version is 7, local router ID is 9.9.9.1
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
*> 10.0.0.0         10.50.0.2                              0 1 {2,3} i
*> 10.1.1.0/24      10.50.0.2                              0 1 2 i
*> 10.2.2.0/24      10.50.0.2                              0 1 3 i
*> 10.3.3.0/24      10.50.0.2                0             0 1 i

For now, we only want the 10.2.2.0/24 prefix to come through.

router bgp 1
 aggregate-address 10.0.0.0 255.0.0.0 as-set suppress-map filter-specifics
!
access-list 5 deny   10.2.2.0
access-list 5 permit any
!
route-map filter-specifics permit 10
 match ip address 5

I’ll explain that in a bit, but first let’s check to see if it was successful:

r0#show ip bgp
...
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         10.50.0.2                              0 1 {2,3} i
*> 10.2.2.0/24      10.50.0.2                              0 1 3 i
r2#show ip bgp
...
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      192.168.3.9              0    200      0 2 i
*> 10.2.2.0/24      0.0.0.0                  0         32768 i

Interestingly enough, r2 and r1 don’t see the aggregate, since the as-set option puts their AS in the AS_SET path attribute. When they see their own AS there, they reject the route since it would form a loop. Hold onto that thought.

Back to the config above. access-list 5 matches the exact prefix of 10.2.2.0 and denys it, permitting anything else. The route-map permits anything that is matched by the ACL. The suppress-map references the route map.

Here’s the thing to know about suppress-maps:

Anything permitted by the suppress-map is suppressed (denied). Anything denied by the suppress-map is advertised (permitted).

It’s completely counter-intuitive. Regardless, once you get by that, it’s a simple matter of figuring out what you want to allow and how you want to match it, making sure it gets denied, and then creating the suppress map. In this case I chose to use a standard access-list because it’s an easy way to match a particular route (and I was reading through Doyle Volume II last night, and he switches around all the time too).

Rather than matching on a particular route, how about matching on the originating AS? For instance, all the routes coming from AS2 will be allowed through, anything else will be suppressed:

router bgp 1
 aggregate-address 10.0.0.0 255.0.0.0 as-set suppress-map filter-specifics
!
ip as-path access-list 1 deny _2$
ip as-path access-list 1 permit .*
!
route-map filter-specifics permit 10
 match as-path 1

r3#show ip bgp
BGP table version is 7, local router ID is 10.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         0.0.0.0                            32768 {2,3} i
*> 10.1.1.0/24      192.168.3.2              0             0 2 i
s> 10.2.2.0/24      192.168.3.6              0             0 3 i
s                   192.168.3.2                            0 2 3 i
s> 10.3.3.0/24      0.0.0.0                  0         32768 i

So, only the 10.1.1.0/24 component is allowed through because it originated in AS2 by way of the BGP regular expression:

_2$ means

_ : Match break between two AS, or no AS
2 : Match the literal 2
$ : Anchor to the end of the string.

This regular expression matches anything with 2 as the final AS hop. Since each peer prepends their ASN, the originating AS is at the end. Note that without the _, it would have matched the AS_PATH of 42. For more information on BGP regular expressions, see Using Regular Expressions in BGP and as regular expression. I hope to do an article on it later.

One final thought before I go. If a community is set on a component route, how is it treated? On R2 I sent 3:42 on the 10.2.2.0/24 route. After removing the suppression from R3, I can see the community:

r3#show ip bgp 10.2.2.0
BGP routing table entry for 10.2.2.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.50.0.1 192.168.3.2
  3
    192.168.3.6 from 192.168.3.6 (10.2.2.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 3:42

However, this community is then propagated to the aggregate:

r3#show ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 21
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.50.0.1 192.168.3.2 192.168.3.6
  {2,3}, (aggregated by 1 10.3.3.1)
    0.0.0.0 from 0.0.0.0 (10.3.3.1)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
      Community: 3:42

Ick. What if the community was no-export?

The advertise-map option to aggregate-address selects the routes whose attributes are propagated to the aggregate. The attribute-map option allows you to set attributes.

So that’s it for BGP aggregation.

Posted in Routing | Comments (0)