Go CCIE Go!! - A Cisco Certified Internetwork Expert

Yep it really is that simple.

— “Smithson, Brandon K ” wrote:
> Is it really that simple to find the client > identifier? Just issue the > debug ip dhcp server packet command and use the > resulting displayed MAC > address? > > I know the Cisco Univercd link > hiad_c/ch10/hipdhcps.htm#wp1116280>> says to do > that, but the DHCP > command “client identifier” is contradicted between > that link and the > following Univercd link: > hcf_c/ch15/cfhanstl.htm#wp1201022>>. > > The second link, which pertains to Autoinstall, says > you have to use the > MAC address and reference it to a matrix to > determine the client > identifier (at least for the manual method). > Regardless, my point is > that the end result is a long string, not just the > MAC address. For > example the MAC address of R2 Ethernet 0 in the 2nd > link above is > 00e0.1eb8.eb09., and it’s client identifier is > 0063.6973.636f.2d30.3065.302e.3165.6238.2e65.6230.392d.4574.30 > > So, wouldn’t you have to use (if the host is R2, and > it’s connected > interface is Eth0): > ip dhcp pool 1 > host 10.0.20.54 255.255.255.240 > client identifier > 0063.6973.636f.2d30.3065.302e.3165.6238.2e65.6230.392d.4574.30 > > According to the second Cisco Univercd link above: > “Some Cisco networking devices use a DHCP client > identifier format that > is different from the format used by networking > devices running Cisco > IOS release 12.4(1) or newer. This document only > explains the DHCP > client identifier format used by networking devices > running Cisco IOS > release 12.4(1) or newer. Use the process described > in “Determining the > Value for the DHCP Client Identifier Automatically” > section to determine > the DHCP client identifier format that your Cisco > networking device is > using.” > > To me, it reads as if you have to use the longer > client id if your > devices are running 12.4(1) and newer. Since the > lab devices are > running 12.4 and higher (I assume), do we use this > more complex, > drawn-out method? > > Thanks, > Brandon > > —–Original Message—– > From: Darby Weaver [mailto:darbyweaver@yahoo.com] > Sent: Saturday, December 29, 2007 10:54 PM > To: Smithson, Brandon K [CCC-OT_IT]; Darren Johnson; > Thorsten Mayr; > Wilson, Ryan # Atlanta; Cisco certification > Subject: RE: Lab Configuration Management > > Yep: > > This is the way I was taught to find it: > > You can determine the client identifier by using the > debug ip dhcp > server packet command. In the following example, the > client is > identified by the value 0b07.1134.a029. > > Router# debug ip dhcp server packet > > DHCPD:DHCPDISCOVER received from client > 0b07.1134.a029 through relay > 10.1.0.253. > > DHCPD:assigned IP address 10.1.0.3 to client > 0b07.1134.a029. > > > However, in a typical DHCP Server (I’m an old > Windows guy, so I’m going > to quote MS DHCP)… > > I would just create static DHCP entries and for this > I only need the mac > address of the interface I am expecting the DHCP > request to come from. > > But since we are Cisco guys and we know how to use > debug effectively, we > can get the client identifier pretty quickly as > well. > > But since my TFTP Server is probably most of the > times going to either > be a Windows or Linux box any way, I’d probably go > ahead and configure > it to the be the DHCP Server in the first place. > > > — “Smithson, Brandon K ” > wrote: > > > Thanks for the explanation. I believe “hardware > address” is for BOOTP > > > requests and “client identifier” is for DHCP > requests. > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hi > > ad_c/ch10/hipdhcps.htm#wp1074511 > > > > The client identifier takes a little more work to > calculate than just > > the hardware address. > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hc > > f_c/ch15/cfhanstl.htm#wp1201022 > > > > > > —–Original Message—– > > From: Darby Weaver [mailto:darbyweaver@yahoo.com] > > Sent: Saturday, December 29, 2007 5:32 PM > > To: Darren Johnson; ‘Thorsten Mayr’; Smithson, > Brandon K [CCC-OT_IT]; > > ‘Wilson, Ryan # Atlanta’; ‘Cisco certification’ > > Subject: Re: Lab Configuration Management > > > > Hmm… > > > > You guys ever look at the process of a Cisco IP > Phone and how it grabs > > > its configs? > > > > Well we used to do something amazingly similar > with our WLSE and our > > WAPs just by dropping them on the correct VLAN… > > > > DHCP is a wonderful tool. > > > > Autoinstall is a wonderful tool. > > > > Doesn’t hurt to be an expert with both of them for > the Lab anyway. > > > > It really a concept, your router wants to load > this way if it has no > > configuration… > > > > Minimal Cisco DHCP Server Configuration Example > > > > The following example shows the minimum > configuration needed on a > > Cisco DHCP server to enable AutoInstall on a new > router. > > > > ip dhcp pool 1 > > > > host 10.0.20.54 255.255.255.240 > > > > In this example the new router will download the > default configuration > > > file from any available TFTP server, using only > broadcast TFTP > > requests. > > Configuring a Cisco DHCP Server to Provide TFTP > Server Information To > > AutoInstall Examples > > > > In the following example, a router is configured > as a DHCP server that > > > will provide information to a new router. The new > router is connected > > to the network via the Ethernet 0 interface, which > has a MAC address > > of 0000.0c59.fcb0. The DHCP server is configured > to assign the IP > > address of 10.0.20.54/28 to the Ethernet 0 (E0) > interface on the new > > router. > > This configuration instructs the DHCP client (the > new router using > > AutoInstall) to download the configuration file > with the name > > “/tftpboot/R1-config” from the TFTP server with > the address > > 172.16.1.1. > > > > ip dhcp pool 1 > > host 10.0.20.54 255.255.255.240 > > !The following line identifies the new router > using the new router’s > > MAC address > > hardware-address 0000.0c59.fcb0 > > !The following line specifies the configuration > filename > > bootfile R1-confg > > !The following line specifies the TFTP server > address > > option 150 ip 172.16.1.1 > > > > > > The following example configures the DHCP server > to provide the same > > address to Ethernet 0, but in this example the > TFTP server name > > “tftp.cisco.com” is given instead of the server > address. The > > dns-server command is added to provide the address > of the DNS server > > (173.1.1.10) that will resolve the TFTP server > name. > > > > ip dhcp pool 1 > > host 10.0.20.54 255.255.255.240 > > hardware-address 0000.0c59.fcb0 > > bootfile R1-confg > > !option 66 specifies the TFTP server name > > option 66 ascii tftp.cisco.com > > dns-server 173.1.1.10 > > > > Configuring a Default Relay Router Example > > > > In this example the address 10.0.20.20 is > specified as the next-hop > > toward the TFTP server with the address > > 172.16.1.1: > > > > ip dhcp pool 1 > > host 10.0.20.54 255.255.255.240 > > hardware-address 0000.0c59.fcb0 > > bootfile R1-confg > > !option 150 specifies the TFTP server address > > option 150 ip 172.16.1.1 > > default-router 10.0.20.20 > > > > > > Option 66 and 150 is discussed here for instance. > > > > Note the BootFile Name and the R1Config (for > > instance) > > > > There is also an option to specify a unique file > as well in DHCP and > > if you use this puppy you can have one file per > router or switch for > > instance. > > > > > > > > This is not a totally new concept. > > > > Now once the router grabs a DHCP Address and Basic > Config from > > Autoinstall…. > > > > What else did you need it to do for you? > > > > When you finish the lab, you can have a > preconfigured RANCID or Kiwi > > or AdventNet or Cirrus or CiscoWorks login and > grab the configs for a > > quick compare aka grading. > > > > > > > > You can do something similar with a tool like > SolarWind’s Engineer’s > > Toolkit and grab configs as well. > > > > But I like Rancid and Kiwi best. Of course RAT > would do the same > > thing compare your completed config against a > baseline configuration. > > > > > > > > > > > > — Darren Johnson > > wrote: > > > > > Hey all. Did the original post allude to the > fact > > that this was for a > > > lab? > > > If so, to dynamically load a config onto a > router, > > which is set to > > > factory default, you need to look at > autoninstall. > > That would sort the > > > > > ‘loading config’ issue. > > > To dynamically save a config every specified > > interval (say Friday > > > morning at 8:00am to a TFTP server) you need to > be > > looking at KRON. > > > Ive set this up for a customer recently (watch > out > > for a software bug > > > when specifying a Sunday …….) > > > > > > Dazzler > > > > > > —–Original Message—– > > > From: nobody@groupstudy.com > > > [mailto:nobody@groupstudy.com] On Behalf Of > > Thorsten Mayr > > > Sent: 28 December 2007 20:27 > > > To: ‘Smithson, Brandon K ‘; ‘Wilson, Ryan # > > Atlanta’; ‘Cisco > > > certification’ > > > Subject: RE: Lab Config Management > > > > > > Just had a thought about this as I’ll need a > > solution myself and a > > > click on a gui aka website sounds like a neat > > plan… > > > > > > The options I am seeing: > > > > > > a) go with something like “kiwi” where u can > > define multiple jobs to > > > archive the configs in different folders (as in > > various > > > labs…) and set up multiple > > > jobs to upload the configs the way round… or > > send static commands to > > > > > pull the config whatever you prefer. > > > > > > - problem you probably need a lic for kiwi or is > > there a freeware > > > version - and kind of generic solution… > > > > > > b) write a simple script to push and pull the > > configs which u can bind > > > > > to a web front end easily. Easy to do, but > > initially intense to write > > > all those scripts > > > > > > - don’t like the generic side of this idea > > neither… > > > > > > c) write a php script with arrays, something > like > > $devs = > > > array(’router1′ => array( ‘hostname’ => > > ‘192.168.0.1′ …. > > > And /path/to/somewhere/$LAB_ID/$hostname etc… > > > > > > - somehow I, well let’s say “don’t like” php … > > ): > > > > > > > > > > > > My 2 cents - if someone has a solution in place > > already - please > > > please share > > > > > > … I checked on freshmeat but couldn’t find > > anything (yet) > > > > > > > > > —–Original Message—– > > > From: nobody@groupstudy.com > > > [mailto:nobody@groupstudy.com] On Behalf Of > > Smithson, Brandon K > > > Sent: 28 December 2007 18:30 > > > To: Wilson, Ryan # Atlanta; Cisco certification > > > Subject: RE: Lab Config Management > > > > > > You could do a term len 0, show run, highlight > the > > config, copy and > > > paste it to Wordpad (or Word if you have it). > If > > you have large > > > configs, you can set a send delay (around 10 ms) > > to slow down copying > > > the large configs back into the routers to > prevent > > overflowing and > > > causing errors. > > > > > > —–Original Message—– > > > From: nobody@groupstudy.com > > > [mailto:nobody@groupstudy.com] On Behalf Of > > Wilson, Ryan # Atlanta > > > Sent: Friday, December 28, 2007 10:46 AM > > > To: Cisco certification > > > Subject: Lab Config Management > > > > > > I was wondering if someone could lead me in the > > right direction. I > > > have a LAB and I would like the ability to save > > and load my config > > > files dynamically. I have seen this done in > class > > room environments, > > > but I’m not how. Does anyone know of a solution? > > > > > > > > > > > > Ryan > > > > > > > > >