Date: Tue, 3 Nov 2009 17:24:15 -0500
Subject: CCNP Class-on-Demand
From: "Jeremy L. Gaddis"
To: sales@internetworkexpert.com

Hello,

On September 18th, 2009, Brian McGahan posted an message to the CCNP
forum on ieoc.com stating that "...our CCNP Class-on-Demand is now
completed and available ..." [0]

On September 29th, 2009, I placed an online order (#186806) for your
CCNP Class-on-Demand (SKU #IENP-BC-CoD).  I received login details
shortly thereafter and was found that the course was *NOT* complete
and not all parts of the course were available.

On September 30th, 2009, after inquiries were posted to the same
thread [0] regarding the missing videos stating that "they will all be
available by the end of next week."  In addition, he stated that he
"should have a beta release of the CCNP Lab Workbook available by
Monday at the latest."  This is the lab workbook that would be,
according to the CCNP CoD product page [1], "available early October
2009".

On October 7th, 2009, I posted to the ongoing thread [0],
demonstrating that 1) the lab workbook was not available, and 2) the
remaining ONT videos were still missing.  Shortly thereafter, Brian
McGahan posted the BCMSN portions of the lab workbook.

After responding to Tony Mattke ("tonhe") on the thread [0] on October
8th, nothing has been heard from Brian McGahan.

On October 22nd, 2009, the EIGRP segment of the BSCI portion of the
workbook was posted, however.

Between October 8th and today, many others have inquired about the
availability of the remaining portions of the class, WHICH WE HAVE
ALREADY PAID FOR.

I understand that things happen.  Other things come up that have to
take priority.  However, it is now November, long past when I would
have expected the materials that I HAVE ALREADY PAID FOR to be
available.

A few moments ago, I attempted to reach Internetwork Expert's sales
division to inquire about this product.  The call, which was made
during INE's business hours [2], went unanswered and I was sent to
voicemail.

Unfortunately, the time has now come when I must demand that either:

1.  the COMPLETED product be made available in my account, or
2.  a full and complete refund be made to the credit card I used to
pay for the product.

Either option will be acceptable, and I expect that a resolution to
this issue will be made within 24 hours.

Thank you,
Jeremy L. Gaddis

[0]: http://ieoc.com/forums/t/8291.aspx
[1]: http://www.internetworkexpert.com/ccnp.htm
[2]: http://www.internetworkexpert.com/contact.htm

I’m not sure what order they were originally in, so they’re in no particular order here.

The following problems were resolved in release K.13.71.

…

IP Communication (PR_0000044004) – Switches running software versions K.13.65 - K.13.68 may experience a resource leak in ICMP that eventually causes loss of IP communication with the following symptoms.

• The switch will stop routing traffic for hosts for which it provides gateway services.
• All dynamic routing protocols stop functioning. The switch will stop sending routing protocol packets, and will not process incoming routing protocol packets sent from its neighbors.
• In-band network management stops functioning. The switch will become inaccessible via Telnet, SSH, WEB, and TFTP.
• Console management may become very sluggish and may appear to be non-responsive.
• Output from the CLI command show ip route will be corrupted.
• A reboot is required to clear up the symptoms.

BUT AT LEAST WE SAVED SOME MONEY!

(Note: Yes, I have been bit by this bug.)

Hmm…

“In Cisco IOS Release 15.0(1)M, this feature was introduced on the Cisco 1941, 2900sm, 2901, and 3900 routers.”

Well now, this certainly looks interesting:

Router# show version

Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Experimental Version 
12.4(20090904:044027) [guraman-revpi12 577]
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Fri 04-Sep-09 09:22 by guraman

ROM: System Bootstrap, Version 12.4(20090303:092436) 
[BLD-xformers_dev.XFR_20090303-20090303_0101-53 102], DEVELOPMENT SOFTWARE

C3900-2 uptime is 8 hours, 41 minutes
System returned to ROM by reload at 08:40:40 UTC Tue May 21 1901! 
System image file is "flash0:c3900-universalk9-mz.SPA"
Last reload reason: Reload Command



This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco CICSCO3945-MIDPLN (revision 1.0) with CISCO3900-MPE140 with 987136K/61440K bytes of 
memory.
Processor board ID FHH1231P02Y
3 Gigabit Ethernet interfaces
1 terminal line
1 Virtual Private Network (VPN) Module
1 cisco Integrated Service Engine(s)
DRAM configuration is 72 bits wide with parity enabled.
255K bytes of non-volatile configuration memory.
1020584K bytes of USB Flash usbflash0 (Read/Write)
1020584K bytes of USB Flash usbflash1 (Read/Write)
500472K bytes of ATA System CompactFlash 0 (Read/Write)

License Info:

License UDI:

-------------------------------------------------
Device#   PID                   SN
-------------------------------------------------
*0        CISCO3900-MPE140      FHH1215008L     



Technology Package License Information for Module:'c3900' 

----------------------------------------------------------------
Technology    Technology-package          Technology-package
              Current       Type          Next reboot  
-----------------------------------------------------------------
ipbase        ipbasek9      Permanent     ipbasek9
security      securityk9    Evaluation    securityk9
uc            None          None          None
data          None          None          None

Configuration register is 0x0

Taken from “Digitally Signed Cisco Software” (cisco.com).

Thoughts?

One example was on August 28th, when @procurve “re-tweeted” this:

Now, in terms of functionality, the ProCurve 5406zl switch does not even come anywhere near a Cisco 7206VXR. They are in two completely different categories, as far as I am concerned. I made the remark that “they couldn’t have been doing much with that 7206vxr if they were able to replace it w/ a 5406zl”. Anyone who is familiar with both devices would, I’m positive, agree with me. Nonetheless, nice try at patting yourself on the back, HP.

So it’s little instances like this that annoy the shit out of me, considering the not-so-great experiences I’ve had with ProCurve in the last year or so. Today, @procurve posted this:

I, of course, wanted to hear what they had to say, so I clicked. Read the blog post, “Cost effective networking — The choice is yours”, if you’d like. I won’t post the whole thing here, but reading it will help you to understand my response.

If you did click that link, you won’t see my comments posted. As far as I can tell, my posted was never allowed to be displayed on that page. I’m glad I kept a copy before I submitted it. Here’s what I wrote:

Actually, the choice isn’t mine, unfortunately. I’m a “technical” guy, i.e. one who has to implement, configure, and maintain ProCurve equipment. You guys do well at catering to the beancounters, though, I’ll give you that.

If the choice were mine, I wouldn’t have had a couple truckloads of 5400s come through the loading dock. It would have been Cisco or Juniper gear instead — you know, equipment that actually has some of the features I need.

Your switches are okay at layer 2, they work great there. But for those of us who need some of these advanced features, you’re just not there. First chance I get, I’m ripping out every piece of ProCurve gear I have that’s running at layer 3 and they’ll be replaced with an “incredibly inflexible and limiting solution”.

I don’t think I said anything that was untrue. I got a bunch of new 5400zl switches (22 of them, if memory serves) and, to be quite honest, I’m not impressed. I did think it was ironic that a nearly eight-year-old “HP” ProCurve 9300 switch (which wasn’t actually an “HP” at all) had features I needed that the brand spankin’ new 5400s don’t have (route maps and policy based routing, for example). When a 9300 was yanked and replaced with a 5406zl, it was then necessary to move that functionality off to — you guessed it — a Cisco device.

To HP’s credit, as I mentioned above, their switches are fine — as long as you stick to layer 2. Unfortunately, I’m using them at layer 3 as well, and am amazed by some of the issues that this gear has. There have been numerous, repeated, and documented issues with OSPF ECMP. There was a bug where scp’ing a config file over (roughly) 4200 bytes in size would cause the switch to reset itself to factory defaults and, of course, a case I myself opened last December that still hasn’t been resolved (more on that in a minute).

Anyway, my comments never got to see the light of day on HP’s blog. Even so, “imtechchris” was nice enough to reply to me. He chose not to argue my points, though, and instead decided to attack my technical skills. Here’s his reply, in its entirety (just in case it disappears from the blog):

Now with regard to this statement I made:

First chance I get, I’m ripping out every piece of ProCurve gear I have that’s running at layer 3 and they’ll be replaced with an “incredibly inflexible and limiting solution”.

I was actually quoting their article and pointing to the fact that, if or when I have the chance, I’ll yank out that ProCurve gear and replace it with either Cisco or Juniper, which their original article alluded to as “incredibly inflexible and limiting solutions”. Apparently Chris couldn’t grok that. He chose to end his reply with “If anything is clear it’s that you don’t really know how to configure these switches and you don’t want to bother learning because it’s not Cisco or Juniper.”

I’ll argue each of those points with you. After about six years of dealing with this garbage (I’m referring to the ProCurves, Chris), I think I’ve got a little bit of an understanding of how they work. I’ve managed to keep a multi-site network with hundreds and hundreds of nodes running for the last several years. I took one HP certification test, the “Accredited Integration Specialist” exam (without studing, of course), which was a complete joke (it took all of 20 minutes to complete, and I scored 100% on it — I have the score report somewhere around here if anyone thinks I’m bullshitting). I never bothered to pursue any further HP certifications. Regardless, I’d argue that I do, in fact, “know how to configure these switches”.

Now, as far as me not wanting to bother learning because it’s Cisco or Juniper, well, you’re almost right. More specifically, I “don’t want to bother” because I’ve had repeated bad experiences. It is my job to manage this gear, however, and regardless of vendor, I will, to the best of my ability, keep our network up and running — that’s what I’m paid to do. Would I be a helluva lot happier about it if it were Cisco or Juniper gear? FUCK YES.

Last point: I was going to mention and provide details (with a screenshot, of course) of the case I opened w/ ProCurve support last December (22-Dec-2008, if memory serves), but the “Support Case Manager – Enterprise edition” is apparently having some issues. When I enter in the case ID to view the details, it takes forever and finally gives me a “Could not access case” error message. The issue in this case, by the way, was replicated by at least two others who read this web site and e-mailed me privately. Apparently HP told them two different things, including telling one that the issue he was experiencing (CPU utilization at 99%) was “by design”. I still have not heard of a fix, even after an HP guy came and spent the day with me documenting everything we could find related to the issue (thanks for lunch, Richard).

So, HP, fix my issues, quit shipping stupid bugs in what is supposed to be production-level code, and get some support and maybe then my opinion of you might improve.

Oh, and please, no calls or e-mails from my sales guys this time.

UPDATE: I finally got to the case details:

Looks like they closed the case on me on August 7th, even though the last message I got from an HP engineer reads:

Just a quick status update on this issue. Our lab has been very busy with some hot issues recently and hasn’t yet got around to reproduction testing yet. I hope to have a more definitive answer for you by the end of next week.

That was on July 10th, and was the last thing I heard about this issue. There is no “solution” or “fix” mentioned in the case details, either. Thanks again, HP, way to suck.

And people wonder why I hate HP…

“Any Transport over MPLS (AToM) is Cisco’s solution for transporting Layer 2 packets over an IP/MPLS backbone.”

In a nutshell, AToM allows us to transport a wide variety of layer 2 traffic (HDLC, PPP, Frame Relay, ATM, Ethernet, …) over an existing IP/MPLS backbone.

To demonstrate, consider the following topology:

In the topology, the P, PE1, and PE2 routers make up the service provider’s IP/MPLS backbone. P, PE1, and PE2 belong to us, the service provider, and CE1 and CE2 belong to a customer of ours. The video will show how we can provide the customer with a 256k serial (HDLC) connection over our IP/MPLS backbone. The raw HDLC frames received on the serial 1/0 interfaces of PE1 and PE2 are encapsulated in MPLS and sent over the backbone to the remote PE router, where they are decapsulated and sent back out the customer-facing serial connection.

Here’s a video demonstration so you can see just how cool this is:

After I posted “Dynamips, a 7200, and a full BGP table”, a number of you left comments asking how I got the BGP routes into dynamips… the answer is einval’s “bgpsimple”.

“This perl script allows to setup an BGP adjacency with a BGP peer, monitor the messages and updates received from that peer, and to send out updates from a predefined set of NLRIs/attributes. BGP session and message handling is done by Net::BGP.”

0. Pre-requisites

On Ubuntu, at least, you’re going to need to install some packages that likely aren’t already installed. We’re going to need these to be able to build bgpdump in step 2. Fortunately, the following command will install everything you need (well, except for Net::BGP and bgpsimple):

[root@stewie ~]# apt-get install build-essential zlib1g-dev libbz2-dev

1. Install Net::BGP

Before we can even think about doing this, we’re going to need to install the Net::BGP perl modules, most likely from CPAN (your distribution may provide it in a handy installable package, but I wouldn’t count on it). I’m using an Ubuntu 8.04 LTS Server installation — you can use whichever distribution (or BSD) that you like, but this is what I’m using.

Fire up the CPAN shell:

[root@stewie ~]# perl -MCPAN -e shell

cpan shell -- CPAN exploration and modules installation (v1.9402)
Enter 'h' for help.

cpan[1]>

If this is the first time you’ve done this, you’ll have to go through some configuration. That configuration is out of scope of this document. Google it.

Next, install Net::BGP and exit the CPAN shell:

cpan[1]> install Net::BGP
CPAN: Storable loaded ok (v2.15)
Going to read '/home/jlgaddis/.cpan/Metadata'
  Database was generated on Thu, 20 Aug 2009 22:27:00 GMT
Running install for module 'Net::BGP'
Running make for K/KB/KBRINT/Net-BGP-0.13.tar.gz

[snip]

Appending installation info to /usr/lib/perl/5.8/perllocal.pod
  KBRINT/Net-BGP-0.13.tar.gz
  /usr/bin/make install  -- OK

cpan[2]> exit
Lockfile removed.
[root@stewie ~]#

2. Install bgpdump

As mentioned in bgpsimple’s README, we’re going to use a RIB dump from a router in the default-free zone. Fortunately, RIPE makes this data available for download. Before we can use it, however, we need to convert it to a format that bgpsimple can use. We’re going to download and compile bgpdump which can do the conversion for us.

[root@stewie ~]# wget http://www.ris.ripe.net/source/libbgpdump-1.4.99.9.tar.gz
--22:00:48--  http://www.ris.ripe.net/source/libbgpdump-1.4.99.9.tar.gz
           => `libbgpdump-1.4.99.9.tar.gz'
Resolving www.ris.ripe.net... 193.0.19.19
Connecting to www.ris.ripe.net|193.0.19.19|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 82,909 (81K) [application/x-gzip]

100%[=====================================================>] 82,909       130.32K/s

22:00:49 (129.85 KB/s) - `libbgpdump-1.4.99.9.tar.gz' saved [82909/82909]

[root@stewie ~]#

Uncompress the tarball and change to the newly created directory:

[root@stewie ~]# tar zxf libbgpdump-1.4.99.9.tar.gz
[root@stewie ~]# cd libbgpdump-1.4.99.9/

Be sure to skim through the README file in this directory.

Now, we can begin to build bgpdump. I don’t need IPv6 support, so I’m going to leave it out.

[root@stewie ~/libbgpdump-1.4.99.9]# ./configure --disable-ipv6
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes

[snip]

checking for inet_ntoa... yes
checking for inet_ntop... yes
checking for IPv6 support... disabled
configure: creating ./config.status
config.status: creating Makefile
config.status: creating bgpdump-config.h
[root@stewie ~/libbgpdump-1.4.99.9]#

Once the configure script has completed (successfully!), we can build bgpdump:

[root@stewie ~/libbgpdump-1.4.99.9]# make

[snip]

[root@stewie ~/libbgpdump-1.4.99.9]# ls -l bgpdump
-rwxr-xr-x 1 root root 46540 2009-08-20 22:14 bgpdump

As you see, we end up with a binary named “bgpdump”, which I’m going to copy over to /usr/local/bin. I’m also going to create a directory named “bgp”, where I’ll store the files we’ll be working with:

[root@stewie ~/libbgpdump-1.4.99.9]# cp bgpdump /usr/local/bin
[root@stewie ~/libbgpdump-1.4.99.9]# mkdir ../bgp
[root@stewie ~/libbgpdump-1.4.99.9]# cd ../bgp

3. Get some route data

Before we can inject any routes into our router, we need some routes to inject! As mentioned, RIPE makes these available to us. Go to the “RIS Raw Data” page, pick a collector, then download a file containing the raw data:

[root@stewie ~/bgp]# wget http://data.ris.ripe.net/rrc16/2009.08/bview.20090820.2359.gz
--22:59:26--  http://data.ris.ripe.net/rrc16/2009.08/bview.20090820.2359.gz
           => `bview.20090820.2359.gz'
Resolving data.ris.ripe.net... 193.0.19.19
Connecting to data.ris.ripe.net|193.0.19.19|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,108,638 (3.0M) [application/x-gzip]

100%[=====================================================>] 3,108,638    234.33K/s    ETA 00:00

22:59:40 (214.70 KB/s) - `bview.20090820.2359.gz' saved [3108638/3108638]

[root@stewie ~/bgp]#

Now that we have some routing data, we need to get it into a format that bgpsimple can work with. This is where bgpdump comes into play. Copying from bgpsimple’s README:

[root@stewie ~/bgp]# zcat bview.20090820.2359.gz | bgpdump -m - > myroutes
[root@stewie ~/bgp]#

4. Download bgpsimple

Download the code for bgpsimple:

[root@stewie ~/bgp]# wget http://bgpsimple.googlecode.com/files/bgp_simple.tgz
--23:11:17--  http://bgpsimple.googlecode.com/files/bgp_simple.tgz
           => `bgp_simple.tgz'
Resolving bgpsimple.googlecode.com... 209.85.225.82
Connecting to bgpsimple.googlecode.com|209.85.225.82|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,324 (9.1K) [application/x-gzip]

100%[=====================================================>] 9,324         --.--K/s

23:11:17 (114.18 KB/s) - `bgp_simple.tgz' saved [9324/9324]

[root@stewie ~/bgp]#

Uncompress the tarball:

[root@stewie ~/bgp]# tar zxf bgp_simple.tgz

You should end up with a Perl script named “bgp_simple.pl”:

[root@stewie ~/bgp]# ls -l bgp_simple.pl
-rwxr-xr-x 1 jlgaddis jlgaddis 20388 2009-01-07 10:31 bgp_simple.pl

5. Start up your dynamips router

Now it’s time to fire up our virtual 7200 router. Here’s the .net file for dynagen that I used (don’t forget to change the filenames and paths, as appropriate).

Start up dynamips, start up dynagen, connect to the console, and do some initial configuration:

[jlgaddis@stewie ~]$ telnet 192.168.1.109 2000
Trying 192.168.1.109...
Connected to 192.168.1.109.
Escape character is '^]'.
Connected to Dynamips VM "R1" (ID 0, type c7200) - Console port


              Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

[snip]

Router> enable
Router# configure terminal
Router(config)# no ip domain lookup
Router(config)# no ip http server
Router(config)# hostname c7200
c7200(config)# line con 0
c7200(config-line)# exec-timeout 0 0
c7200(config-line)# logging synchronous

6. Configure dynamips router’s network interface

We need to put an IP address on the router’s fastethernet 2/0 interface, then verify that we can ping the host that we’re going to run bgpsimple on:

c7200(config-line)# interface fastethernet 2/0
c7200(config-if)# ip address 192.168.1.99 255.255.255.0
c7200(config-if)# no shutdown
c7200(config-if)#
*Aug 20 23:23:26.167: %LINK-3-UPDOWN: Interface FastEthernet2/0, changed state to up
*Aug 20 23:23:27.167: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0,
changed state to up
c7200(config-if)# do ping 192.168.1.104

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.104, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms

7. Configure the BGP session on your dynamips router

Next, we need to configure our dynamips router for a BGP session with bgpsimple. You will need to change IP address below (192.168.1.104) to the IP address of the box you are running bgpsimple on:

c7200(config-if)# router bgp 65000
c7200(config-router)# no synchronization
c7200(config-router)# no auto-summary
c7200(config-router)# neighbor 192.168.1.104 remote-as 65000

8. Test with a limited number of prefixes

Now that our dynamips router is configured for BGP, we’re ready for a quick test with a small number of prefixes (10, for now). Look at the README for what all these command-line options mean (I wrapped this for readability, you don’t have to):

[root@stewie ~/bgp]# ./bgp_simple.pl -myas 65000 -myip 192.168.1.104 \
> -peerip 192.168.1.99 -peeras 65000 -p myroutes -m 10 -n
---------------------------------------- CONFIG SUMMARY --------------------------------------------------
Configured for an iBGP session between me (ASN65000, 192.168.1.104) and peer (ASN65000, 192.168.1.99).
Will use prefixes from file myroutes.
Maximum number of prefixes to be advertised: 10.
Will spoof next hop address to 192.168.1.104.
----------------------------------------------------------------------------------------------------------
Sending full update.

[snip]

Looks like that worked, let’s take a look at the BGP table on our dynamips router:

*Aug 20 23:31:49.715: %BGP-5-ADJCHANGE: neighbor 192.168.1.104 Up
c7200# show ip bgp
BGP table version is 31, local router ID is 192.168.1.99
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
*>i1.1.1.0/24       192.168.1.104                   0      0 25152 6939 3303 8300 i
*>i3.0.0.0          192.168.1.104                   0      0 25152 6939 15412 9304 80 i
*>i3.51.92.0/23     192.168.1.104                   0      0 25152 23148 7018 ?
*>i4.0.0.0/9        192.168.1.104                   0      0 25152 1273 3356 i
*>i4.0.0.0          192.168.1.104                   0      0 25152 1273 3356 i
*>i4.21.103.0/24    192.168.1.104                   0      0 25152 6939 3549 46133 i
*>i4.23.88.0/24     192.168.1.104                   0      0 25152 23148 7018 46164 i
*>i4.23.88.0/23     192.168.1.104                   0      0 25152 23148 7018 46164 i
*>i4.23.89.0/24     192.168.1.104                   0      0 25152 23148 7018 46164 i
*>i4.23.92.0/22     192.168.1.104                   0      0 25152 23148 7018 46164 i
c7200#

And there’s our 10 routes! w00t!

9. Advertise all the routes!

Now that we now we can get an adjacency up and exchange routes, let’s go for the gusto!

Kill bgp_simple.pl (CTRL-C works) and let’s take a quick look at how many routes are in the “myroutes” file.

[root@stewie ~/bgp]# wc -l myroutes
300035 myroutes

In my case, we have just over 300k. Your numbers may vary slightly — and there very well may be duplicate prefixes — depending on which dump you download from RIPE. In order to inject all the routes, we just run bgp_simple.pl as before, but without the “-m 10″ (maximum of 10 prefixes to advertise) option (again, wrapped for readability):

[root@stewie ~/bgp]# ./bgp_simple.pl -myas 65000 -myip 192.168.1.104 \
> -peerip 192.168.1.99 -peeras 65000 -p myroutes -n
---------------------------------------- CONFIG SUMMARY --------------------------------------------------
Configured for an iBGP session between me (ASN65000, 192.168.1.104) and peer (ASN65000, 192.168.1.99).
Will use prefixes from file myroutes.
Maximum number of prefixes to be advertised: 10.
Will spoof next hop address to 192.168.1.104.
----------------------------------------------------------------------------------------------------------
Sending full update.

[snip]

And now we just watch the number of prefixes received continually go up on our dynamips router:

c7200# show ip bgp summary | begin Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.104   4 65000   98425      21    98413    0    0 00:01:24    98237

c7200# show ip bgp summary | begin Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.104   4 65000  141060      23   141069    0    0 00:02:04   140849

c7200# show ip bgp summary | begin Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.104   4 65000  238966      25   238975    0    0 00:03:16   238739

We can take a quick look at a few of the prefixes in our BGP table:

c7200# show ip bgp 12.0.0.0/8 longer-prefixes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*>i12.0.0.0/9       192.168.1.104                   0      0 25152 23148 7018 i
*>i12.0.0.0         192.168.1.104                   0      0 25152 23148 7018 i
*>i12.0.18.0/24     192.168.1.104                   0      0 25152 23148 7018 27585 i
*>i12.0.19.0/24     192.168.1.104                   0      0 25152 1273 3561 27487 i
*>i12.0.28.0/24     192.168.1.104                   0      0 25152 1273 4323 30050 i
*>i12.0.29.0/24     192.168.1.104                   0      0 25152 1273 174 30538 i
*>i12.0.33.0/24     192.168.1.104                   0      0 25152 1273 174 40544 i
*>i12.0.43.0/24     192.168.1.104                   0      0 25152 23148 7018 2386 i
*>i12.0.48.0/20     192.168.1.104                   0      0 25152 1273 174 1742 i
*>i12.0.153.0/24    192.168.1.104                   0      0 25152 23148 7018 6519 i
*>i12.0.170.0/24    192.168.1.104                   0      0 25152 23148 7018 22528 i
*>i12.0.239.0/24    192.168.1.104                   0      0 25152 19151 1239 33628 i
[snip]

That’s all there is to it!

10. All your routes are belong to us!

c7200# show ip bgp summary
BGP router identifier 192.168.1.99, local AS number 65000
BGP table version is 1038362, main routing table version 1038362
298870 network entries using 34967790 bytes of memory
298870 path entries using 15541240 bytes of memory
51910/51909 BGP path/bestpath attribute entries using 6436840 bytes of memory
47723 BGP AS-PATH entries using 1265376 bytes of memory
1 BGP community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 58211270 total bytes of memory
BGP activity 668359/369489 prefixes, 668359/369489 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.104   4 65000  669061      20  1038362    0    0 00:04:16   298870
c7200#

OPTIONAL: If the BGP connection between bgpsimple and your dynamips router dies due to a hold timer expiring, you can get around this by doing two things:

1. Editing bgp_simple.pl. At line 220, I added two lines:

        KeepAliveTime           => 600,
        HoldTime                => 1800,

That “section” of code (setting up the peer connection using Net::BGP::Peer) now reads like this:

my $bgp  = Net::BGP::Process->new();
my $peer = Net::BGP::Peer->new(
        Start                   => 0,
        ThisID                  => $myip,
        ThisAS                  => $myas,
        PeerID                  => $peerip,
        PeerAS                  => $peeras,
        KeepaliveCallback       => \&sub_keepalive_callback,
        UpdateCallback          => \&sub_update_callback,
        NotificationCallback    => \&sub_notification_callback,
        ErrorCallback           => \&sub_error_callback,
        OpenCallback            => \&sub_open_callback,
        ResetCallback           => \&sub_reset_callback,
        KeepAliveTime           => 600,
        HoldTime                => 1800,
);

1. Adjusting the BGP timers on the dynamips router, like so:

c7200# configure terminal
c7200(config)# router bgp 65000
c7200(config-router)# timers bgp 600 1800
c7200(config-router)# end

We can then see those values reflected here:

c7200# show ip bgp neighbor 192.168.1.104 | in Last
  Last read 00:00:00, last write 00:00:56, hold time is 1800, keepalive interval is 600 seconds
c7200#

Note that it’s probably best to change both sides (bgp_simple.pl and your router’s config), since BGP will use the lowest of the values configured between peers.

For reference, here’s the “sntp” commands available in the software:

ProCurve Switch 2610-48(config)# sntp ?
 broadcast             Operate in broadcast mode
 <30-720>              The amount of time between updates of the system clock 
                       via SNTP
 server                Configure SNTP servers to poll time from.
 unicast               Operate in unicast mode
 <cr>

…and, of course, “timesync” takes an argument too…

ProCurve Switch 2610-48(config)# timesync ?
 sntp                  Set the time protocol to SNTP
 timep                 Set the time protocol to the TIME protocol

Pretty simple, huh? Here’s the video:

The first thing you’ll want to do is head over to ProCurve’s “Software for switches” page and grab the appropriate software for your switch. At the time of this writing, K.13.63 is the latest available on the web site, however I grabbed K.13.68 from HP’s FTP server. Unzip the file that you download, read the release notes, and copy the software over to your TFTP server.

After that, it’s just a matter of following the steps in the previous post.

Here’s an update in action (note that this switch shipped with K.12.57 and all software versions after K.13.61 include a BootROM update, so we’ll our switch reboot automatically in the middle of the update. Also, by default, the switch use DHCP will acquire an IP address on VLAN 1, so we don’t have to configure one (though it’s always a good idea, of course).

Note that this whole process takes quite a bit longer than shown in the video. When I was done recording, the video came in at 08:19 long. By removing a lot of the “waiting”, I was able to get it down to the 02:42 that you see here.