Re: Problems getting Cisco router and Motorola Nextlevel system to work together
We should probably move this over to cisco-nsp. I'd be interested to see a 'sh buffers' because if it's process switching that much data I bet the buffers are thrashing. I seem to remember working on something very similar to that 4 or 5 years ago when a customer has brigding over a bunch of ATM PVC's and they told me it was some type of IPTV set top box. We tuned the buffers really high so they didn't trim back and it worked. We also do some bridging under interrupt without process switching too last time I checked so some more data would be helpful. Move it over to [EMAIL PROTECTED] and we can help more on the Cisco side if you want. Rodney On Tue, Jul 24, 2007 at 09:25:49PM +0100, [EMAIL PROTECTED] wrote: > > > The router is currently configured to use IRB which is a > > hybrid process. > > The problems is that the IRB process is overloaded and is > > dropping traffic faster than it can process it. > > Which NPE is in this router? > > Basically, the 7200 has underpowered CPUs and if you force it to process > switch, then it handles a LOT LESS packets per second than you might > think. I expect that your config is forcing process switching rather > than fast switching. > > The only three solutions are > > A) run less traffic through the 7200 so that process switching can cope > > B) stop using the feature that forces process switching > > C) replace the 7200 with a 7300 which will probably not have CPU issues. > However, not knowing the specifics of what IRB is doing, I would advise > you to test a replacement platform before committing to it. > > Oh well, maybe 4 solutions. If you are using a weak NPE such as NPE-200 > you may be able to get some joy by upgrading to a more powerful one. For > instance an NPE-400 should handle roughly twice the load of an NPE-200. > > --Michael Dillon
Re: Router / Protocol Problem
Then that proves it's not a local router problem then. :) On Wed, Sep 06, 2006 at 07:49:26PM +, Christopher L. Morrow wrote: > On Wed, 6 Sep 2006, Rodney Dunn wrote: > > > > > Get a sniffer trace. Packets on the wire prove what's going on. > > provided the packets get back to him, it seems his problem is traffic > getting back to him :( so probably no packets will be on the wire (none in > question atleast)...
Re: Router / Protocol Problem
Get a sniffer trace. Packets on the wire prove what's going on. Without that kind of real data everything is just speculation. Rodney On Wed, Sep 06, 2006 at 12:16:01PM -0400, Mike Walter wrote: > > Sorry, I am running iBGP. I just swapped out the NPE225 engine to a > NPE400 and 512MB and have not seen a change yet. I am still unable to > reach the sites. I am going to give it a while and sometime soon reboot > the other router. I removed the single /24 today out the one connection > to see if that would change anything as well. > Mike > > -Original Message- > From: Hank Nussbacher [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 06, 2006 12:07 PM > To: Mike Walter > Cc: Justin M. Streiner; nanog@merit.edu > Subject: RE: Router / Protocol Problem > > On Wed, 6 Sep 2006, Mike Walter wrote: > > > > > Thanks for everyone's great input. Here are answers to Justin's > > questions. > > > > #1 - 12.3.6a - 7204VXR (NPE400) 512MB - 200+ MB free > > #2 - 12.2.15T5 - cisco 7204VXR (NPE225) - 256MB (I have a NPE400 - > 512MB > > I want to swap in) - 23MB Free (Issue?) > > > > Full Routes from all peers. No internal routing protocol as of yet, > all > > static routes. Getting ready to implement OSPF. I have not rebooted > > the routers as a test. I have CEF on both routers. I have had some > > customers complaining about slowness. > > No internal routing protocol? Not even iBGP? How do the 2 routers > exchange info? How do the internal systems know which router to exit > from? Or are they both independent? > > I assume you are AS26241 and peer with 3356, 4323 and 6181. > > I also assume you should be announcing your 2 prefixes: > 69.4.64.0/20 > 216.68.104.0/21 > > but you have deaggregated a single /24 - 69.4.71.0/24 which has sent > 34 BGP updates in the past 24 hours (which might be ok). > > So, it is a bit hard to debug this with only partial info. > > Regards, > Hank Nussbacher > http://www.interall.co.il
Re: Cisco ACL question
There isn't a quick and easy answer but a more complex solution could be to use EEM w/ a TCL policy to monitor when/if the ip address changes and if it does reconfigure the ACL. ie: policy A every 10 seconds do 'sh int serial 0/2/0' did ip address change? no -> exit yes -> run policy B to reconfigure the ACL. Ask it over on cisco-nsp if you want to try it out. Rodney On Wed, May 31, 2006 at 04:02:49PM -0400, Jon R. Kibler wrote: > Greetings All, > > Sorry for the slightly off-topic question, but I suspect that this is an > issue that others > have faced or may soon face as ISP continue to push out more PPP-oriented > networks. > > One of our customer's ISP is converting from static IP assignments to PPP IP > assignments for > > all customers' Internet facing routers. This is creating a security problem > that I do not > > know how to fix and for which the ISP is no help. Problem: how to ACL on a > dynamic IP? > > Assume that we have the following (partial) configuration on a Cisco 2801 and > are assigned > the static netblock 1.2.3.0/29. This was what worked before the ISP made the > change. > > ! Old config example > interface serial0/2/0 > ip address 1.2.3.1 255.255.255.248 > ip nat outside > ip access-group 110 in > ... > > interface fastethernet0/0 > ip address 172.17.100.254 255.255.255.0 > ip nat inside > ... > > ip nat pool localstatic 1.2.3.2 1.2.3.2 prefix 29 > ip nat inside source list 1 pool localstatic overload > ip nat inside source static tcp 172.17.100.22 22 1.2.3.5 12322 > ip nat inside source static ... > > access-list 1 permit 172.17.100.0 0.0.0.255 > access-list 1 deny any log > > access-list 110 permit tcp any 1.2.3.0 0.0.0.7 established > access-list 110 permit tcp host a.b.c.d host 1.2.3.5 eq 12322 > access-list 110 deny tcp any any log > access-list 110 permit udp host d.n.s.1 eq 53 host 1.2.3.2 > access-list 110 permit udp host d.n.s.1 host 1.2.3.2 eq 53 > access-list 110 permit udp host n.t.p.1 eq 123 1.2.3.2 > access-list 110 deny udp any any log > access-list 110 permit icmp any host 1.2.3.2 echo-reply > access-list 110 permit icmp any host 1.2.3.2 unreachable > access-list 110 permit icmp any host 1.2.3.2 time-exceeded > access-list 110 deny icmp any any log > access-list 110 deny ip any any log > > > In the new configuration, the serial0/2/0 interface now has a dynamic IP. How > can I put > ACLs on that IP that will permit NTP, DNS, and ICMP originating from within > the router > to work? Everything behind the router works, but anything generated by the > router itself > breaks (because the external IP is not permitted in an ACL). > > In the new configuration, this is the only change I made (other than PPP > stuff): > > ! New config example > interface serial0/2/0 > ip address negotiated > ip nat outside > ip access-group 110 in > ... > > > Everything from behind the router continues to work fine. However, the router > is unable to > do NS lookups, set time, etc. Basically, all traffic to the dynamic IP is > blocked. Is there > a SIMPLE way to fix this problem AND keep the router secured? > > I have searched the Cisco site, and Google, and cannot seem to find an answer > that I can > fully comprehend. I thought that maybe 'ip nat outside' was my fix, but I > could not get it > to do what I expected. > > Thanks in advance for your help! > > Jon Kibler > -- > Jon R. Kibler > Chief Technical Officer > A.S.E.T., Inc. > Charleston, SC USA > (843) 849-8214 > > > > > == > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. >
Re: MLPPP over MPLS
For more specific discussion we can move it over to cisco-nsp but here is a general document on it. http://cco/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801f26c8.html#wp1045653 Rodney On Tue, Feb 21, 2006 at 02:00:01PM -0600, Hyunseog Ryu wrote: > > Overall, MLPPP may work fine with MPLS as long as you have single > virtual circuit from each physical circuit. > Such as T1 channel from Channelized DS3... > But you have to use sub-interface (logical interface) other than > sub-channel from channeliezed circuit, > you may have some problem. > If you want to use QoS with MLPPP, some cases you may have to disable > CEF because of side effects. > > Overall, what I was recommended by Cisco source, is, if possible, to use > MLFR instead of MLPPP for MPLS integration. > > If you need more information, you can contact your local Cisco System > Engineer, and he/she will give more information to you. > > Hyun > > > Bill Stewart wrote: > > I've also heard a variety of comments about difficulties in getting > > Cisco MLPPP working in MPLS environments, mostly in the past year when > > our product development people weren't buried in more serious problems > > (:--) I've got the vague impression that it was more buggy for N>2 > > than N=2. There are a number of ways to bond NxT1 together, including > > MLFR and IMA, and we've generally used IMA for ATM and MPLS services > > and CEF for Internet. IMA has the annoyance of extra ATM overhead, > > but doesn't have problems with load-balancing or out-of-order > > delivery, and we've used it long enough to be good at dealing with its > > other problems. > > > > > > > > > >
Re: NAT Configuration for Dual WAN Router
On Thu, Dec 15, 2005 at 08:33:55AM -0600, eric wrote: > > [ This is not a plug for a vendor, just operational experience ] > > On Thu, 2005-12-15 at 10:49:51 +0100, Peter Dambier proclaimed... > > > I dont see how the router can NAT to more than one ip-address. So you need > > one NAT-router per DSL-line. > > I have some experience with the Xincom Twin WAN router. Basically, all it > does is NAT RFC1918 address space (by default) and load balance stateless > TCP traffic (ie. web traffic) over two outbound links. Established TCP > sessions will not fail over, unfortunately, but the device is fairly > reliable and does NAT-T fairly easy. Interesting in that I was talking with a customer about something similar to that today. How can you do nat and failover but keep the existing TCP sessions alive. Given the two upstreams were doing uRPF we couldn't come up with a solution. Rodney > > Sure, there's cheaper ways to do this solution without paying for a > blackbox, but there's no moving parts in the device and thus is good for > small offices that have no clue built-in. > > - Eric
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
I will check on this and get back with you. Rodney On Thu, Jan 20, 2005 at 11:18:10AM -0500, Joe Maimon wrote: > > > > David Barak wrote: > > >--- Suresh Ramasubramanian <[EMAIL PROTECTED]> > >wrote: > > > > > > > >>David Barak <[EMAIL PROTECTED]> wrote: > >> > >> > >>>While it says that bogon filters change, and > >>> > >>> > >>provides > >> > >> > >>>a URL to check it, what percentage of folks who > >>> > >>> > >>would > >> > >> > >>>use a feature like "autosecure" would ever update > >>>their filters? > >>> > >>> > >>> > >>What do they do to update that bogon list anyway - > >>push a new IOS image? > >> > >> > >> > > > >That's a mighty fine question: the link I referenced > >is the most recent I was able to find, and its list of > >bogons is thoroughly out-of-date. In the interest of > >long-term reachability, I would call on Cisco to > >remove the IANA-UNASSIGNED blocks from the autosecure > >filters. > > > > > > > > > I think the last time this was hashed out here, there was a consensus > that Cisco should not be promoting a feature that uses a static list for > blackholing. The problem is with now-good-bogons bad enough as it is, > even with a presumably competent admin responsible for the setup. > > Perhaps Cisco could couple this with a scheduled scp to a server of > choice, preferably Cisco's, for an update checking feature. At that > point I would think perhaps it has a bit more + than - to it. > > At any rate it should NOT be tied to IOS images, the vast majority of > those never get upgraded. Make ACLS be able to parse their rules from a > file stored wherever. Just like that new DHCP static bindings from text > file feature. > > Joe
Re: Cisco 7513 & Bandwidth Points
Noel, Tom, There are limitations on the 75xx's depending on the RSP/VIP setup you have. It's a distributed platform that does software based forwarding when running in dCEF mode. All packet are switched by the VIPs and never touch the RP. Therefore the switching capacity is a function of the speed of the VIPs and the features you have enabled in the packet path (ACL's, QOS, etc..). The short answer is there isn't a bandwidth concept like there is with the 72xx. However, you can overload the VIP with the right PA combination and features. The matrix of performance will depend on the features, ppps, and VIP type. There have been extensive discussions about this on cisco-nsp so if there are further questions I'd suggest we move it over there and I can add more. Thanks, Rodney On Thu, Jan 13, 2005 at 09:09:28PM -0500, Noel Montales wrote: > > On-List replies perhaps may be usefull.. Or could you post a summary of > your findings? > > Regards, > Noel Montales > > Claydon, Tom said: > > > > Hello, > > > > We are moving from a Cisco 7206 to a 7513, and I was wondering if we > > will be limited by bandwidth points on the 7513 (as we are with the > > 7206). From the sparse documentation I've found so far, it doesn't > > appear that this limitation exists in the 7513, correct? > > > > Off-list replies are welcomed. > >
Re: Cisco 2611XM as cheap border router
This will not work for full routes. The memory upgrade is utilized for larger IOS images with new features. An update to the product bulletin is in the works to clarify it. Further specific questions in regards to the memory can be moved over to the cisco-nsp alias. Rodney On Tue, Jan 11, 2005 at 07:39:49AM +0200, Mark Bojara wrote: > Hello people of nanog :) > > Ive been doing some reading up and I see that that 2600 series is now > supporting 256MB of memory. Do you guys think this router could handle > 3/4 peers a QoS setup (RSVP or something)? > > http://www.cisco.com/en/US/products/hw/routers/ps259/products_qanda_item0900aecd800f71dd.shtml > > Regards > Mark >
Re: [Insight?] OutPut Drops Cisco 7206VXR
It's a vendor specific troublehsooting question so let's move it over to the cisco-nsp alias. http://puck.nether.net/cisco-nsp/ The drops can be as others have said for various reasons (QOS, bursty traffic, etc...). The bus error is most likely software although it could be hardware. Yours does look like a software problem. Send the relevant interface configurations, sh stack, show region, and show version to the cisco-nsp alias. Rodney On Tue, Oct 26, 2004 at 10:49:22AM -0400, Gyorfy, Shawn wrote: > > Yeah - we have traffic shaping: > > policy-map Outbound-Transmission-To-Core (We have 10) > class Expedited-Forwarding-To-Core >priority percent 50 > class Hanover_13364_14025_37272-TS-To-Core >shape average 1536000 192000 15000 > class Queller_3266_3268_30989-TS-To-Core >shape average 70 87500 15000 > . > . > . > (10) > > FastEthernet0/0 is up, line protocol is up > Hardware is DEC21140A, address is 0001.636e.1c00 (bia 0001.636e.1c00) > Description: Connected to Extreme Summit48 > Internet address is > MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, > reliability 255/255, txload 12/255, rxload 3/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 100Mb/s, 100BaseTX/FX > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:21, output 00:00:00, output hang never > Last clearing of "show interface" counters 00:37:12 > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 5397 > Queueing strategy: weighted fair > Output queue: 0/1000/64/0 (size/max total/threshold/drops) > Conversations 0/82/256 (active/max active/max total) > Reserved Conversations 0/0 (allocated/max allocated) > Available Bandwidth 25000 kilobits/sec > 5 minute input rate 1505000 bits/sec, 979 packets/sec > 5 minute output rate 5084000 bits/sec, 1590 packets/sec > 2028319 packets input, 434456929 bytes > Received 3 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 watchdog > 0 input packets with dribble condition detected > 3453733 packets output, 1359654191 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier > 0 output buffer failures, 0 output buffers swapped out > > > Serial2/0 is up, line protocol is up > Hardware is M1T-T3+ pa > Description: ny-0200 V#51HFGL605916 (DS3 to 39 Broadway POP) > Internet address is > MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec, > reliability 255/255, txload 8/255, rxload 29/255 > Encapsulation PPP, LCP Open > Open: CDPCP, IPCP, crc 16, loopback not set > Keepalive set (10 sec) > Restart-Delay is 0 secs > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters 00:37:49 > Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: weighted fair > Output queue: 0/1000/64/0 (size/max total/threshold/drops) > Conversations 0/10/256 (active/max active/max total) > Reserved Conversations 0/0 (allocated/max allocated) > Available Bandwidth 11052 kilobits/sec > 5 minute input rate 5029000 bits/sec, 1584 packets/sec > 5 minute output rate 1437000 bits/sec, 966 packets/sec > 3460149 packets input, 1351120603 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 parity > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 2005303 packets output, 418156501 bytes, 0 underruns > 0 output errors, 0 applique, 0 interface resets > 0 output buffer failures, 0 output buffers swapped out > 0 carrier transitions >rxLOS inactive, rxLOF inactive, rxAIS inactive >txAIS inactive, rxRAI inactive, txRAI inactive > > > > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 26, 2004 10:55 AM > To: Gyorfy, Shawn > Subject: Re: [Insight?] OutPut Drops Cisco 7206VXR > > Do you have any rate limiting on the Ethernet interface? > > The bus error.. I would say let cisco just replace your gear... that > dosen't sound good. How is the bandwidth usage soo different? That > dosen't sound right > > > -Justin > On Tue, 26 Oct 2004, Gyorfy, Shawn wrote: > > > > > What's up all, > > > > I have a question, maybe some have experienced this before- let me paint > the > > picture for you first - We are running VoIP- customer's are experiencing > > static. > > > > I have a DS3 going for a Cisco 10k router to a Cisco 7206VXR M2T-T3+ pa > > Interface. As of right now, the current usage is about 5.5Mbps with an > > input rate of about 1425pps and output rate of 756. > > > > The Fast Ethernet is connected to an Extreme Switch. The FastE's usage > > right now is about 20Mbps with an input rate of 868pps and an output of > > 1541pps. > > > > O
Re: Cisco etherchannel question
Let's move this to the cisco-nsp alias since it's a vendor specific question. http://puck.nether.net/cisco-nsp/ Thanks, Rodney On Wed, Oct 20, 2004 at 07:27:33AM -0700, william(at)elan.net wrote: > > > Hi, > > I have etherchannel setup between cisco 7500 router and 5500 switch. > > For data going from 7500 router everything seems to be ok and data is > well split between four interfaces with about 1/4th sent to each one > (about 40% utilization each right now). > > But for data going from 5500 switch the split appears to be that one > interface has 100% utilization while another one is 20% and others are > less then 10%. So its not really splitting data on random basis to > each interface and uses other interfaces as overflow after the main > one. I don't like this as the one interface that is 100% full appears > to sometimes be dropping packets on either switch or cisco router side. > > I'm wondering what I can do to force 5500 to use etherchannel in similar > way cisco 7500 does? > > -- > William Leibzon > Elan Networks > [EMAIL PROTECTED]
Re: Load Balancing Multiple DS3s (outgoing) on a 7500
Drew, Something that was just released that you might be interested in if you haven't already found an alternate solution. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a0080221544.html It's a new feature in 12.3(8)T. Rodney On Fri, Mar 12, 2004 at 10:39:16PM -0500, Drew Weaver wrote: > Does anyone know of an article, or documentation regarding load > balancing the traffic on 3 or more FastEthernet interfaces on the outgoing > direction? Right now we're running BGP internally, and the routes that are > being chosen based upon the final BGP decision step or what I like to call > the 'IP address tie breaker' which is not always optimal. We have a cisco > 7500 that is connected to 4 other Cisco 7500s which each have 45Mbps ds3s to > the Internet, we would like to load balance the outgoing traffic across all > 4 of these 7500s, can anyone shine any advice my way? I noticed that there > are instructions on Cisco's site regarding doing LB on 12000s. > > > > Anyways thanks in advance ;-) > > > > -Drew > > >
Re: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ?
In an effort to keep from getting too vendor specific on nanog I'll respond to you offline. My initial response to Alex was aimed at giving him something else to consider from a "gotcha" perspective along with his other requirements. Rodney On Mon, Apr 26, 2004 at 03:50:45PM -0400, [EMAIL PROTECTED] wrote: > On Mon, 26 Apr 2004, Rodney Dunn wrote: > > > That's the most common deployment mistake I > > see made with the 75xx nowadays. People want > > to move to dCEF to get added feature capability > > or either run a new feature that requires dCEF and they > > don't consider the extra load on the VIP CPU's that > > is required. > > Does dCEF use much more CPU on the VIPs or just memory (to store the > fowarwarding table on the VIP)? My experience has been that a 7500 with > RSP4's and VIP2-50's (with dCEF) will handle much more packet forwarding > than a 7206VXR NPE300...but with full BGP routes, you need at least 64mb > (preferably 128mb) on the VIPs or you can't use dCEF. Not using dCEF > largely defeats the purpose of using a 7500, doesn't it? > > -- > Jon Lewis [EMAIL PROTECTED]| I route > Senior Network Engineer | therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ?
Just be sure you have the VIP's that can handle any features you need or you plan to run with dCEF off and let the RSP do the work. And that's true as long as you are not running features on that platform that require dCEF. That's the most common deployment mistake I see made with the 75xx nowadays. People want to move to dCEF to get added feature capability or either run a new feature that requires dCEF and they don't consider the extra load on the VIP CPU's that is required. There is no hardware assisted forwaring on a 75xx so it's pure software and CPU speed to do features. Rodney On Mon, Apr 26, 2004 at 02:11:04PM -0400, [EMAIL PROTECTED] wrote: > > On Mon, 26 Apr 2004, Michel Py wrote: > > > > > > "Alexander Hagen" > > > What about a 7505 w/ RSP4/256 and 2 VIP 2-50/128s with 4 PA-FE-TXs. > > > > I would get a 7507 w/redundant RSPs and redundant PS. > > You'd get a 7507 (only if it were a choice between that or a 7505?), but > then at the end of your message, you say you wouldn't buy any 7500? > > > >> What is better about the 7206 VXR ? > > > Fewer software bugs, > > > > Not in my experience. > > A couple 'advantages' to the 7206 are much smaller size & mass. The 7206 > is single person portable. The 7507 and 7513 are very much larger and > much more massive. You'll never see someone running down the street away > from your data center with a 7507 under their arm. > > > The part I missed earlier is that I think Alexander needs to buy the > > platform. As of today I can not recommend buying any 7500 as even the > > 7507 and the 7513 are going to EOL sooner or later. If you can't afford > > a 7603, then the 7206VXR with NPE400G and a gigabit trunk to a 3550 is > > what I would do. > > A basic 7507 (dual PS, dual RSP4, couple of VIPs and PAs) is so cheap > today, if he's strapped for cash, that's what I'd go for. I'm guessing > you can still get at least several years out of such a box, and by the > time you've outgrown it or cisco stops making IOS for it (they still make > IOS for AS5200's!), hopefully you'll have the cashflow to upgrade. > > -- > Jon Lewis [EMAIL PROTECTED]| I route > Senior Network Engineer | therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: MLPPP Problem with Cisco 7513
Richard, One bug I know of that could possibly be a match is: CSCec00268 Externally found severe defect: Resolved (R) Input drops and * throttles on PPP multilink interface fixed in 12.2(15)T9. The way to verify is to check 'sh int multilink ' and see if the interface is under throttle. Router#sh int mu 2 Multilink2 is up, line protocol is up Received 0 broadcasts, 0 runts, 0 giants, 0* throttles ^-- Here. If that's not it email me offline and I'll help you get it resolved. Thanks, Rodney On Tue, Jan 06, 2004 at 05:30:51PM -0800, Richard J. Sears wrote: > > I am hoping someone can shed some light on an interesting problem we are > having - > > When we set up a customer for MLPPP, things tend to go well for a period > of time. Then - all of a sudden - we will begin to have problems with > our multilink bundles (generally only one at a time) and the only fix is > to reload our 7513. This problem happens on both of our 7513 routers > from time-to-time. Once we reload - the problem will stay gone for as > long as several months, or in the last case only about 12 hours. > > Once we see the problem, it is apparent only in one direction. For > example the customer can push the full capacity of their circuits to us, > but they cannot pull anything above about 300k back to them on a two-T1 > bundle. This is the same every single time we have the problem. > > We have changed multilink bundles, tried different types of switching > and route caching, turning on and off fragmentation - the only thing > that solves the problem is reloading the entire router. We can pull the > T1s from the multilink bundle and each individual T1 works great. No > line errors, no crc errors - nothing. No errors are apparent while in > MLPPP mode either. No throttles or anything similar. > > We have had this problem in the past and it was recommended that we > upgrade the code on our 7513s. We are currently running version > 12.2(13)T5 on both our 7513 as well as the customers router. Upgrading > the code did not solve the problem. I have been unable to locate a Cisco > bug defining this type of problem for any version of their code. > > This particular customer's T1s are both terminated on the same VIP (we > are running DMLP) but are terminated on separate PAs and hence separate > CT3s. We have noticed the problem even with T1 bundles on the exact same > PA and CT3. We are not doing multi-chassis DMLP. dCEF is enable on both > routers, however the problem remains the same even after disable dCEF. > > Here are configs and router info: > > interface Multilink6 > description Eastgate Mall (s2/1/0/8:0 and s2/0/0/12:0) [20291] > ip address 207.158.1.133 255.255.255.252 > no cdp enable > ppp multilink > ppp multilink interleave > multilink-group 6 > > interface Serial2/0/0/12:0 > description Eastgate Mall #2 > no ip address > encapsulation ppp > no fair-queue > ppp multilink > multilink-group 6 > > interface Serial2/1/0/8:0 > description Eastgate Mall #1 > no ip address > encapsulation ppp > no fair-queue > ppp multilink > multilink-group 6 > > > AR04#sh diag 2 > Slot 2: > Physical slot 2, ~physical slot 0xD, logical slot 2, CBus 0 > Microcode Status 0x4 > Master Enable, LED, WCS Loaded > Board is analyzed > Pending I/O Status: None > EEPROM format version 1 > VIP2 R5K controller, HW rev 2.02, board revision D0 > Serial number: 17953368 Part number: 73-2167-05 > Test history: 0x00RMA number: 00-00-00 > Flags: cisco 7000 board; 7500 compatible > > EEPROM contents (hex): > 0x20: 01 1E 02 02 01 11 F2 58 49 08 77 05 00 00 00 00 > 0x30: 68 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 > > Slot database information: > Flags: 0x4 Insertion time: 0x41C8 (1d08h ago) > > Controller Memory Size: 32 MBytes DRAM, 4096 KBytes SRAM > > PA Bay 0 Information: > CT3 single wide PA, 1 port > EEPROM format version 1 > HW rev 1.00, Board revision A0 > Serial number: 17814822 Part number: 73-3037-01 > > PA Bay 1 Information: > CT3 single wide PA, 1 port > EEPROM format version 1 > HW rev 1.00, Board revision A0 > Serial number: 09725065 Part number: 73-3037-01 > > --Boot log begin-- > > Cisco Internetwork Operating System Software > IOS (tm) VIP Software (SVIP-DW-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) > TAC Support: http://www.cisco.com/tac > Copyright (c) 1986-2003 by cisco Systems, Inc. > Compiled Wed 28-May-03 21:57 by nmasa > Image text-base: 0x60010930, data-base: 0x604C > > > > AR04#sh ver > Cisco Internetwork Operating System Software > IOS (tm) RSP Software (RSP-JSV-M), Version 12.2(13)T5, RELEASE SOFTWARE (fc1) > TAC Support: http://www.
Re: Cisco introduced 'warm' reload...
My mistake. I missed it took that as the "Reason for reload" option. Thanks Andrew for catching that. Rodney On Sun, Sep 14, 2003 at 06:54:28PM -0400, Rodney Dunn wrote: > On Sat, Sep 13, 2003 at 08:11:52PM -0700, Michel Py wrote: > > Rodney, > > > > > Rodney Dunn wrote: > > > Thanks for pointing that out. I'll have it removed > > > from the CLI for any platforms where it's not supported. > > > > Actually, there's nothing to remove. The > > > > > cisco7507#reload ? > > > LINEReason for reload > > > > Is perfectly legitimate. > > I agree. But it shouldn't accept the command even though > it's not visible. > > 75xx_Lab#sh ver | incl IOS > IOS (tm) RSP Software (RSP-JSV-M), Version 12.3(2)T, RELEASE SOFTWARE (fc1) > 75xx_Lab#rel warm > > System configuration has been modified. Save? [yes/no]: yes > Warning: Attempting to overwrite an NVRAM configuration previously written > by a different version of the system image. > Overwrite the previous NVRAM configuration?[confirm]n > No action taken because command was not confirmed > Proceed with reload? [confirm]n > > > > > > > > > The currently supported platforms are: > > > 3660 and 3745 in 12.3(2)T > > > 7200 in 12.2(18)S > > > I'll also check on future platform implementations and > > > let you know. While at first the feature seems platform > > > independent it turns out there are some platform > > > dependencies. > > > > If I may, it would be a hell of a good idea to make it work on platforms > > such as the 7500 where one would think it is un-necessary. On paper, > > having a feature set with rpr/rpr+ would render this command > > un-necessary on a 7500 with dual RSPs. In practice, there are so many > > compatibility issues with rpr/rpr+ and other features that some 7500s > > that have dual RSPs run a non-rpr image and the second RSP is sitting in > > the router as a spare. > > Sure you may. I'll check with the 7500 group and let you know what the > plans are for this platform. > > Rodney > > > > > > Michel. > >
Re: Cisco introduced 'warm' reload...
On Sat, Sep 13, 2003 at 08:11:52PM -0700, Michel Py wrote: > Rodney, > > > Rodney Dunn wrote: > > Thanks for pointing that out. I'll have it removed > > from the CLI for any platforms where it's not supported. > > Actually, there's nothing to remove. The > > > cisco7507#reload ? > > LINEReason for reload > > Is perfectly legitimate. I agree. But it shouldn't accept the command even though it's not visible. 75xx_Lab#sh ver | incl IOS IOS (tm) RSP Software (RSP-JSV-M), Version 12.3(2)T, RELEASE SOFTWARE (fc1) 75xx_Lab#rel warm System configuration has been modified. Save? [yes/no]: yes Warning: Attempting to overwrite an NVRAM configuration previously written by a different version of the system image. Overwrite the previous NVRAM configuration?[confirm]n No action taken because command was not confirmed Proceed with reload? [confirm]n > > > > The currently supported platforms are: > > 3660 and 3745 in 12.3(2)T > > 7200 in 12.2(18)S > > I'll also check on future platform implementations and > > let you know. While at first the feature seems platform > > independent it turns out there are some platform > > dependencies. > > If I may, it would be a hell of a good idea to make it work on platforms > such as the 7500 where one would think it is un-necessary. On paper, > having a feature set with rpr/rpr+ would render this command > un-necessary on a 7500 with dual RSPs. In practice, there are so many > compatibility issues with rpr/rpr+ and other features that some 7500s > that have dual RSPs run a non-rpr image and the second RSP is sitting in > the router as a spare. Sure you may. I'll check with the 7500 group and let you know what the plans are for this platform. Rodney > > Michel. >
Re: Cisco introduced 'warm' reload...
Michel, Thanks for pointing that out. I'll have it removed from the CLI for any platforms where it's not supported. The currently supported platforms are: 3660 and 3745 in 12.3(2)T 7200 in 12.2(18)S I'll also check on future platform implementations and let you know. While at first the feature seems platform independent it turns out there are some platform dependencies. Thanks, Rodney On Sat, Sep 13, 2003 at 12:01:25PM -0700, Michel Py wrote: > > > Pascal Gloor wrote: > > Cisco inroduced 'warm' reload > > http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_ > > feature_guide09186a00801a755a.html > > 12.3(2)T This feature was introduced. > > 12.2(18)S This feature was integrated into Cisco IOS Release > 12.2(18)S. > > Did anyone test this yet? > > It's not available on all platforms, at least not on my test one. When > doing "reload warm" it does a cold one and takes "warm" as the reason > for reload. > > Michel. > > > cisco7507#sh ver > Cisco Internetwork Operating System Software > IOS (tm) RSP Software (RSP-JK9O3SV-M), Version 12.3(2)T, RELEASE > SOFTWARE > (fc1) Synched to technology version 12.3(1.9) > > cisco7507#warm? > % Unrecognized command > cisco7507#warm-reload > Translating "warm-reload"...domain server (192.168.222.4) > % Unknown command or computer name, or unable to find computer address > > cisco7507#reload ? > LINEReason for reload > at Reload at a specific time/date > cancel Cancel pending reload > in Reload after a time interval > >
Re: Cisco introduced 'warm' reload...
Pascal, Timo asked the same thing. I'm setting up a 3745 and a 3660 in the lab to test it on. In the Release notes there is a link to Feature Navigator (FN) that will display the platform support for a feature. http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp Currently that shows only 3745 and 3660 support. I'm not sure exactly why that is but I will check and let you know. Also, I'll try to get the Release Notes more clear about how to check for the hardware support especially when it appears to be a platform independent feature. Rodney On Sat, Sep 13, 2003 at 12:19:46PM +0200, Pascal Gloor wrote: > > Cisco inroduced 'warm' reload > > http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guid > e09186a00801a755a.html > > 12.3(2)T This feature was introduced. > 12.2(18)S This feature was integrated into Cisco IOS Release 12.2(18)S. > > > Did anyone test this yet? > > > Pascal
Re: cef/process switching problem
ACL's are done in the CEF path also as long as you don't have the "log" keyword on it that causes a punt. Check the 'sh int stat' from the ingress interfaces and see which ones are showing inbound process hits. Rodney On Tue, Sep 09, 2003 at 10:33:54AM -0500, Austad, Jay wrote: > > It's 12.2 code. show ip int e0 shows that CEF is enabled on the interface. > Supposedly 12.2's CEF also handles policy routing (which is not being used > on this router). > > > -Original Message- > > From: Jason Frisvold [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 09, 2003 10:24 AM > > To: Austad, Jay > > Cc: [EMAIL PROTECTED] > > Subject: Re: cef/process switching problem > > > > > > Not sure on the MC3810 (never used one), but I know that many of the > > other Cisco routers didn't do CEF on ethernet until later revisions of > > code... There are other factors that kick it out of CEF as well.. I > > believe ACL's and Route Maps are 2 of them.. > > > > On Tue, 2003-09-09 at 11:07, Austad, Jay wrote: > > > I've got a cisco MC3810 with a bunch of DSL customers on it. CEF is > > > enabled, but when I do a show int stat, I see that almost > > 100% of the > > > outbound packets on the ethernet interface are process > > switched, and not > > > being matched in the route cache. The Input looks just > > fine, and the other > > > interfaces are borderline (usually 50% hit rate on the > > cache or a little > > > less). > > > > > > CPU is sitting pretty high on this box during the day, and > > I have strong > > > suspicions that this is why. :) > > > > > > I can't seem to find any info on why this would be > > happening or how to > > > figure out what's going on. Anyone have any suggestions? > > > > > > -jay > > -- > > --- > > Jason H. Frisvold > > Backbone Engineering Supervisor > > Penteledata Engineering > > [EMAIL PROTECTED] > > RedHat Engineer - RHCE # 807302349405893 > > Cisco Certified - CCNA # CSCO10151622 > > MySQL Core Certified - ID# 205982910 > > --- > > "Imagination is more important than knowledge. > > Knowledge is limited. Imagination encircles > > the world." > > -- Albert Einstein [1879-1955] > >
Re: Load balancing in routers
On Mon, Apr 08, 2002 at 02:25:54PM -0400, Richard A Steenbergen wrote: > > On Mon, Apr 08, 2002 at 11:02:11AM -0700, Mark Kent wrote: > > > > >> > load balancing over multiple links uses a flow-hashed method. If you > > >> > want per-packet load distribution you have to specifically enable it by > > >> > saying "no ip route-cache" on each interface. > > >> > > >> That is very deadly, please, don't anyone actually try that. > > > > How so? So it uses a little more cpu, but that may not be relevant in > > a lot of applications (like down at the T1 level). > > Besides just driving up the CPU load through the roof for no real reason, > process switching produced per-packet load balancing. This is not a > desirable thing, since it introduces packet reordering which can be VERY > detrimental to TCP performance. Just think, if you had a slightly > different cable length, packets could spend more time on one wire than > another, and become totally out of sync. When you put a packet up to process level it has to wait until the IP INPUT process runs before being switched. This get's worse since with every packet you have to find a longest prefix match in the entire RT. It takes more time especially when another process is already running and you have other packets being switched under the rx interrupt where you do have some sort of fastswitching enabled (legacy fastswitchin or CEF) on other interfaces. This is explained in good depth in "Inside Cisco IOS Software Architecture" by Bollapragada, Murphy and White. Chapter 2 specifically. While process switching does introduce delay/jitter and reduced throughput because of out-of-order packets there is another problem with the old fastswitching model. Cache maintenace. Back when (sorry to bring it back up) NIMDA hit Cisco routers running traditional fastswitching were hit harder because the CPU was constantly doing cache invalidations. With CEF that is not an issue. The GSR is a completely dCEF for normal IP forwarding. There is no fallback path like there is on the other routers. If a packet comes in and due to a feature configuration it can't be CEF/dCEF switched it does a fallback to the traditional fastswitching routines to try and switch the packet. The first packet would be punted to process level (which is another drawback of the traditional fastswitching approach) where the cache would be build so the next packet to that destination could be switched without being sent to process level. > Input flow >1 >2 >3 >4 >5 > Link 16Link 2 >1 2 >3 4 >5 6 >2 >1 >3 >4 >6 >5 > Output flow > > > > I've had a customer on the end of 8 T1, no ip route cache, on a 4700 > > (their end) and a 7206/300 (my end). 4700 runs a little hot, but survives. > > > > Similarly, I currently have a couple of 4*T1, a 3*T1, and several 2*T1 > > on PA-MC-T3 ports on a 7206/300 with no issues whatsoever. Max cpu > > usage is 35%. Everything works. > > If all you want to do is a few T1's on an NPE300, you'll be fine. I'm > certain Alex is used to doing more and scraping every last packet out of > his routers. :) > > > Now, contrast that with my first use of cef, this was back when the > > only cef configuration was "ip cef" or something similar. Very > > difficult to screw things up when the config is a one-liner, and yet > > when I turned this on the 7206 immediately crashed. > > It's really not much more complex now. I saw some "CEF Watchdog" (to check > for dCEF corruption) type functionality in recent 12.0S builds, but on a > 7200 it doesn't matter since is distributed. What you are referring to is the CEF Inconsistency Checker. http://www.cisco.com/warp/public/105/cefincon.html I scans the RT on the RSP/GRP and then compares to what is on the LC's to catch situations where they get out of sync. If and when it does happen it's a bug no matter what triggered it. > > As for your crash... Well, my first guess is that you were running the > "wrong" IOS image. 7200's are simple enough that they are usually safe to > run whatever the "newest" code on. That practice that will get you burned > on GSR's. But in the end... It's Cisco, what do you expect. Call TAC or > try again with new code. :) CEF is on by default on the 72xx after 12.2(6), 12.1(12), and 12.1(10)E via: CSCdu81146 hth, rodney > -- > Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras > PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
