Re: router CPU utilization on access lists? [7:75002]
Priscilla Oppenheimer wrote: > Yes, that's true indeed that access lists don't cause process switching > anymore, so wouldn't show up in IP Input. > Two exceptions that I failed to mention are logging and the side effect of a deny. By default, a deny causes the generation of an ICMP admin. prohibited unreachable sent to the source of the blcoked packet. Since packets cannot be created in interrupt mode, process context is required. But these are rate limited to two/second by default as self protection. Plus normal traffic shouldn't result in very many denies. But you can inhibit this entirely by configuring "no ip unreachables" on an interface. If the matching ACE has the "log" keyword, then process context is required to create the log message and perform normal logging. This too is rate-limited. > Thanks for everyone's advice. It sounds like Marty has the right approach. > Although access lists aren't process switched, they are generally fast > switched unless the router supports some other feature (like silicon > switching) or some fancy configuration like CEF or NetFlow? > > So, the thing to look for is a high utilization caused by interrupts (the > number after the slash). > > I can't safely turn them off and test, so I think I will try to simulate the > network and traffic in a lab to test my theory that they are an issue. > > It's a 2621 router with lots of entries in the access lists that are > applied. I think it's time to offload a lot of the policy represented by the > lists to a PIX firewall. > You can "tune" the lists by letting it run for a while and then noting the match counts (show access-list). Within each grouping of permit entries, you can reorder the statements to reduce the number of entries that must be compared to reach a match. If the ACL processing is as efficient as possible but is really impacting CPU utilization, then you could enable the turbo ACL feature (access-list compiled). Unfortunately, that's still only available on higher-end platforms, from 3700s on up. > Here's a good URL on troubleshooting high CPU util, by the way: > > http://www.cisco.com/warp/public/63/highcpu.html > > Thanks > > Priscilla > - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=75095&t=75002 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: router CPU utilization on access lists? [7:75002]
Priscilla Oppenheimer wrote: > Maybe a dumb question, but I know you guys can help me. :-) > > How would I know if a router is using excessive CPU on IP access lists? > > What am I looking for when I do a show processes cpu? > You can't determine the portion due to ACL processing from any single display. You'd have to compare the result of "show proc cpu" with the ACL enabled and with it not enabled, for the essentially identical traffic stream. Within the display, note the percentage of time spent in interrupt mode, as indicated by the number after the "/" in the five second average. Interrupt stack time is almost totally due to switching packets and associated inspection of them such as ACLs. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=75010&t=75002 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: DTP and VTP Domain [7:64892]
Priscilla Oppenheimer wrote: > > DTP uses protocol type 2004 too, just like DISL. I guess it's just an update > to DISL for use with 802.1Q rather than ISL? > Yes. Step 1: negotiate whether to trunk. Step 2: if the result is yes, then negotiate which flavor. If both are indifferent, favor ISL. > And, I figured out why you might want to tell DTP not to autonegotiate or be > desirable and why in that case no VTP domain name is exchanged and the VTP > domain names don't have to match. The main reason is that the other end > might not be Cisco and might not care about VTP anyway. Does that make sense? > Or the other switch is a Cisco one that doesn't speak DTP. The 2900/3500XLs and the 2950 didn't speak DTP until recently. Skipping the DTP negotiation with a device that isn't capable eliminates one source of delay before STP is handed the port. I was told by someone in Cisco that the original reason for "nonegotiate" was that the early ISL NIC drivers in servers didn't gracefully ignore the DTP multicast, but crashed the server! - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64985&t=64892 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: EIGRP Adjacenies are Unidirectional. Why? [7:59186]
"[EMAIL PROTECTED]" wrote: > > As EIGRP only looks at incoming hello packets (EIGRP type 5 packets) to keep > a peer neighbor relationship up on a particular side of a routed link., this > can be a prime issue for "black hole" routing issues. > > OSPF adjacencies are bi-directional. Makes more sense. > > Why was EIGRP designed this way? > I don't know why, but I do know Cisco is revisiting that decision. At Networkers 2002 Alvaro described an enhancement "on the drawing board" called reliable three-way handshake. Backward compatible. See session RST-440. Marty Adkins Chesapeake NetCraftsmen, LLC 1290 Bay Dale Drive, Suite 312 http://www.netcraftsmen.NET Arnold, MD 21012-2325 Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=59198&t=59186 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Apparent packet loss... [7:57922]
Keith Woodworth wrote: > > we use ip route-cache policy on each interface that is has policy routing > enabled. I'm trying to find out how route-cache correlatets to CEF. Does > ip route-cache policy need to be turned off when CEF is enabled? How is > it it different than CEF? The two seem to be interchangable and on reading > stuff on CCO about CEF there is a command: > > ip route-cache cef > > oh wait a minute, I can use ip route-cache policy to do just the policy > routing, or use ip route-cache cef. > You can have both at the same time. > Any idea on which is better? > See if this description of Netflow Policy Routing in IOS 12.2 is what you're looking for (watch URL wrap): http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfindep.htm#xtocid20 - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57977&t=57922 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Apparent packet loss... [7:57922]
Keith Woodworth wrote: > > |->> Anyway to acutally tell for certain if the router is dropping packets? > |-> > |->show buffers > |->show queueing > |->show queue interface etc. > > Showing misses/failures on all buffers but these have the most: > > Small buffers, 104 bytes (total 50, permanent 50, peak 201 @ 7w0d): > 44 in free list (20 min, 150 max allowed) > 1991931468 hits, 98395 misses, 43142 trims, 43142 created > 2371 failures (0 no memory) > Middle buffers, 600 bytes (total 25, permanent 25, peak 92 @ 3d20h): > 23 in free list (10 min, 150 max allowed) > 43042905 hits, 2828 misses, 2508 trims, 2508 created > 703 failures (0 no memory) > Big buffers, 1524 bytes (total 50, permanent 50, peak 68 @ 6d12h): > 50 in free list (5 min, 150 max allowed) > 12398616 hits, 359 misses, 81 trims, 81 created > 79 failures (0 no memory) > > so according to docs on CCO about buffers, misses/failures usually lead to > dropped packets. This leads me to believe that data is coming in at a rate > higher than the RP can keep up though. Will have to look at upping the # > of permenant buffers and see if that helps. > As Priscilla explained, output drops are frequently normal, just indicating a speed mismatch combined with a large enough packet burst that the output queue limit was exceeded (40 packets). If drops are due to a lack of buffers, then that would happen on input, not output, and the counter "no buffer" would be incrementing. The display above shows that for each of the categories, IOS grew the list above its initial size due to some transient need, then trimmed each of them back. Notice that trims = creates. See the peak values and how long ago they occurred. For an ISP or border router, CEF will help a lot since the route-cache is pre-built, rather than demand based. With the latter, lots of short-lived flows to lots of destinations cause the first packets of each flow to be process-switched. And there's far less cache maintenance or churn. CEF also works fine with netflow and policy routing. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57975&t=57922 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: full duplex or half duplex, how can you tell [7:57431]
Priscilla Oppenheimer wrote: > > sam sneed wrote: > > > > this is about the comment > > > > " You'd get a link but lots of collisions, eh? The half-duplex > > side would > > receive while it was sending, because the full-duplex side > > would send > > whenever it wanted. In other words, the 2500 side would report > > collisions, > > assuming there was enough simultanesous traffic." > > > > I hooked up a 2501 eth0 to a 3548 set to full duplex and speed > > 100. > > Interestingly the link light on the router lights up but no the > > switch. > > That's probably because of the speed mismatch not the duplex mismatch? > > In some cases you can get a link light and think everything is fine, when > actually there are problems due to a duplex mismtach. > Only a speed issue, not a duplex issue. When the 10/100 side is hard set to 100Mb so that it doesn't negotiate nor autosense, and the other side is a legacy 10Mb/half interface, then the 10Mb side will get a false link indication. The 100Mb fast link pulses produce enough energy in the band where the 10Mb interface is looking for them, to fool it. The 100Mb side will correctly show no link. The tip off is that the 10Mb side sees zero valid input frames in its counters. The 100Mb transmitter appears to be forever streaming. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57672&t=57431 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: why loopback plug detected as loopback in first place? [7:57155]
Cable Guy wrote: > > When you put a hardware loopback plug on a serial to test it, why does the > router see it as a loopback? With the show int serial command, you will see > -serial up, line protocol up (loopback mode)- > Of course it needs to see it as loopback otherwise the router wouldn't > operate and allow loopback tests. But what part of the digital signals > specifically tell the router that what it sent out has just come back? It > can't be the carrier detect because that could be interpreted as a carrier > detect from any csu/dsu. Maybe a timing issue on the return signal, but > sounds like the keepalives are being interpreted here somehow? Someone > know the details of this? Help. > Check the archives on the topic of HDLC keepalives. They have sequence numbers as well as a (layer 2) DTE/DCE flag. Experiment with "debug serial interface". - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57155&t=57155 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: odd IOS arp cache abnormality? [7:56884]
Priscilla Oppenheimer wrote: > > > The router is testing for a duplicate IP address. Hopes it > > doesn't get a reply. > > What it sends already is a reply, as the debug in the original message > stated. Here's an example: Oops, I didn't read the debug carefully enough. Thanks for the correction! > > >From my testing, the router doesn't do what you would expect it to do to > determine if someone else is using its own address, i.e. broadcast an ARP > Request with its own address in the Target Internet Address field. > > It does, by the way, send itself an ARP reply, in addition to the broadcast > ARP reply above. > > Ethernet Header > Destination: 00:00:0C:05:3E:80 > Source: 00:00:0C:05:3E:80 > Protocol Type:0x0806 IP ARP > ARP - Address Resolution Protocol > Hardware: 1 Ethernet (10Mb) > Protocol: 0x0800 IP > Hardware Address Length:6 > Protocol Address Length:4 > Operation:1 ARP Request > Sender Hardware Address:00:00:0C:05:3E:80 > Sender Internet Address:10.10.0.1 > Target Hardware Address:00:00:0C:05:3E:80 > Target Internet Address:10.10.0.1 Wow, I have no idea why it would ever do that. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57146&t=56884 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: NTP and Daylight Saving [7:57076]
Paulo Roque wrote: > > It4s exactly that kind of task I want to avoid ! > > Paulo > > ""Georgescu, Aurelian"" escreveu na mensagem > news:200211072134.VAA21948@;groupstudy.com... > > You have to set up daylight saving and time zone on each client, so they > > will know how to interpret the UTC. > > The NTP time is a binary number that is always referenced to UTC. So it knows nothing about timezone offsets. The latter is really a "cosmetic" display & entry option when the binary time is expressed in ASCII for us humans. So there is no real time value change due to DST; the internal value doesn't change at all. Only the entry and display offsets get changed. This is how Unix has worked for years. You can choose to have your devices display time any way you like. If you do nothing, they will display time as UTC. If you want them to reflect the local timezone, you must tell them what zone they live in. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57108&t=57076 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: odd IOS arp cache abnormality? [7:56884]
Cable Guy wrote: > > I am trying to clear arp-cache in IOS 12.1 and get unexpected results. Below > you see debug arp turned on, the current arp cache, then the clear command. > Immediately, the router sends out arp requests for the entries that were in > the cache. > > Why does the router immediately send arp requests when I attempt to clear > the cache? I would think it would wait till a need arose to send the > appropriate arp request, afterall, I do want to clear the cache? Is there > some way to prevent this? > > Further, looking at the debug #1 and 2, why is the arp request being sent > with target MAC address? This is more confusing. Why bother arping if it > knows the target MAC address? I can only think Cisco is saving some > bandwidth here. > The "clear arp" command has always been a misnomer. It more properly should be "refresh arp" because that's what it does. That's why it unicasts the ARP requests, to check if they're still valid, if the target is still there. > And a bigger question, why is the router sending itself an ARP...packet > number 3 below. Is it some sort of security measure? Does it do this at > startup too? The router is testing for a duplicate IP address. Hopes it doesn't get a reply. Yes, it does that any time the interface changes state to up, or the IP is changed. The only way I know to truly clear the arp entries associated with an interface is to shut/no shut that interface. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57107&t=56884 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: The Origin of Echos and Echo Replies [7:53148]
Priscilla Oppenheimer wrote: > > Interesting test. I think I understand it. ;-) > > Where are the debugs being run, by the way? The local router that is pinging > or the router at the other end? It looks like they are on the local router > doing the pings? Try running them on the other router. Be sure to turn fast > switching off on the other router. > > Regardless, what you are seeing makes sense considering this (unbelievable > but true ;-) discovery that pings to a local serial interface go out across > the serial link and bounce back from the router on the other end of the > link. So the subinterface on the other end of the link better be up, eh? > Here's another interesting test with a point-to-point WAN link (or PVC). Address the two ends as 10.0.0.1/24 and 10.0.0.2/24. 1) Ping the neighbor's IP -- typical echo & echo-reply. Note the RTT. 2) Ping the local serial IP -- packet is forwarded over to the neighbor, which routes it back. Initiating router receives and replies to its own ping. That reply is forwarded to the neighbor which forwards it back. Double the normal round trip time. 3) Now the teaser... what happens if you ping 10.0.0.3? Enable "debug ip icmp" on both routers and observe. :-) - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=53181&t=53148 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dhcp client cisco 2500 [7:52922]
Jason Yates wrote: > > How would I setup my ethernet interface, on my cisco 2500 running IOS 12.06, > to grab it's ip info from a dhcp server, or is this impossible? > You want: interface e0 ip address dhcp Works for me! - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=53164&t=52922 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: The Origin of Echos and Echo Replies [7:53148]
Priscilla Oppenheimer wrote: > > s vermill wrote: > > > > Anyone smart on interworkings of Cisco routers care to clarify > > something for me? I was in a discussion with someone in > > another forum. It was being discussed how pings from a local > > ethernet interface to a local serial interface on the same > > router actually cross the WAN to which that serial interface is > > attached and are returned by the distand-end router. > I'm not totally sure what you mean by "from a local ethernet interface". If you mean that the router forwarded a packet that arrived on its Ethernet interface, and the destination was its serial IP, then the packet will definitely *not* leave the router. OTOH, if the router itself is the source of the packet, and it pings its own serial IP, and the outbound interface and layer 2 encap are resolved and unambiguous, then the router will launch the packet out that p2p interface or PVC. I have done exactly what Priscilla describes, and not only seen the output from "debug ip icmp" on the neighbor router, but also observed it generating ICMP redirects, since the packet was forwarded out the interface it arrived on! This Cisco aberation is extremely useful for troubleshooting p2p WAN links. When the path has been looped (line protocol up (looped)), the only IP that is pingable is the directly connected one. That the router actually sends the packet makes it possible to test the link with ping. Now I wasn't performing an extended ping and sourcing the ping from a different interface. Maybe that's the difference? I last did this with IOS 12.0(7)T. Priscilla, I'm not saying what you observed is wrong! I don't have access at the moment to replicate it, but I'm positive of what I saw -- I had my students do it in class numerous times. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=53161&t=53148 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: How to force a gratuitous ARP [7:51674]
John Neiberger wrote: > > I'm planning on moving routing responsibilities from a router to our > 6513 and I *really* need to minimize downtime. I'll be moving an > interface IP address from one device to another and this is the default > gateway for all devices on that network. The problem is that all > devices on that subnet will have the wrong MAC address in their ARP > caches. I know that if I issue a unicast ping from the new router it > will force the end host to update its ARP cache but a broadcast ping > does not accomplish the same thing, probably because most devices ignore > a broadcast ping, and I don't feel like pinging every device > individually. > > I can't configure HSRP just to gain the benefit of gratuitous ARP; > simply configuring it will be disruptive and that's what I'm trying to > avoid. > With the new box being a Cisco, the good answer is you won't have to do anything. For many many years, Cisco routers have performed several operations anytime you "no shut" an interface or change its IP address: 1) ARP broadcast as a duplicate IP address test (and hope nobody replies). 2) Gratuitous ARP reply sent to the broadcast MAC. The latter causes every local host to blindly overwrite its previous ARP entry. Life goes on undisturbed... If you want to observe this behavior without a protocol analyzer, type "debug arp", then perform the change. Marty Adkins Email: [EMAIL PROTECTED] Chesapeake NetCraftsmen, LLC o:410.757.3050, p:[EMAIL PROTECTED] 1290 Bay Dale Drive, Suite 312 http://www.netcraftsmen.NET Arnold, MD 21012-2325 Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51692&t=51674 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950 CRC Errors [7:51419]
John Neiberger wrote: > > We've had nothing but bad luck with the 3C905C NICs. We've purchased a > *bunch* of low-end Dell PCs that have that NIC and they tend to get the > blue screen of death and then reboot if they're connected to Cisco > switches, especially when STP is turned on. Very odd behavior and we > haven't found a solution yet. We'd better come up with something fast > because we're getting more of those pieces of junk soon. > Here's an old Cat 5000 bug report that I saved: BugID: CSCdt68700 Title: Switch reports FCS, Alignment, Runts when 3C905C connected at FD Feature: counters Version: 5.5(6) Integrated: Severity: 5 State: C Release Notes: Under normal traffic conditions, a 100 Megabit, Full-duplex connection between any Cisco Catalyst Switch and a 3Com 3C905C will result in Layer 2 errors. The Catalyst Switch will report these Layer 2 errors as FCS, Alignment and Runt Packets. Troubleshoot this issue by reviewing the below guidelines and documentation. 1. Verify that both the 3Com 3C905C and Catalyst Switch are both set for auto-negotiate or both are manually set for 100 MB, Full-Duplex. A duplex mismatch will cause a higher rate of Layer 2 (physical) layer errored frames. 2. Load the lastest 3Com 3C905C driver available from www.3com.com 3. Load the diagnostic utility available with the lastest 3Com 3C905C driver. update.exe /diag) 4. Connect 2 test workstations with 3Com 3C905Cs back-to-back using a crossover cable. 5. Test Connectivity initiating a large file transfer between the workstations and noting the following counters with the 3Com Diag Utility. This test, the back-to-back between the PCs with 3C905C(s), will give a benchmark for performance and physical layer errors. According to the 3Com documentation, the details of the following counters are significant: Receive Overruns: Receive Overrun is the number of lost packets that cannot be stored in the receive buffer because the PC''s buffer is already full. Carrier Sense Lost: Carrier Sense Lost is the number of packets transmitted with a carrier sense loss. This normally occurs as a result of collisions. Transmit Underrun: Transmit underrun is the number of times a packets was transmitted without adequate data by the NIC. In respective the Catalyst Switch Counters, a packet transferred that results in the Carrier Sense Lost or Transmit Underrun incrementing on the 3Com NIC will cause at least one of the following counters to increase on the Switch: Alignment, FCS, CRC, Input Errors, Receive Errors, and/or Runts. Noting the errors and performance back-to-back between 2 PCs with the 3C905C NIC will give a minimum baseline for the number of errors reported by the switch and a generally baseline for performance. 6. Repeat step 5 with the PCs connected to the switch and baseline the number of errors to the errors recorded in Step 5. Expect a higher number of errors when the workstation is connected to the network as there will be higher load of traffic including multicast, unicast-flood, and broadcast traffic. Note: It has been noted that increasing CPU/BUS Speed on the workstation increases the number of Transmit Underrun packets recorded on the NIC and Runt Packets on the Catalyst Switches. In conclusion, this issue is not a Switch specific issue nor an issue with compatability. Please contact 3Com Tech Support for resolution. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51543&t=51419 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CCO: Token Ring Bridging and RIF Decoding [7:51295]
Sorry, folks. I forgot about the URL slurper. padding...padding...padding...padding...padding...padding...padding...padding... padding...padding...padding...padding...padding...padding...padding...padding... padding...padding...padding...padding...padding...padding...padding...padding... padding...padding...padding...padding...padding...padding...padding...padding... padding...padding...padding...padding...padding...padding...padding...padding... Marty Adkins wrote: > > One more treatment of an old topic, but rather well done. > FWIW, > - Marty http://www.cisco.com/warp/public/100/trb_rif.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51298&t=51295 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CCO: Token Ring Bridging and RIF Decoding [7:51295]
One more treatment of an old topic, but rather well done. FWIW, - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51295&t=51295 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: show process cpu and the interrupt value [7:49954]
bergenpeak wrote:
>
> When one does a "show process cpu", one is shown the overall information
> and then the breakdown per process.
>
> It's my understanding that the information shown on the summary line,
> specifically for the 5 sec information ("30%/24%"), shows the total
> CPU utilization and that which has been consumed handling interrupts.
> In the above snipet, the CPU was operating at 30% utilization over
> the last 5 seconds. A total of 24% of the overall utilization in the
> last 5 seconds was handling interrupts (or at least that's my
> understanding)
[snip]
Here's one more article to add to the reading list on this topic:
http://www.cisco.com/warp/public/63/highcpu.html
Marty Adkins Email: [EMAIL PROTECTED]
Chesapeake NetCraftsmen, LLC o:410.757.3050,
p:[EMAIL PROTECTED]
1290 Bay Dale Drive, Suite 312 http://www.netcraftsmen.NET
Arnold, MD 21012-2325 Cisco CCIE #1289
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=50086&t=49954
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: blocking spam with cisco routers [7:48971]
GEORGE wrote: > > Hi all I have a question ,I configured my e-mail server to only accept > local e-mail, and deny other relay , however im still vulnerable to > spam. My question is how do the ips block other e-mail going to their > smtp > Do they do it by access-list? Allowing only the local network with port > 25? > Or just the e-mail server? > If cisco routers have to be involved does anyone have some links. Im > behind a pix and would like to allow only my network to use smtp. Network layer filtering can't really do much to prevent relaying; it has to be done in the SMTP application. The techniques that I'm familiar with include: 1) Disallow mail sent to non-local (different domain) addresses unless the SMTP source is within the local domain, as resolved in a reverse DNS. This is simple but prevents one from sourcing mail while traveling, using a different ISP, at work, etc. 2) Same as #1 but require U/P authentication for outgoing mail. 3) Same as #1 but indirectly authenticate by correlating an outgoing mail connection with a "recent" successful POP3 fetch, which naturally requires a U/P. My DSL ISP, Speakeasy, does this and it works quite well. If you attempt outbound mail without having done a POP fetch in the last several minutes, an error message tells you that you must do that first. And BTW, none of these reduce spam, only the relaying of it! Marty Adkins Email: [EMAIL PROTECTED] Chesapeake NetCraftsmen, LLC o:410.757.3050, p:[EMAIL PROTECTED] 1290 Bay Dale Drive, Suite 312 http://www.netcraftsmen.NET Arnold, MD 21012-2325 Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=49018&t=48971 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: STP and 7 hops [7:44408]
Here's a pretty good explanation of the STP timers, diameter, etc. Understanding and Tuning Spanning-Tree Protocol Timers http://www.cisco.com/warp/public/473/122.html Much easier to follow than the IEEE standard. Marty Adkins Email: [EMAIL PROTECTED] Chesapeake NetCraftsmen o:410.757.3050, p:[EMAIL PROTECTED] 1290 Bay Dale Drive, Suite 312 http://www.netcraftsmen.net Arnold, MD 21012-2325 Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44463&t=44408 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: NAT dilemma [7:42762]
"Michael L. Williams" wrote: > > "Paul Lalonde" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > but > > routing out via an Ethernet interface will likely just *drop* the packet > > onto that broadcast domain (subnet) without pointing it to a specific next > > hop. > > This raises an interesting question: If you try to make a static route that > routes out an ethernet interface (multi-access medium), does the router send > the frame to the Layer 2 broadcast address? If so, then if there is another > router somewhere on that segment, wouldn't it hear and route the packet > properly, or would it see it as a layer 2 broadcast and it not go any > further? > One might think that a static route to a broadcast interface type would be ambiguous for layer 2, and it is. But what IOS does in that case is just ARP for the destination IP and hope it gets an answer. It will work, but only if some other adjacent router will perform a proxy ARP reply. Use "debug arp" to observe this. I used this trick several years ago when I didn't want to run a routing protocol on one interface and there were quite a number of potential next hops (long story). As for the original question... I compared the supplied config to mine and it should work, but then I have Comcast, not Roadrunner. I agree with Paul Lalonde -- just let the router learn the default route via DHCP (it works for me). Once you get it working, you'll want to add some things like an inbound ACL, pass the domain name to your internal DHCP clients, possibly extend the internal DHCP lease time, etc. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42781&t=42762 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ACL - Let's put some numbers on... [7:41738]
Anthony Pace wrote: > > I thought on some platforms there was a way to cache the ACLs and or policy > route-maps so they could be fast/CEF/mls switched. Like the logic got > copiled and pushed into silicon (or something like that). Is there any > vlaidity to that? > > Anthony Pace > Actually on ALL platforms, ACLs are fast or CEF-switched by default. You can use netflow feature acceleration on models and IOS releases that support that as well. ACLs have been fast-switched both inbound and outbound since IOS 10.0 (quite a ways back :) Policy routing has been fast/CEF-switched for several major releases. Yes, ACLs cause impact and yes, how deep it has to search for a match does make the difference. So the only true answer is to benchmark a case with typical traffic mix both with and without the ACL. The final solution is to use turbo ACLs or Cat6500 ACLs. The former finds a match in three lookups for any length ACL. The one action that does cause IOS process CPU time is the generation of an ICMP administratively prohibited unreachable message sent back to the source. That's why those are rate-limited to one/sec per source. And you can disable them entirely to prevent a DoS with "no ip unreachables". - Marty > ""Brunner Joseph"" wrote in message > news:[EMAIL PROTECTED]... > > Just remember if you run CEF on this router or fast switching (as you > > should) it will process switch if you apply access-lists to interfaces. > > > > Any time you apply ip policy (policy routing) or access lists it really > > hammers the cpu. Do you run MRTG ? If you do consider graphing the CPU of > > your router. I used to run about 80 to 100 % without cef, (process > > switching) now I run around 10 to 20 % with cef. Consider using "routes to > > null" or the bit bucket instead of access lists (unless your using the > ACL's [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42358&t=41738 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CCIE Written: Ethernet 802.3 Frames [7:21945]
Leigh Anne Chisholm wrote: > > 1. See Priscilla's response first. > > 2. Your query wondering about what protocols other than Novell that can use > the 802.3 frame makes me wonder if you have misunderstood encapsulation. > Novell's encapsulations were developed prior to the IEEE finalizing their > standards. They're Novell-proprietary. > > To illustrate this point, if you set the IPX encapsulation type to be > novell-ether and you typed "show ipx interface ethernet 0", you'll see > "novell-ether" on the Ethernet 0 interface. However, if you type "show > interface ethernet 0", you'll see that the encapsulation is ARPA which is > different than the IPX encapsulation on that same interface. > The reason that "show int" only displays the IP encapsulation is the same reason that only the IP address (and mask) are displayed, not all layer three addresses -- history. The cisco (sic) product line started out as only an IP router, so all displays and config commands were understood to apply to IP. As bridging and other routed protocols were added, the old commands and displays remained the same for backward compatibility. E.G., the command to change encapsulation for IP is just "encapsulation __", not "ip encapsulation __". And even before IP really took off, it was needed for managing the routers (Telnet, etc.), even if the overall enterprise had no use for IP. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=22044&t=21945 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: delay and delay [7:20926]
Priscilla Oppenheimer wrote: > > No, I think I misspoke. Sorry. You can configure both bandwidth and delay > for an interface. Just configuring bandwidth doesn't affect delay. You > would have to configure it separately. (Since delay is inversely > proportional to bandwidth, I would think it would change automatically when > bandwidth is changed, but it doesn't.) This is perhaps bordering on semantics, but as I understand delay (i.e., latency) it has no dependence on bandwidth. Delay is how long it takes the first bit of the frame to arrive at the destination. Whereas bandwidth determines how closely spaced the bits are and how long it takes until the last bit of the frame arrives. So to get the best approximation of delay, a ping should send the minimum size test data. (E)IGRP uses static "typical" values for the transit time of a given data link. A 10Mb Ethernet is assumed to take 1 ms and a WAN link is assumed to take 20 ms (your geography may vary :-) Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=21090&t=20926 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ports and Sockets [7:19701]
Priscilla Oppenheimer wrote: > > Socket has another meaning in the Unix world which I have never quite > understood. Perhaps someone else can explain that. Socket = logical connection = tuple of (remote IP, source port, dest port). The source IP is implicit. :-) - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=19708&t=19701 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: does vtp can span the router [7:18545]
Priscilla Oppenheimer wrote: > > VTP advertisements are sent to a data-link-layer multicast > 01-00-0C-CC-CC-CC. The SNAP type is 2003 which distinguishes the frame from > other Cisco frames that use that multicast (CDP and DISL, for example). > > As I said before, the router would have to be sitting in the middle of a > Layer-2 topology. For example, a one-armed router would pass VTP from one > subinterface to another, wouldn't it?? > > I'm just trying to explain the statement from a CIT book about the router > being in VTP transparent mode, which was the original question. Perhaps > someone else has more details. > I don't believe the router is going to forward any VTP datagrams at all, not between interfaces or subinterfaces. That is unless it is a BRouter with bridging enabled. :-) - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=18690&t=18545 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: 2900XL Console Access [7:14689]
John Kale wrote: > > Hi all, > > i have been trying to access a 2900xl switch thru the console port but this > has proven to be very fustrating. the only thing i have done is that i have > used all possible connection speed (all other setting remain the > same)connection is still nil (nothin at all on the windows hyperterm) > > all the 2900 i have tried (3 to be exact have the same problem) can somebody > help me please.i can connect to all other cisco devices. > Make sure your console cable has all eight wires and that the DB9 or DB25 adapter actually connects pins 1 & 8. Unlike routers, the XL switch console port uses hardware flow control. If a lead is floating (not connected), the switch sees that as a "don't transmit" condition. This causes it to just buffer up all the output. What you type is acted upon, but you see no display. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=15344&t=14689 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: port block unicast and multicast [7:12052]
Priscilla Oppenheimer wrote: > > Has anyone seen this and is there a workaround? > > On a Catalyst 1900 switch enterprise edition, the software has decided that > one of my ports should not flood unknown unicast or multicast. This > wouldn't be a problem except that the port is also my monitor port for > sniffing packets, and I WANT to see unknown unicast and multicast. I'm > trying to see EIGRP, CDP, etc. from a router connected to another port. The > monitoring is working, but I'm not seeing multicasts. > > SwitchA#show int e 0/1 > Hardware is Built-in 10Base-T > Address is 00B0.6426.7941 > MTU 1500 bytes, BW 1 Kbits > 802.1d STP State: Forwarding Forward Transitions: 1 > Unknown unicast flooding: Disabled > Unregistered multicast flooding: Disabled > Duplex setting: Half duplex > Back pressure: Disabled > > See how it says that unknown unicast and unregistered multicast are > disabled? It doesn't say that for any of the other ports. [snip] Priscilla, This is apparently an intentional side effect of enabling a port for SPAN/port monitoring, according to: http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/1928v8x/19icg8x/19icweb.htm#xtocid482036 So your analyzer would get only broadcasts until you configure it to monitor (copy) other ports on the switch. Those other ports will be getting unknowns and multicast so your monitor port will see a copy. I agree that this behavior is different than all the other Cisco switches including XLs, 4xxx, 5xxx, and 6xxx. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=12055&t=12052 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ping replies [7:10910] longish! [7:10910]
Priscilla Oppenheimer wrote: > > By the way, I stumbled on this somewhat helpful document: > > http://www.cisco.com/warp/public/63/ping_traceroute.html > > Couldn't find it by starting with the Tech Tips pages, but the search > engine found it when I searched on something bizarre. > Great article, Priscilla -- thanks for sharing! At 09:16 PM 7/4/01, Chuck Larrieu wrote: > >next - sending 1500-byte packets - get the big M! > > > >Router_1# > >Router_1#ping > >Protocol [ip]: > >Target IP address: 175.175.1.1 > >Repeat count [5]: > >Datagram size [100]: 1500 > >Timeout in seconds [2]: > >Extended commands [n]: y > >Source address or interface: l 0 > >Type of service [0]: > >Set DF bit in IP header? [no]: yes > >Validate reply data? [no]: > >Data pattern [0xABCD]: > >Loose, Strict, Record, Timestamp, Verbose[none]: > >Sweep range of sizes [n]: > >Type escape sequence to abort. > >Sending 5, 1500-byte ICMP Echos to 175.175.1.1, timeout is 2 seconds: > >M.M.M Success rate is 0 percent (0/5) > >Router_1# > >Router_1# > > > >irritating annoyance - note the M.M.M why aren't they all M's Actually I prefer M&Ms, doesn't everyone? Sorry, chocoholic attack. :-) The router which generated the ICMP message rate-limited same to no greater than one per second per source IP. It's one way that IOS tries to prevent one errant traffic stream from impacting others. Note that as soon as the first "M" was received by Router_1, it immediately fired off the second ping. Hence the downstream router decided not to generate another ICMP message, forcing Router_1 to time out (in two seconds). Ping #3 occurred more than one second after #2, so the ICMP message was generated. And so on... The more common pattern seen is "U.U.U" for host unreachable. To explain a bit further about the rationale, remember that the downstream router would really like to spend its resources successfully forwarding packets, in a fast-switching mode (fast/CEF/optimum/whatever). This is performed in interrupt mode. It's not possible to generate new messages in interrupt mode, so all exception cases must be handled by an IOS process (IP input). Doing this is more CPU and buffer expensive and competes with successful traffic flows. So IOS throttles this activity for each source IP, in case the source is brain dead or potentially malicious (a DoS attack). In fact, the fast-switching code can silently drop the unroutable packet without even scheduling a process to run. Thanks to both of you for digging and actually trying these on real gear -- it helps everyone learn much more thoroughly. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=3&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: debug !!! [7:10598]
Priscilla Oppenheimer wrote: > > To look at ip traffic he should use debug ip packet detail. (Be careful on > a busy production router. This displays a lot of info, and when you ask a > router to use CPU cycles to display output on the console instead of using > those cycles to route packets, you're asking for trouble.) > > To see traffic for just see one interface, try > > debug condition interface interface > > If you enter the debug condition interface command, the debugging output > will be turned off for all interfaces except the specified interface. I've > never tried this. I just discovered it in the documentation. It may be new > in 12.0. > You can enter multiple conditions which are logically OR'd such as multiple interfaces. The rest of the conditions are really targeted to access servers so you can select one ISDN call or one user out of dozens or hundreds. > To see specific traffic, he could apply an access list to debug ip packet, > as someone else suggested. But how much IP traffic does this point-to-point > link carry? It probably carries traffic for multiple IP sessions. So the > access list idea could be impractical... Remember that IP addresses are > end-to-end. > > So the interface condition is probably a better way to do it. > The access-list acts as a "display filter" in Sniffer parlance. One must also keep in mind what traffic is even eligible to be seen by debug, which is performed in the IOS process named "IP input". Fast-switched packets never make it there, since they are forwarded in interrupt mode, so one would have to inhibit route-cacheing on one or more interfaces. That's another reason it could cause a performance impact! Make certain that "logging console xxx" does NOT include debug; capture the display in a Telnet session instead. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=11018&t=10598 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ARP and TCP/IP layering [7:8335]
"Howard C. Berkowitz" wrote: > > OSI, in its _basic_ 7 layer form, is a useful tool for > conceptualizing and educating. That's it. Certain concepts, like the > generic relationship between layers, protocol encapsulation, etc., > are generally useful. But I assure you, from personal experience in > ISO, IETF, CCITT/ITU-T, and ANSI, nobody spends more than a few > seconds thinking about what layer something goes into. I wholeheartedly agree, Howard! What is very important to understand is ENCAPSULATION and the concept of protocol headers. It's crucial to know what layer is encapsulated inside of another. This is fundamental to both design and troubleshooting. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8544&t=8335 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Router Discovery Protocol [7:8470]
Priscilla Oppenheimer wrote: > > When a workstation starts up, it can multicast an ICMP router solicitation > packet to ask for immediate advertisements, rather than wait for the next > periodic advertisement to arrive. Although most routers support RDP, few > workstation IP implementations support it, so RDP is not widely used. RDP > is not the default configuration on Cisco routers. If had been the default, > like Proxy ARP is the default, RDP might have caught on. Interestingly enough, Windows IP stacks since Win95 Winsock2 have included IRDP. If you capture one booting, you'll see the solicitation multicast. And I _thought_ that recent U*nix stacks included it as well. E.G., Solaris included it, while the older SunOS required adding the client as a separate download and install. As for why it didn't catch on -- in a single router situation, it only takes care of part of the configuration on the workstation. The IP address and mask still must be statically entered, so why bother. IRDP is more flexible with multiple routers and priorities, but HSRP and later VRRP did the job with faster failover times, while totally transparent to the workstation. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8508&t=8470 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Route Updates and Fast Switching Cache [7:8110]
John Neiberger wrote: > > After reading a practice test question and answer I'm confused about the > operation of fast switching, specifically when a route has already been > cached when a new equal-cost route is learned via a different interface. > For example: > > Route A learns of 192.168.1.0/24 via e0 with a metric of 1000. Fast > switching is enabled so this route is cached. Then the router learns of > 192.168.1.0/24 with a metric of 1000 via e1. My thinking is that the cache > would be invalidated and recreated with two entries but the test engine > answer stated that routing would not change because the route was cached and > the cache would not be invalidated. > With the exception of CEF, all Cisco switching modes are demand-based. Only after a packet is successfully forwarded to a destination (via process-switching), will IOS add a route cache entry for _that destination_. So it's not as if the existing of a route/prefix causes a cache entry to be created; rather it's traffic generated. In your example above, all traffic to 192.168.1.22 would go via e0, as long as that remains valid. Traffic for a second host in 192.168.1.0/24 will go via e1. And so on. CEF does add entries to the FIB and AdjTable that directly correspond to routing table and ARP cache entries. It's not demand-based. > Any thoughts? I'd test this myself but at the moment I only have two > routers at home. Do any of you have any experience with this? Actually you can test this with just two routers if you can create two equal-cost paths with them. But you must create the traffic with a third device -- a host connected to a LAN interface. Switching modes only apply to packets that are in fact switched; i.e., forwarded. Traffic that originates within the router or terminates in the router is not fast-switched, nor process-switched -- it's not switched at all! If a ping is sourced from the router with two equal paths, the pings will alternate paths on a per-packet basis. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8153&t=8110 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: lab switch 2900XL or 5k? [7:7926]
Daniel Cotts wrote: > > The 3500's use the router like IOS. > The 2900 series that use the CatOS or "set" commands are the 2901 and the > following: > http://www.cisco.com/univercd/cc/td/doc/product/lan/c29xx/c2926/01intro.htm > Watch the wrap. > > The 2901 is no longer made. It is a two slot fixed configuration. The Sup > module is equivalent to a SupI. The interface blade has twelve 10/100 ports. > It will do ISL trunking. Similar to a 5213. > Provided that the Sup card has 20 Meg of DRAM, it will run 4.5.8 code. A > guess (without looking) at the eBay rate would be $1300-$1500 range. > If you have the budget then a 5505 with a Sup III and a 5225-R card would be > the way to go. The 5225-R will do ISL, 801.Q, and FastEtherChannel. I concur with 2900XL for a _truly_ IOS Catalyst. If you don't need gigE, then why buy the 3500XL just for lab use. They both run the identical software, tweaked slightly for the hardware differences. New releases are in lock step between them. The 1900 claims to be IOS but it ain't! It's an IOS "overlay" on top of a menu system. Fairly restrictive. But if you want a cheap switch that can handle VLANs and STP, it's an option. I also agree that the old discontinued 2901 is the cheapest way to get CatOS, but even with 20MB of DRAM, you're capped at CatOS 4.x. But it's fine for practicing syntax and almost all features, and all of the ports can ISL trunk (no 802.1q). It's a heavy and noisy monolith. Essentially a fixed-configuration 5002. You'll need a torx/spline driver to remove the blades. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8089&t=7926 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Rule 5-4-3 [7:7578]
Priscilla Oppenheimer wrote: > > At 04:18 PM 6/11/01, Jianfeng Wang wrote: > >Actually, the switch diameter rule is to keep spanning-tree protocol > >working. Cisco switches sets their echo time to 2s and forward-delay to > >15s. In which case, diameter larger than 7 makes spantree failed to work. > > Please do not send messages to me personally. If you are confident in your > comment, you will send it to the whole group and everyone can benefit. If > you aren't confident, then I don't want to hear it. > Sometimes that happens accidentally. If one does a "reply all" in the typical email client, [EMAIL PROTECTED] gets a "cc" instead of a "to". That bounces due to Paul's spam filter accepting only messages directly sent "to" the list. > I checked IEEE 802.1D more carefully and it does say the recommended > maximum diameter of a bridged network is 7. There's no such thing as an > echo timer, but the hello timer is 2 seconds by default. The forward delay > is 15 seconds by default, as you say. [snip] Back when there was only one STP -- the DEC one -- the seven-bridge guideline existed. DEC engineers said it allowed for conversative BPDU propogation, but also for serialization delay and WAN latency. Their spec allowed one (or two?) bridge hops to have a slow serial link, as low as 56kb. (Hey, back then 56kb was a common WAN speed!) With more than seven bridge hops, a frame might take longer than one second to travel end-to-end. That would cause DEC's LAT protocol (which can only be bridged) to time out and retransmit. If the max retry count was exceeded, the session was dropped. Someplace in my paper archives I believe I have the slides from a DECUS presentation that broke out the timing budget. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=8078&t=7578 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question on the meaning of "tunneling" [7:6136]
"Howard C. Berkowitz" wrote: > > In the most general sense, a tunnel is a means of taking a protocol > data unit payload of OSI layer N of protocol family P1: (N,P1)-PDU, > and transmitting it with a delivery header at layer M of protocol > family P2. What is actually transmitted is, minimally, a (N,P1)-PDU > encapsulated in a (M,P2)-PDU. There may be a "shim" between the end > of the delivery header and the beginning of the payload header; > there's no good OSIRM term for the shim. In a slightly less mathematical explanation: Think about the encapsulation steps while traveling down the stack. Are one or more layers repeated? If so, then tunneling is involved. Yeah, that's simplistic. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=6166&t=6136 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OT Looking for tech presentation tips [7:5111]
Priscilla Oppenheimer wrote: > > Ask your manager to send you to a class on doing presentations. You > shouldn't be expected to do this without training any more than the junior > engineers can do their jobs without training. In a training class, you will > get a chance to practice in a safe environment. You will also learn how to > handle questions. > Besides Toastmasters, I can heartily recommend Friesen, Kay & Associates' three-day Instructional Techniques workshop. I've sent a number of new instructors to it who found it very helpful. http://www.fka.com/ Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=&t=5111 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: GigE LX and SX interoperability [7:4545]
Scott Donoho wrote: > > We will soon have a lab setup that has two core routers that have GigE > LX(long haul) interfaces. We need to test connectivity between the two > routers with a switch in between. The problem is the switch we have has GigE > SX(not LX) interfaces. The physical cable distance will be very short(under > 400m). My question: will the switch have to have the LX interfaces in order > for this to work even at relatively short distances? or will the SX > interfaces work as well. I'm not sure what the difference is between SX and > LX is at the physical layer. TIA, > Besides the CCO reference, here's another good explanation (watch wrap): http://www.corningcablesystems.com/web/privnet/privnet.nsf/%28vwAllKeys%29%7CvwAllKeys/D1574C2BD2F2388B8525698A004DD6C5?OpenDocument Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=4632&t=4545 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Spanning Tree Protocol [7:2564]
Leigh Anne Chisholm wrote: > > It's a symptom of the problem I wrote about earlier in this thread. When a > MAC becomes active on the network, the computer isn't able to communicate for > the first 50 seconds the port detects the end-system is active. The port > begins in blocking mode, then transitions to listening, then learning. > Finally, once STP determines that a looped topology hasn't occurred, the port > is set to forwarding mode. This creates havoc with any end-system that > expects to receive over-the-network information within the first 50 seconds. > IP, IPX, AppleTalk - all face the same issue. > Well, this is picking nits, but the STP forwarding delay is only 30 seconds. The 50 second delay only occurs if the path to root is lost such that the root BPDU is not heard for maxage (20) seconds. A leaf user port only takes a 30-second hit. > The simple solution isn't to kill Spanning Tree on all switches - that's the > "I don't understand the problem so I'll do whatever works and create a bigger > problem" solution. The real solution is to enable portfast on all switch > ports that have end-systems directly connected. The caveat to this is to > ensure none of the end-systems are capable as acting as a bridge, forwarding > packets between LAN segments. Enabling portfast essentially disables > Spanning > Tree on a port - and Spanning Tree is used to ensure a loop-free environment. > Portfast doesn't disable STP at all. All it does is cause forwarding to occur without the conservative delay for listening and learning. The port still listens for BPDUs, will detect a topology loop, and will go into blocking to break that loop. But I definitely agree with Leigh Anne that it's a BAD idea to disable STP! But before STP ever gets a chance to do anything with a port, three other phases must complete: 1) speed/duplex auto-negotiation -- max of 3 seconds per the standard. 2) negotiation of trunking via DTP 3) negotiation of Etherchannel via PAgP The last two are typically very fast if the device on the other side is capable of negotiating. If not, then the retries for each can add up to as much as 15-20 seconds, depending on platform and code release. In CatOS, the macro "set port host" disables both of these and enables STP fast-forward/portfast. You can observe the progress by making the logging a bit more verbose: "set logging level spantree 6". And while we're at it, enable bpdu-guard so if someone does back-door and create a loop, the portfast-enabled port will be disabled. I'd love to see if that makes the Macs happy. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2949&t=2564 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst traceroute problem [7:965]
Shane Stockman wrote: > > My problem is that when I try to tracroute to a printer on a vlan it just > gives me the stars , but I can ping quite easily from the same switch.I had > a trace done from the mainframe and it stops at this switch and I had > another mainframe trace done from a mainframe in Europe and it still stops > at this switch.I can ping the printer address and get a 100% reply from both > mainframes. > Keep in mind that a traceroute performed by a Cisco or Unix device sends a UDP packet to a high (bogus) port (e.g., 33534). Since the target should have no application running at that port, it should reply with an ICMP port unreachable. It's possible that some device is filtering the UDP packets in the forward direction, or the ICMP unreachables in the reverse direction, while happily passing ICMP echo/echo-reply. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=965&t=965 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: traceroute !A * !A meaning [7:915]
"Howard C. Berkowitz" wrote: > > Only a suggestion, but the fact that there are pairs of !A suggest > that there might be per-packet load balancing going on, and the ACL > applies only to one of the paths in the load-shared bundle. That > could be why you get through on half the attempts (ignoring the * > timeout which I'll assume is a random error). > > If I were being truly perverse, though, I might think the load > balancing is across five paths, two of which have ACLs, two of which > don't, and one of which has a reachability problem. > > >You're right. !A is "administratively unreachable" which is generally an > >ACL... This almost certainly occurred on a single path. All three iterations were blocked by an ACL, which caused the router that did so to generate an ICMP administratively prohibited unreachable to the source. The generation of all ICMP unreachables is rate-limited by IOS to no more than one per second to the same source. Hence the packet was silently dropped on #2 which produced a three-second timeout at the source. To see the pattern, perform an extended trace and set the probe count to 5 or 7 -- notice that every other iteration is a timeout. This self-protection mechanism slows down a persistent sender, and aims to limit the potential impact on all other traffic flows. Generating ICMP messages takes extra CPU time, beyond just the ACL check, because all message generation must be performed by an IOS process, rather than in interrupt mode (fast-switching, etc.) Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=963&t=915 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ethernet vs. Fast Ethernet [7:515]
Priscilla Oppenheimer wrote: > > At 06:12 PM 4/13/01, Irwin Lazar wrote: > > >I know a few years ago several interface cards, especially those from Intel, > >had a heck of a time auto negotiating with Cisco Catalyst 5xxx's, but I'd > >imagine these problems are resolved by now. (It shows you how long it has > >been since I've actually touched a real network. :-) ) > > Not much has changed! Auto-negotation seems to still be a disaster. We hear > complaints about it not working all the time. Does anyone have a technical > answer (or URL) that explains why it behaves so badly? Just trying to > learn. Thanks.. > I wouldn't go so far as to characterize it as a disaster, as it does usually work. More specifically, speed almost always negotiates or auto-senses correctly. And if it didn't, someone would investigate immediately and correct it. Duplex negotiation is done after the speed is set, and that sometimes incorrectly auto-negotiates. When that happens, everything does work, but there will be a performance impact that is totally dependent on the probability of simultaneous traffic in both directions. Hence, a workstation with a single-tasking user may not exhibit a symptom, while a server could be severely impacted. As others have mentioned here in previous posts, look for "late collisions" on the half-duplex side. Some specific reasons I know of or have experienced that cause autonegotiation to fail: a) Older drivers for 10/100 NICs that just didn't do it right -- I ran into this with the Compaq Netflex III. Updated driver solved it. b) Early 10/100 NICs based on the National Semiconductor DP83840 chip failed to negotiate duplex correctly, if the cable length was between 35-41 meters (a typical office length!). NatSemi corrected this flaw in the DP83840A version, but all the existing products were stuck with this limitation. Not only did this include some desktop NICs, but also some early Cat5000 blades. See CCO bug IDs CSCdj53500 and CSCdj53272. c) Say one side, the switch, is set for auto-negotiate, and the other side, a desktop, is set to 10/half. Everything negotiates fine. Now what if the desktop changes its setting on the fly to 100Mbps. The 100Mbps fast link pulses produce enough signal in the frequency band of the 10Mbps link pulses, such that the 10Mb side never sees a loss of signal, so it doesn't realize there is a need to re-negotiate! One way this happens is when the desktop O/S changes it while booting. Even more subtle and less noticed is if the speed doesn't change but the O/S changes the duplex. The fix is to have the O/S driver momentarily drop signal whenever speed or duplex are modified. I recall 3Com 3C905 PCI cards and their driver producing this symptom. Workaround: pull the cable out/in or cycle the port. See CCO bug ID CSCdk28412. If anyone would like to read more than you want to know about auto-negotation, read http://www.scyld.com/expert/NWay.html, written by Bill Bunch of National Semiconductor. NatSemi contributed the technique to 802.3u. If you want to read about conformance testing, including auto-negotiation, peruse: http://www.iol.unh.edu/testsuites/fe/index.html at http://www.iol.unh.edu/consortiums/fe/index.html If you're into hardware chipsets, then follow the links at: http://www.scyld.com/expert/100mbps.html And as a great place to start on anything about Ethernet, Charles Spurgeon's site at U. Texas is still great: http://wwwhost.ots.utexas.edu/ethernet/ Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=659&t=515 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Check this one out ..... [7:537]
Priscilla Oppenheimer wrote: > > It makes it easy to have Internet connectivity in the kitchen or bathroom. > Gives a whole new meaning to PPP! ;-) > My, you are in rare form tonight! Keep in comin' :-> - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=558&t=537 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: AppleTalk on Support exam [7:269]
Priscilla Oppenheimer wrote: > > For those of you who have taken the Support exam recently, did you get any > AppleTalk questions? > I took Support 2.0 last summer and had a couple Appletalk questions. And since the latest version of the CIT course, v4.1, has moved Atalk to an appendix, that does beg the question of when the exam will get updated. They usually lag six months or so. For those who are interested, I still try to cover a quicky synopsis of Appletalk when I teach CIT. And we've kept it in the router and server configs, so there's some exposure. It's not just that Appletalk is still on the exam -- I think it's worthwhile for people to contrast the various methods of service location used over the years, vis a vis Novell and Microsoft. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=303&t=269 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CCIE Lab Report - unsuccesful
John Hardman wrote: > > I sniped most of your report below with the exception of point #5. I have > been trying to form a picture of the lab, trying to make it a part of me > that I visit on a regular basis. When I was in Taekwon-Do I found that the > more time I spent in visualization the better I got. It goes beyond just > "seeing it", but a total emersion in the expeirence. And this is what I have > been trying to do with the lab, so a little more detail will help me fill > out my vision... NDA permiting, what can be asked of the proctor? > For a little visualization, point your browser to http://www.tara.ca/ourlabs/ccie.html and peak at Halifax. They're redesigned their site -- they used to have a Quicktime 360 degree "movie" of the lab. Back when I was still teaching CCIE prep classes I used to show it to people. It helped take the edge off of the unknown. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ethernet address question
Priscilla Oppenheimer wrote: > > At 10:09 PM 3/23/01, you wrote: > > >Are you sure that the LAA bit applies to Ethernet? I've never seen > >that defined as such in any doc. Only for Token Ring. > >- Marty > > It's in IEEE 802.3. I just checked. And I bet you have seen it used! How > about in DECnet networks? The MAC address gets changed to be based on the > network-layer address and to start with AA. > > So, unless I'm twiddling the bits wrong, which is possible, since it is > early Saturday morning, and I didn't get enough sleep, I think that's an > example of an Ethernet locally-administered address. > You were twiddling correctly. I looked up the Ethernet V2 spec vs. 802.3 and found what you stated -- bit 1 (the 2nd from the LSB) is the LAA bit for 802.3, but _not_ for Ethernet V2. Since DEC was using AA-00-04-00-xx-xx prior to 802.3 being created, is it just coincidence that AA happens to set the LAA bit? And here's yet another fairly well-written reference on Ethernet/802.3 operation: http://ethernet.industrial-networking.com/articles/gthomas.asp - Marty _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: loopback the WIC card, how is it done?
"Bullock, Jason (1125)" wrote: > > Hey Listers. > > I was thinking about this cool thing one of the cisco TAC engineers did when > helping me troubleshoot a tricky network problem a few months ago. They > looped up my serial interface on a 2600 to verify the WIC card was working > properly, and that the attached CSU was not faulty. They configured the WIC > interface to show up and up , even though there T1 was down. > The problem is , I can not remember the command sets that were run to make > this work. ! Anyone know this one? ugh. > S/he probably had you do: interace s0 loopback which commands the serial NIC to assert the signal lead to the DCE called loopback. If the DCE (CSU/DSU or whatever) is optioned to obey this, then it will perform a local loopback. So whatever the router sends is reflected back to it on the receive side. Note this is totally different from the default HDLC keepalive message that is exchanged between the two routers. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: juniper and cisco
"Howard C. Berkowitz" wrote: > > >The thing is, Juniper's technology is based upon a central bus architecture > > shared memory, not shared bus. There is a difference. I don't > have the URL handy, but Cisco has a paper out by the Stanford > University professor who architected the GSR. It does a nice > comparison of the three basic architectures, shared bus, shared > memory, and crossbar. Shared bus runs out of steam at about 2Gbps, > and the 7500 is about the highest end Cisco product that uses it. > Junipers are generally shared memory and GSRs are generally crossbar. And Catalyst layer 3 forwarders (dare I say routers?) use the shared memory design, with some added wrinkles for QoS. (hoping not to get the hair up on the back of Howard's neck re terminology...) > >where as the new GSR routers have a processor for each interface card (as >the Juniper has one central CPU). > Rather than get hung up on how many "processors" and what that means, I prefer to compare them functionally the way Howard has espoused here before. There's a path determination function (software in some kind of processor/CPU) and there's a packet forwarding function. The latter can be done by line cards with their own CPUs, line cards with ASICs, or other hardware-assisted implementations. Now when an interface flaps or the path determination function gains or loses a prefix, what happens and which components are involved? - Marty _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: 2500 series e0 fullduplex?
Priscilla Oppenheimer wrote: > > Regarding the original question, though I couldn't find a URL to confirm > this, I don't think the Ethernet AUI port on the 2500 series Cisco router > supports full duplex. I think the 2500 routers came out before full duplex > Ethernet existed for one thing. Also, I doubt that it is possible to > support full duplex with an AUI attachment. You would need a way to tell > the transceiver to ignore collision detection, and that's probably not > supported. > The 2500 e0 is definitely half-duplex CSMA/CD only. It uses a LANCE chip as its "NIC" which predates fast Ethernet. AFAIK, there are no Cisco routers with 10Mb Ethernets that support full-duplex. Prior to the introduction of fast Ethernet in the industry, there were a few NIC vendors that added full-duplex capability to 10Mb cards. But it never really caught on; plus it was superceded by 10/100. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DHCP- Advise / Suggestions Apprciated
Gayathri wrote: > interface Ethernet0 > ip address 10.X.X.X 255.255.0.0 > ip helper-address 10.X.1.X > ip helper-address 10.X.1.Y > > The main reason we have 2 DHCP servers is for redundancy. > With both servers in the same physical LAN, you have redundant servers but not redundant network paths nor redundant layer 2. > Please note that they are independant of each other . > For a more robust redundant solution with true failover and incremental updates, you might want to check out Cisco Network Registrar (CNR). > Does this mean that , when the client is requesting, the router first > forwards to the first DHCP server and since it is not getting a response , > is dropping it? > No, as far as the router is concerned, this is a very simple operation. When a UDP-based broadcast is received on an interface with a helper statement, the destination port is compared to the list of ones to be forwarded. If it's one of those, then the destination IP in the packet (255.255.255.255 or subnet broadcast) is overwritten by that specified in the helper-address. The packet is then routed just like any other. If the port type is DHCP/BOOTP then the router fills in the giaddr field so the DHCP server knows the correct client subnet. If there are two, three, twenty helper-address statements, then the router just repeats all this for each in turn. The first DHCP server in the list will likely get the request first, but which repsponse actually comes back first is a horse race. DHCP client and server code deals very gracefully with multiple responses (see the RFC). Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
"Howard C. Berkowitz" wrote: > > I wasn't aware of that! Thanks. > > But isn't loop detection also a PPP option? > Yes, it's described as part of RFC1661, but it might be a catch-22. The magic number field used for this is optional and must be negotiated. Cisco routers do attempt magic number negotiation and do detect looped paths, and let me check current doc... DO maintain a line protocol up status as long as "down-when-looped" has NOT been configured. So you're quite right -- for Cisco to Cisco, PPP and HDLC will both treat this the same way. OTOH, if the encapsulation were frame-relay or some other, then a loop causes a line protocol down state (e.g., LMI or ILMI polling fails). With Cisco to non-Cisco, particularly Ascend Pipelines, I have seen the magic number negotiation fail, and the Cisco reported a loop condition because the Ascend was echoing back the packet with the Cisco's magic number. But that was a while back. So thanks, Howard, for responding! - Marty > At 10:16 PM 2/19/2001 -0500, Marty Adkins wrote: > >"Howard C. Berkowitz" wrote: > > > > > > HDLC really doesn't offer any advantages over PPP, so it really > > > reflects someone who doesn't want to do minimum reconfiguration of > > > their Ciscos to worry about using PPP for multivendor compatibility. > > > > >Well, one small advantage is that Cisco's proprietary HDLC keepalive > >will report a loop condition on the layer 1. And it will also, by > >default, treat a looped interface as "line protocol up", which is > >great for testing, using just the router. > > > > Marty Adkins Email: [EMAIL PROTECTED] > > Mentor Technologies Phone: 240-568-6526 > > 133 National Business Pkwy WWW: http://www.mentortech.com > > Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: HDLC
"Howard C. Berkowitz" wrote: > > HDLC really doesn't offer any advantages over PPP, so it really > reflects someone who doesn't want to do minimum reconfiguration of > their Ciscos to worry about using PPP for multivendor compatibility. > Well, one small advantage is that Cisco's proprietary HDLC keepalive will report a loop condition on the layer 1. And it will also, by default, treat a looped interface as "line protocol up", which is great for testing, using just the router. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: T1 Link
Priscilla Oppenheimer wrote: > > Yup, SLARP is pretty cool. It's one good reason to use HDLC. It makes > configuration so easy. Also, the students will love saying SLARP. I'm > helping out with the academy at our local high school, as I've mentioned > before. Those students will love saying SLARP, over and over and over again. > Unless autoinstall has changed in the last year or so, it used to first try HCLC, then PPP, then Frame Relay, and I think there was a forth one. Yes, SLARP is very cool... when you want it. When you don't, it sure adds a bunch of time -- if the SLARP succeeds, then IOS gets very patient broadcasting rDNS, TFTP, etc. etc. > I'm having a hard time, in general, teaching networking to kids who don't > really love it and don't have to know it for their jobs. I got spoiled, > teaching classes to people who had paid money to be there and needed the > info to survive on the job. I'm sure it's quite different at a community > college, but you probably get some young people too. Any advice?? Thanks! > Hmmm, tell them you're going to teach them TCP/IP operation so they can learn how to tweak their TCP stack and soup up those Napster downloads! :-) :-) - Marty _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: A question
Kathy Miihalisko wrote: > > Saswata, > > Very interesting, took a cue from Chuck and attached the following, does any > of this look familiar? > > WHAT MICROSOFT SAYS: > > For a device running Windows CE 3.0, if this attempt to locate a DHCP server > fails, the DHCP client will auto configure the stack with a selected IP > address from the Microsoft-reserved class B network 169.254.0.0 with the > subnet mask 255.255.0.0. This process is called Automatic IP (Auto IP). Auto > IP is enabled by default. To disable Auto IP, update the AutoCfg registry > key. The DHCP client will test, using a gratuitous ARP, to be sure that the > IP address the client has chosen is not already in use. If the address is in > use, the client selects another IP address. The client repeats this > selection process for up to ten addresses. Once the DHCP client has selected > an address that is verifiably not in use, the client configures the > interface with this address. The client continues to check for a DHCP server > in the background every 5 minutes, or according to the interval specified by > the AutoInterval registry key. If a DHCP server is found, the auto > configuration information is abandoned and the configuration offered by the > DHCP server is used instead. [snip] IOW, it only took Microsoft about 15 years to figure out how to emulate the auto address acquisition of an Apple Mac. :-) MS calls it plug and play IP (pnpip) as described in http://msdn.microsoft.com/library/backgrnd/html/pnpip.htm Also see RFC 2563. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Router ID in OSPF
"Howard C. Berkowitz" wrote: > > >Hi everybody: > >I am study BSCN,there are something confused me: > >in the book they says:The highest IP address on an active interface is > >normally used as the router ID, but this can be overridden by configuring an > >IP address on a loopback interface. > >I want to know which will be the Router ID if the loopback IP address > >smaller than the active interface IP address? > >Any suggestion will be appreciate,thanks. > > > >Will Guan > >frome Peking, China > > If there are multiple loopback, the router ID will be the numerically > highest IP address on any loopback. In other words, [snip] And the part that some folks forget is that once a router ID is active, it will not change if another interface is made active, or the IP of another interface is changed to a higher value. The rationale is stability, since all other routers in the area are tracking this one by its present router ID. The same principle applies to the DR election -- there is no coup option. Now if you were to shut down the interface with the existing router ID... Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Last Nights DC Cisco Meeting
"Howard C. Berkowitz" wrote: > > To the city fathers of San FranCISCO: > > Be afraid. Be very afraid. > Don't you know that Cisco already consumated that one in 1995? :-) And who can forget the heated internal debate that eventually led to the capitalization of the name from cisco Systems to Cisco Systems?! - > CISCO SYSTEMS TO HAVE CITY RENAMED > >San Jose, California, September 8, 1995 -- Cisco Systems, Inc., > (NASDAQ: CSCO), the leading global supplier of internetworking solutions, > today announced their agreement with San Francisco, CA to rename the city. > Coming on the heels of the 3COM/Candlestick agreement, the city has agreed > to accept $5,000,000 over a period of 5 years to have the name shortened > to Cisco, CA. > > According to a company spokesman, "When we saw how easily the city of San > Francisco had rolled over for the 3COM deal, we knew we had an excellent > opportunity. The chance to reinforce Cisco's presence in the networking > community and the world at large is something that we just couldn't afford > to pass up. For the price, it's quite a steal." > > 3COM officials declined to comment on a report that they had tried to > block the deal due to their concern that 3COM Park (formerly Candlestick > Park) would now be located in Cisco, CA. > > "With the number of national and international visitors, TV coverage, and > the 1999 Superbowl to be held in the newly renamed city, Cisco will > continue to extend its reach into every facet of the networking world," > said the spokesman. "We are proud of the outstanding accomplishments of > our employees and partners in fiscal 1995 and we see this as an excellent > opportunity to reward them for their dedication." > > Cisco Systems, Inc. is the leading global supplier of enterprise networks, > including routers, LAN and ATM switches, dial-up access servers and > network management software. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CID book
"Howard C. Berkowitz" wrote: > > Amen. One of the realities of publishing is that even if it were > possible to have enough reviews to catch every error, the book would > be far more expensive and would come out too late to be useful. Even > if the book were "precise," how does the author deal with situations > where the Cisco material from which it is drawn is obsolete or wrong? > For that matter, errors do find their way into RFCs, and are > corrected in future editions. > > >Wouldn't it be better to > >write - "Dear Author... I don't know if you know this > >but I think page 43 has a mistake. Could you comment > >on this?" I wrote all 13 chapters of CID, and yet I > >would never claim that it was entirely my product. > I can't resist passing along Terry Slattery's response on the topic of errors in books, submitted to the comp.dcom.sys.cisco newsgroup back on 7/5/99: It is interesting that you quote Knuth's book. It was the model that Bill Burton and I used for our Quality Challenge in _Advanced IP Routing in Cisco Networks_. We pay $1 per error and send a certificate which lists all the bugs you find (some folks have found several). It's really hard to make a 500 page book perfect. We're up to 160 bugs on our web site: http://www.ccci.com/books and I still have about a dozen more to process. We're a bit behind in sending out the certificates and award, but they will all be sent. [I'm spending a *lot* of time doing software for the MentorLabs vLab(sm) Cisco remote lab system.] Fortunately, most of our bugs were typographical. It is gratifying that people will send bug reports. We used a web page that lists them so we don't get repeated submissions of the same bug. The only problem is when the we didn't clearly understand the bug and provide the correct fix the first time. Thanks to the really smart readers, we quickly identified the real fix. We've fixed all 160 bugs in the latest submission to McGrawHill and I think they will all be fixed in the 4th printing. -tcs ps. Knuth's reward was $2.56 (hint: it isn't a coincidental figure). I know someone who received a check from Knuth and framed it. He probably sent out a number of checks that were never cashed. So even Knuth didn't make it with no bugs. > I disagree with you (2.- No book is ever 100% correct...) > "Fundamental Algorithms, The Art of Computing Programming, Vol 1. Donald > E. Knuth, on the preface at the botton "I will gladly pay $2.00 reward to > the first finder of each remaining error, whether it is technical, > typographical, or historical." > > i don't mind receive $2.00 per error, from Gilles' books :-) > > On Mon, 5 Apr 1999, Michael Salvagno wrote: > > > Date: Mon, 05 Apr 1999 06:42:04 PDT > > From: Michael Salvagno <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Subject: Re: Cisco CCIE Study Guide > > > > Jack, > > > > After reading your eloquent request, I have to disagree that a free > > book should be send to you by McGraw-Hill. > > > > Why? > > > > 1. Everyone that purchased the first book did so under the assumption > > that they would learn and get a jump on Cisco knowledge. (I know that I > > did) The fact that you are aware of numerous errors, points to the > > assumption that some learning did take place. In fact if you do see the > > errors you are well on your way to mastering the material. > > > > 2. No book is ever 100% correct. I would think that it is assumed by the > > those that write that "out to press quicker" is what the public wants > > rather than getting all the details perfect (which will never happen). > > If the book publisher did not care about technical details, an errata > > would never have been published. > > > > > > I do think that possibly a scenario much like software upgrades would be > > better. When you purchase a technical book, you receive a code that will > > allow you to upgrade to a later revision at a reduced price. > > But getting a free book or demanding one puts undue financial contraints > > on the book publisher and author. > > > > This is just my opinion, and stated as such I do not in any way > > represent McGraw Hill. > > > > Best Regards, > > Mike Salvagno > > > > = > > > > > > Dear Gentlemen, > > > > "...Some time ago I purchased Giles' book mentioned in the subject line > > above. I must say, I am very disappointed in the number of errors I > > found. I appreciate the fact that your publishing company recently > > posted Updates and Errata on your website. However, there are so many > > errors, it is a painstaking process making the changes--it is no wonder > > a second publication is being made..." -- Terry SlatteryCCIE# 1026 Chesapeake Computer Consultants, Inc. 410-280-8840, ext 3021; Fax 410-280-8859 [EMAIL PROTECTED] http://www.ccci.com --
RE: Nagle's algorithm
Here's an old one I saved in my archives but you could probably search for it on nexial as well. The main situation it addresses is the use of a router as a commserver, with a dumb terminal attached or dialed up. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 > Received: from spot.Colorado.EDU ([EMAIL PROTECTED] [128.138.129.2]) by >ccci.com (8.8.5/8.7.3) with ESMTP id TAA18611; Wed, 26 Feb 1997 19:27:06 -0500 (EST) > Received: (from daemon@localhost) > by spot.Colorado.EDU (8.8.5/8.8.4/CNS-4.1p) > id QAA17553 for cisco-ml1; Wed, 26 Feb 1997 16:19:40 -0700 (MST) > Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) > by spot.Colorado.EDU (8.8.5/8.8.4/CNS-4.1p) with SMTP > id QAA17120 for <[EMAIL PROTECTED]>; Wed, 26 Feb 1997 16:19:19 -0700 >(MST) > Received: (billw@localhost) by puli.cisco.com (8.6.12/8.6.5) id PAA13961; Wed, 26 >Feb 1997 15:16:43 -0800 > Date: Wed, 26 Feb 97 15:16:43 PST > From: William "Chops" Westfield <[EMAIL PROTECTED]> > To: Crocker Sean SSgt 786CS/SCBM <[EMAIL PROTECTED]> > Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > "'KRATOCHVIL.KEITH'" <[EMAIL PROTECTED]>, > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: RE: Nagle question > In-Reply-To: Your message of Wed, 26 Feb 1997 21:27:23 +0100 > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text > > Actually Paul did, just in a truncated manner. What he is saying is > that enabling the Nagle algorithm on the router will affect the traffic > that is originated directly FROM the router or is addressed directly TO > the router (hence "terminated"). > > So your guess is correct, it's the characteristics for the router as a > host or end-station. Service nagle is especially good to enable if you > are, say, telnetting to the router via a 56 kbps link or slower. > > I asked the same question last year, answered by Paul. I had to reread > the docs for a bit before the filament would start glowing :-). > > It's worth pointing out while we're talking about this, that as far as I can > tell, the "slow start congestion avoidance" algorithms mandated by various > sources pretty much devolve to the Nagle algorithm for connections with > non-continuous traffic (ie always doing "slow start" == "Nagle algorithm") > > I thought that was pretty neat when I realized it, but it also means that > a slow-start tcp might be subject to some of the weird interactions that > cause the Nagle algorithm to be off by default in a cisco... > > BillW > cisco > > _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Switching method help!!
Tony van Ree wrote: > > Hi, > > I understand yes that CEF can assist with load balancing but, be aware it must be >set at both ends of a service as I understand it. Unfortunately I don't know enough >about CEF yet. We do however have it configured in a number of instances. > > Teunis, > Hobart, Tasmania > Australia > The packet forwarding process is independent on each router, but to get the benefit of load-sharing by source and destination pairs, in _both_ directions, both ends would need to use CEF. For the group, here are a couple more links that explain CEF and other switching modes in more detail (no CCO account required): How to Choose the Best Router Switching Path for Your Network http://www.cisco.com/warp/public/105/20.html Performance Tuning Basics: http://www.cisco.com/warp/public/63/tuning.html Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 > On Friday, December 15, 2000 at 11:27:59 AM, Priscilla Oppenheimer wrote: > > > Fast switching definitely has the problem you refer to. Fast switching > > offers per-destination load-sharing. Since the router caches information on > > how to forward traffic to a destination, all traffic to that destination > > exits the same interface. > > > > One of the goals of CEF was to overcome this problem. I can't remember the > > details, but I think you can do more precise load-balancing with CEF. I'll > > see if I can dig up more details and get back to you. Or maybe some other > > folks who use CEF can chime in. > > > > Priscilla _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: simulating delay on Cisco routers in test bench
You might experiment with traffic shaping. If you set it low enough you will decrease the routers effective use of the available bandwidth. Note this will NOT lower the delay. But it might approximate what you're looking for. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 Priscilla Oppenheimer wrote: > > At 11:06 AM 12/6/00, you wrote: > >Hi Priscilla, > > > >Is there a way to increase the round trip delay (expected delay 400ms) > >between two back to back connected CISCO routers using an IOS command. > > > >This is to simulate a satalite link delay between two CISCO routers ( > >approximately 400-600 ms) on a test bench. > > > >Appriciate your attn and response. > > > >Thanks > >msrfernando > > Hm. That's a good question. I'm thinking aloud here > > You can reduce the bandwidth with the bandwidth command, and then delay > increases. But that is just from the point of view of EIGRP routing > metrics. To really increase the delay is a lot harder. You could add a > bunch of access lists and other features so that the router gets bogged > down processing, but it would be a lot of work to get this calibrated to > the exact delay that you want. > > Could you use a simulation tool instead? Have you looked into Cisco's > Netsys product? Another good product is NetPredictor from > http://www.netpredict.com. > > You should send this question to the Cisco Group Study list. I hope you > don't mind if I copy them. Any ideas, folks? Thanks. > > Priscilla _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Master Clock Source
Jason Roysdon wrote: > > Do you have a Unix box you can host NTP from? Might try that as a source. > Also, if this box is losing time, don't set it as an ntp master (it > shouldn't be serving out bogus time). Oh, think I may have found your > problem, try assigning a stratum to your master: > ntp master 15 > Or you can use an NT or other WinThing with Tardis: http://www.kaska.demon.co.uk/ > I'd set 15 as it's the lowest (especially since you have no true contact > with an accurate source), and hopefully that'll let you get time to your > misbehaving box. I tested a bit on some routers I have, and whenever I set > bogus times, checked that it did get set bogus, and rebooted, they always > got the right time when they came back up from the ntp master they were > configured to poll. > I agree it should work; has for me plenty of times. Troubleshoot this with #debug ntp xxx. Remember that NTP does a number of polls before it actually sets the time, so you may have to wait a minute or so. > -- > Jason Roysdon, CCNA, MCSE, CNA, Network+, A+ > List email: [EMAIL PROTECTED] > Homepage: http://jason.artoo.net/ > Cisco resources: http://r2cisco.artoo.net/ > As for the calendar part -- AFAIL, only 7000 routers have that $2 Dallas watch chip included. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 > ""Rossetti, Stan"" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > We have a problem on our netowork where the router lose their clock > settings > > when the router reboots. The network is a closed network and does not > have > > any outside sources like an ntp server. Is there anyway to maintian the > > clock even when the router is rebooted. I have tried setting the clock > and > > calendar and then using the "ntp master" and "ntp peer" commands, but the > > peer routers clock does not update when I change the master router clock. > > Is there something that I m missing here. I also tried using the clock > > calendar- valid, but could not get the peer router to update it's clock > when > > I changed the master clock source. How does the clock calendar-valid > > configuration work. I mean do I need to apply this command to all routers > > in the network? > > > > Thanks, > > > > Stan Rossetti _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Perplexing: DHCP fails from Ethernet segment to Token Ring segment
Paul Lalonde wrote: > > Hello all, > > I've configured a Cisco 2513 router to do full bridging between its Ethernet > port and its Token Ring port. I'm using plain transparent bridging (bridge > 'x' protocol ieee). > > The network is broken down into two segments: one switched 10/100 Ethernet > segment, and one Token Ring segment. The Cisco 2513 sits in between the two. > > Currently, the majority of the workstations and servers (including an NT > Server running DHCP services) are on the Token Ring side. > > Initially, I had problems bridging the two segments together because of > MAC-address bitswapping issues (Token Ring uses an inverted MAC address, > Ethernet doesn't). > > These issues have been resolved by using the 'bridge > bitswap-layer3-addresses' command. [snip] The 12.1 doc says this feature operates on ARP and RARP messages. It doesn't mention any others (e.g., BOOTP). http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ibm_r/brprt1/br1dtb.htm#xtocid274036 Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Frame Relay test tool (must be SW)
Serhat Erkan wrote: > > Hi Dave, > I didn't use them because our routers don't support this commands (3661 & > 1750) > Here is the output. Is there any other method ? > > Regards.. > > Router#ttcp > Translating "ttcp"...domain server (255.255.255.255) > Translating "ttcp"...domain server (255.255.255.255) > (255.255.255.255)Translating "ttcp"...domain server (255.255.255.255) > % Unknown command or computer name, or unable to find computer address At one time, ttcp was only in the enterprise feature set. But you could still use the standalone version on your favorite workstation. Read about it here: http://www.mentortech.com/product/network_mon/tnm31/ttcp.htm http://www.mentortech.com/product/network_mon/tnm32/ttcp.htm and download from: http://www.mentortech.com/learn/tools/tools.shtml Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Redistribution
I agree with Chuck. However, the default coefficient (K) values cause the effects of load to be ignored. So it worked and noone noticed the minor error until you scrutinized the config. Cendant? I just taught a CIT class in NYC to two folks from there... Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 Chuck Larrieu wrote: > > Probably the person who did it originally did not understand how the metrics > should be set up. > > Reliability goes low to high. Lower is more reliable. > > Do a show ip protocol and look at the K values that are reported. I'm > curious as to what they might show. > > Chuck > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > James Haynes > Sent: Wednesday, November 22, 2000 9:34 AM > To: [EMAIL PROTECTED] > Subject:Redistribution > > Hi all, > > I recently took a job at a new company and one of the first tasks I've been > given is to go over the configuration and documentation of one of the WANs. > While going thru the router config's I have found some redistribution > commands that are, to me, not making sense. They are: > > router eigrp 113 >redistribute static metric 1544 100 255 255 1500 >redistribute rip metric 1544 100 255 255 1500 route-map rip-to-eigrp > > Now, these are not difficult commands in and of themselves and are readily > understandable. The thing that has me puzzeled is the value of the metric > for Load. Here the values for load are equal to 255. This to my > understanding represents a fully loaded route. Am I correct? If so, why > would one want to do that? If I'm not correct what is the correct > interpretation of the above values. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: !H
Priscilla Oppenheimer wrote: > > H means host unreachable. Jumping to the conclusion that there's a routing > problem isn't logical (though I know that what's the Tech Note document > says.) The host could be turned off. A host unreachable happens when the > last-hop router tries to ARP for the device and doesn't get a response. > This isn't what I've seen and captured with a protocol analyzer, nor viewed via debug. If any router is missing an ARP entry (or any other type of next-hop data link address), it will silently drop the packet. The output of "debug ip packet" will report "encapsulation failed". OTOH, if any router in the chain lacks a route to the destination, that router will generate an ICMP _host_ unreachable, not network unreachable. I agree this is not intuitive, but here's the screen output from a WinThing attempting to ping a bogus address, and the debug output from its default gateway: C:\WINDOWS>ping 10.0.0.1 Pinging 10.0.0.1 with 32 bytes of data: Reply from 192.1.63.196: Destination host unreachable. Reply from 192.1.63.196: Destination host unreachable. Reply from 192.1.63.196: Destination host unreachable. Reply from 192.1.63.196: Destination host unreachable. Ping statistics for 10.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms -- 06:47:58: ICMP: dst (10.0.0.1) host unreachable sent to 192.1.63.198 06:47:59: ICMP: dst (10.0.0.1) host unreachable sent to 192.1.63.198 06:48:00: ICMP: dst (10.0.0.1) host unreachable sent to 192.1.63.198 06:48:01: ICMP: dst (10.0.0.1) host unreachable sent to 192.1.63.198 Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IS-IS use?? [gets O-T]
"Howard C. Berkowitz" wrote: > > The direct ancestor of IS-IS is DECnet Phase IV routing, principally > designed by Radia Perlman. DEC contributed its work to ISO, and > IS-IS was initially developed as a pure OSI routing protocol (i.e., > for CLNP). IS-IS became the native IGP for DECnet Phase V, which was > OSI (protocol, not just model) at its lower layers. This was at a > time when many European governments, and their PTT's that dominated > international standards, were very anti-IP. I am _not_ making it up > when I quote, from my experience in OSI standards committee, European > PTT people saying they would not accept a protocol suite "designed by > the bomb-crazed American military." > Back in 90-91, Ross Callon of DEC was leading the technical charge on IS-IS standardization. DEC was arguably the premier networking vendor at the time, and had considerable clout in the committee space. And let's not forget that John Moy was at DEC before he went to Proteon, where he developed OSPF, borrowing a number of the same terms and mechanisms (link "cost", hellos with neighbors, etc.) > In 1986-1988, the US government issued the Government OSI Profile > (GOSIP), which mandated OSI protocols for future government use. > Integrated IS-IS, in part, was intended as an interim protocol to use > while people migrated from proprietary and IP protocols to OSI. > The USG was forced to grant waivers left and right, because most vendors did not have robust OSI stacks to offer. Everyone wanted others to go first, to incur the big R&D expense. Those vendors that did so wanted to recoup their investment (e.g, DEC). But they found reluctant buyers; the classical critical mass problem. While vendors talked a good line, customers watched and waited, and found the slim offerings to be lacking. In the mean time, IP did an end run. One of the important reasons was that standards development followed the IETF model -- draft, RFC, test interoperability between at least two independently constructed versions, modify as necessary; then declare as standard. The ISO approach at the time was to have equal political representation from many countries, over-specify tons of complexity, declare it a standard; then go build it. Later GOSIP issued a relaxed version of the mandate, saying that OSI was still preferred, but that TCP/IP could be used where OSI was not possible or practical. Finally they just threw in the towel and stopped pretending. Large U.S. corporations were already on board the TCP/IP bandwagon. Europe lagged but eventually succumbed, once their corporations followed the universities, and ignored the wishes of the PTTs. > Of course, market forces drove the world to the IP protocol suite. I > hate to say IP won the war over OSI; it's more that the two > intermarried. The good protocol things in OSI have wound up in IP, > and the bad things are mostly forgotten. > I thoroughly enjoyed attending Interop (back when it was mostly technical) and hearing Marshall Rose speak. Admittedly an IP bigot, he proclaimed "OSI is the dream, and TCP/IP is living it!" Quite accurate when you think about it. The laudable goal of OSI was to create a layered model to which hardware and software vendors would design their wares. Customers would benefit from more choices (competition) at each layer, and product designers would be able to more rapidly introduce innovations within a layer without impacting other layers. Networking would become ubiquitous and cheap. Gee, kinda sounds like the recent history of IP (and Ethernet). :-) This standardization "craze" grew from the disgust of customers tired of having to buy their cables from the same company that sold them the O/S and the applications, and the big iron, and so on. BTW, Marshall rose was a prolific programmer who knitted such combinations as CMOT (CMIP over TCP/IP) and other hybrids. He also liked to poke fun at how fragile and unfriendly X.400 email transports were in those days. (I know -- I built an X.400 gateway between VAXmail, Data General X.400, IBM PROFS, SoftSwitch, and public X.400 carriers. Since DEC was pushing it, we used it to communicate with our DEC salespeople. But we quickly found that we should send all messages via X.400 and SMTP, since the latter always worked, or at least gave a NDN message reply. Marshall would pose the question to an audience: if an SMTP user and an X.400 user meet at a conference and exchange cards with email addresses, how to they communicate? A: the SMTP user sends a message to the X.400 user, whereupon the X.400 user saves that sender address for future replies. Corollary: what happens if two X.400 users meet at a conference and exchange cards and addresses? A: They pick up the telephone... :-) Folks, if you've never typed in one of these obscenely long addresses, you&#
Re: WFQ & FR
Fanglo MA wrote: > > Dear ALL, > > I have some congestion found with my Internet with is connected to the > provider via FR. From the setting configurated by ISP, the no fair-queue > is set on the FR link to ISP. I would like to ask if this is any > negative impact on FR with fair queue so that make it be default to FR > setting? What consideration should I consider to implement queueing > policy to help improving congestion in my case? I know I should collect > baseline performance for further evaulation, does anyone can advice how > to collect such information? My router is low-end 2500 cisco running > 11.3 feature. > If the issue is congestion, then weighted-fair queueing won't affect that. WFQ can change the order of packets as they leave an interface, but doesn't change the total _amount_ of packets. (Except to the extent that it helps latency-sensitive apps/transports avoid a retransmission.) If you're identifying congestion by the FECN/BECN counters in the output of "show frame pvc x" and you are pretty sure that the frame cloud is dropping frames during bursts, then frame relay traffic shaping may help. It will take some empirical tuning, because each provider can police differently, but for a starting point, shape the hub site output to equal the remote site's port rate. HTH, Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ethernet Trivia
Priscilla Oppenheimer wrote: > > At 01:03 AM 10/8/00, Jeff Kell wrote: > >Priscilla Oppenheimer wrote: > > > > > Does this help at all? Speed of light in twisted-pair cable is 177,000 > > > km/sec. So a bit occupies 177,000 divided by 10 million bits per second, or > > > 17.7 meters, in 10 Mbps Ethernet. > > > > > > 177,000 divided by 100 million bits per second is 1.77 meters for 100 Mbps > > > Ethernet. (I'm sure you figured that one out already.) > > > >Some people questioned "the math" above, I'm guessing because it seems > >to read that a bit travels 17.7 meters/sec in 10 Mb Ethernet. But > >we missed the "physics" issues to keep things equivalent. > > No fuzzy math or physics is needed. We are dividing meters per second by > bits per second, which is the same thing as meters/sec x sec/bit. Cancel > out the seconds and you have meters per bit, in other words how much space > on a cable a bit occupies. > You bring back some fond memories -- I was privileged to hear retired Rear Admiral Grace Hopper speak on two occasions, during her later years when DEC was so savvy as to hire her as a consultant. One of her talents was the ability to make computing and communications seem real to others. During her days as a DEC spokesperson, she was known to hand out physical "bits". In the first talk I attended, she handed each of us short pieces of wire which she explained were "nanoseconds". In the next talk, she gave us plastic-wrapped packets of what appeared to be salt and pepper -- picoseconds, she exclaimed. Somewhere in my physical archives I still have both of these, and do treasure them, to the puzzlement of others... http://www.cs.yale.edu/homes/tap/Files/hopper-story.html > I was just sitting out on my deck on the last sunny day we will probably > have for months in Oregon and realized that folks may be missing the basic > arithmetic involved, though they understand the more complicated aspects. > That's weird! > Ahh, in a few months, we'll all be jealous of the great snow conditions. Then we can calculate the length of a bit on the cable of a chair lift! :-) Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 410-280-8840 x3006 275 West Street, Plaza 70WWW: http://www.mentortech.com Annapolis, MD 21401 Cisco CCIE #1289 **NOTE: New CCNA/CCDA List has been formed. For more information go to http://www.groupstudy.com/list/Associates.html _ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
