|
NinjaPablo posted:Can anyone point me in the direction or explain how IOS version numbers work? For your example of 12.1(3r)T2: 12.1- Major release. (3r)- 3rd maintenance release, r'th rebuild (starts at a) T- Consolidated Technology release train (there are typically several trains of IOS available depending on platform, where you get different features, S trains (service providers) have different features than say an E train which is enterprise feature set). 2- Release rebuild counter, in this case this is the second rebuild of 12.1(3r)T -edit- found a better one http://www.cisco.com/warp/customer/620/1.html -/edit- ragzilla fucked around with this message at 22:06 on Apr 16, 2007 |
#
¿
Apr 16, 2007 22:01
|
|
|
|
| # ¿ Apr 19, 2024 00:57 |
|
|
sirchode posted:Catalyst question: Is there a way to get a list of all VLANs showing me which switch is acting as spantree root for each one? I've got hundreds of VLANs so going through each one individually isn't very desirable and I'd like to be able to see at a glance which ones need to be fixed # show spanning-tree detail | inc (is executing the|Current root|We are) gets the mac address of the root bridge, up to you to map mac addr->switch (tested on 3750, might need some changes for other platforms).
|
|
#
¿
Apr 17, 2007 16:56
|
|
|
sirchode posted:Edit: misunderstood you sh spanning-tree is only going to work on catalyst platforms like the 5500. I've never done IRB in routing platforms but there may be some spanning tree info on the 7500s in show bridging / show irb
|
|
#
¿
Apr 18, 2007 03:04
|
|
|
Mr. Fossey posted:I am trying to setup NetFlow on a 1700 running Version 12.3(13). I am going from Serial0 nat'd to FE0. I have the communication working except that I am not translating incoming communication from the internet to internal IPs. I'm not sure you can do this as the flow records are generated on packet ingress- before translation. If you want proper flows you may want to look at tapping/span'ing your internal FastEth port to a netflow probe and export flows from that.
|
|
#
¿
Apr 19, 2007 15:19
|
|
|
jwh posted:Here's an interesting workaround I dug up: http://www.netup.biz/articles.php?n=10 Probably want to keep on eye on the CPU if you tried that, Cisco states in their 'nat on a stick' docs that nat+pbr may result in packets getting punted to the process switching path.
|
|
#
¿
Apr 19, 2007 18:24
|
|
|
Funnylink posted:I have a cisco 800 series router i recently bought 5 months ago. I am having trouble with interference with my wireless security camera creating interference on the wireless channel. I am having problems finding out how to change the wireless channel by googling. How do I configure the dot11radio interface to change the wireless frequency? code:code:
|
|
#
¿
Apr 19, 2007 18:34
|
|
|
fsck posted:I have a pair of Cisco Catalyst 6506 routers that are to terminate both sides of a private-line OC3. I know IOS but CatOS and the relationship between the OC3 FlexWAN module and the supervisor engines is really making me tear my hair out. The FlexWAN isn't a switchport- it's intended to be used as a WAN connection. It's typical use (as a POS interface) you'd just set up IPs on either side and use it as a routed (not switchport) interface. If you need to do VLANs over it you're probably going to have to look at running MPLS/L2VPN/EoMPLS over it. inignot posted:Use 10.whatever on all your interfaces, then enable eigrp per below. jwh posted:I'm wondering if anybody has any advice for DMVPN tunnel monitoring. Because the mGRE tunnels don't ever go down/down (unless the associated physical interface goes down), it's not very practical to simply watch the tunnel interface itself.
|
|
#
¿
Apr 24, 2007 01:56
|
|
|
fsck posted:Actually I don't need to do VLAN trunking, specifically. All I really need to do is use the OC3 to connect one side of the network to the other - they are on different octet class-C subnets (i.e. 10.10.10.0 and 10.10.11.0 for sake of example). The hybrid mode of the current switch config is probably what is so heinously confusing to me. Not seeing you on AIM (my contact info is in profile). In any case, the quick version + disclaimer since I've never worked on the 6500 platform- most of my experience is with routers (7200/12k). Your configuration will probably be done on the MSFC rather than the sup (since you mentioned CatOS I'm guessing you're running in hybrid mode). Once connected to the MSFC you should be able to assign addresses to the POS interfaces (conf t, int pos 5/0/0, ip addr 10.10.255.1 255.255.255.252 (on one side) ip addr 10.10.255.2 255.255.255.252 (on the other), and then ping between them. Then it's just a matter of setting up static routes or a a routing protocol like OSPF.
|
|
#
¿
Apr 24, 2007 02:25
|
|
|
sirchode posted:Thank you, that is indeed pretty awesome. We've got some offices on the other side of the country and I'm imagining having them set up as VLANs managed by our switches and routers over here in the CO, it's a very cool prospect. 12.0(23)S apparently. Pretty recent still. From what I understand it's mostly intended in an MPLS backbone but they also added support for 'regular' IP backbones (much like VRF-lite).
|
|
#
¿
Apr 28, 2007 04:02
|
|
|
adante posted:probably not the right place to ask but what the hey The 'kill all connections' is controlled by the VPN server, you'd have to have the person that configures the VPN concentrator/firewall enable split tunneling and then it would only route traffic intended for the remote network over the VPN tunnel.
|
|
#
¿
Apr 28, 2007 15:26
|
|
|
Wicaeed posted:Ok this is a dumb one, but where can I find the steps I need to go through with the CLI to install a new version of ios for my 871 router? The Cisco website sucks pretty bad and all I can find are tech docs on how to restart the router. http://www.cisco.com/en/US/products/hw/routers/ps380/products_tech_note09186a0080094b23.shtml http://www.cisco.com/en/US/products/hw/routers/ps380/tsd_products_support_series_home.html (800 series support home, the upgrade instructions are under install and upgrade technotes)
|
|
#
¿
May 1, 2007 04:36
|
|
|
InferiorWang posted:
Yes. Cisco devices typically talk across links using a protocol known as CDP (Cisco Discovery Protocol) to tell each other their hostnames / ip addresses / settings they're using on the link. In this case, the switch you are looking it has it's Gi0/1 port set to half-duplex, but the switch on the other side of the link is reporting in it's CDP packets that it has the link set for full-duplex. Check your int Gi0/1 configuration, and remove any commands like half-duplex or switchport nonegotiate.
|
|
#
¿
May 10, 2007 16:14
|
|
|
ionn posted:That's what happens if you connect cisco equipment to cisco equipment. Fixed. I still can't believe how horribly unreliable autonegotiation Cisco-to-Cisco is. It's crazy that in this day and age we still have to go through and manually force speed/duplex on ports to stop Cisco gear from doing something stupid. vvv You've probably never had the fun of using a 7200 with an IO-FE or PA-FE-TX, they're both absolutely terrible at autonego, I didn't even bother letting them autonego after the first one I had to turn up. ragzilla fucked around with this message at 19:36 on May 10, 2007 |
|
#
¿
May 10, 2007 19:22
|
|
|
jwh posted:Isn't autonegotiation required for 1000base-t? I know you can force it off on fiber interfaces, but I don't think I can turn down autonegotiation on my X6548-GE-TX modules. GBIC/SFP based ports can only take 1000/full afaik, fixed modules may vary by platform.
|
|
#
¿
May 11, 2007 03:03
|
|
|
Girdle Wax posted:GBIC/SFP based ports can only take 1000/full afaik, fixed modules may vary by platform. Correcting myself here, GLC-T SFP modules are capable of 10/100/1000 on certain platforms, listed at http://www.cisco.com/en/US/products/hw/modules/ps5455/products_device_support_table09186a0080446625.html
|
|
#
¿
May 11, 2007 21:10
|
|
|
obsidian440 posted:I have very very little cisco knowledge and find myself more and more working with the company firewall/router. The info I get in the pix manager about is If you're stuck on 6.x, you'll need to look into setting the levels of the messages you're trying to pick out, then setting the pix to only send messages of that severity or higher, which might help your signal-to-noise. If that doesn't help you could look at moving to another syslog server like syslog-ng which has built in filtering capabilities so you could direct your 'interesting' logs to a special log file. If you feel like really going over the top you could then setup SEC (Simple Event Correlator) to watch that log file and take actions on the messages, like warning you if someone fails to log in too many times. Another alternative if you have the hardware, and can get the software, to do it would be to upgrade to 7.x and use the built in message list filter feature. As far as logging CPU/Memory, I'd have to recommend setting up cacti on a Linux host somewhere on your network and using that to graph the CPU/Mem/Interface Traffic OIDs.
|
|
#
¿
May 18, 2007 07:42
|
|
|
Cisco goons, you're my only hope (although I've been thinking of typing this up on c-nsp, but it'd probably degenerate into a 6500/7600 whine). All of this (mostly) takes place inside a single facility, the few services that extend outside the facility are not of a big concern / are another topic entirely. I really wish layer2 production networks wouldn't leave the building but that isn't too feasible, yet. My datacenter, over the past few months, has had a couple of service affecting issues, some of them out of our control (UPS failure), some of them our direct fault (accidental spanning-tree loops (thanks portfast) which freaked the hell out of the core network- plugging new switches into the core at 4pm is a bad thing). Due to various reasons, our network is a mixture of relatively old (3500XL access switches), and relatively new (3750 stacks for distribution, 2950G access switches on newer rows) gear, due to this we're somewhat limited in recovery time due to being stuck on PVST for the legacy equipment. Waiting 40 seconds for spanning tree to reconverge because a gig link dropped, really, really sucks. Doubly so because we have over the last year started offering more products, namely voice (as SIP out of our softswitch). And people really hate it when they pick up the phone and get a fast busy. Thankfully we've been able to provide decent QoS inside our network for the voice so people don't have quality issues, mls qos on xx50 series switches is pretty great, as is CoS based priority queuing in the 12k platform. Ideally I would like to completely eliminate reconvergence times after link failures, a lofty goal but I think we can get pretty close. Because of the issues, and the pressure placed on us by the customers, we've been looking at what we do in our network, and what our options are going forward (we're just about to start building out the 'second phase' of our existing space- a good a time as any to decide what you want to do for the next 2 years right?). Currently, we run fairly large layer2 domains, with layer3 terminating at our 2 'cluster'/'distribution' stacks (A & B), consisting of 3750G-24T's and 3750G-12S's. We have 2 /24 colo customer VLANs which span pretty much all of our access switches in production (7 I think at last count), 1 per row of cabinets- end of row switching. The distribution switches talk OSPF with our customer access routers (t1/ds3/oc3/external ethernet aggregation), and core routers, giving them knowledge of all our internal customer prefixes and enabling fairly optimal routing in the distribution-access layers. Since they're 3750 stacks though, they have a snowball's chance in hell of doing anything decent BGP wise to get them to make smart routing decisions at distribution, so I get all sorts of fun crap like packets coming up from a customer, up to 1 of my cores, back down through distribution and up to the other core- this is happening because the distribution switches have a default pointed up to an HSRP between the 2 core routers (12008s), so if the destination isn't bestpath in the router it ends up in, across it goes! So far, this has worked fairly well (up until a few months ago), and is a hell of a lot better than what we had a few years ago before we rebuilt during a move into our new facility, but this poo poo with spanning tree has got to stop, we can't be sitting with our thumbs up our asses waiting for the network to reconverge. So enough with the problem, my main point here is to present my solution (which I and my direct report both really like- but we still have to sell to management and his direct report), and see if anyone here can provide me some "hey did you think of X" or "I tried this and this really bad thing happened". This new design is heavily influenced by a Cisco implementation document- High Availability Campus Network Design— Routed Access Layer using EIGRP or OSPF. My Goals: - First a simple/sample diagram, all links here are point-to-point layer3 links. Currently addressed using /30s but I'm considering using /31s to converse address space. code:- To accomodate getting rid of spanning tree, I want to move the layer3 termination down into the customer access switch (probably using 3560s). 2 routed uplinks, 1 to each distribution switch. Then a handful of SVI's with /28s or /29s serving a handful of customers. These switches will participate in the OSPF loopback program, and limited iBGP as listed below. Spanning tree will be turned off on the customer aggregation SVIs. To try to prevent things from breaking we'll try to implement as much layer2 security as possible: -- Turn on portfast -- Set portfast bpduguard (shut your port off if you plug a switch in- I really hate it when people try to take my layer2 network out of the building) -- port security max-mac-count 1 -- switchport protected (just started considering this one tonight, by doing this and local-proxy-arp on my SVI I can stop the customers from talking directly to each other, and force all traffic to be processed and policed by the switch). - Reduce OSPF database size to get rapid OSPF convergence. Currently my OSPF database probably has ~3k routes in it. This kind of hurts on my slower processors like the GRP-B's in my GSRs. My plan to address this is to reduce OSPF to carry loopbacks only, then exchange customer prefixes via BGP only. --'Load Balancing' and failover between layer3 links will be handled natively via OSPF equal cost multipath. Since everything will have 2 layer3 links, every device should, under normal conditions, have 2 equal cost paths to reach any other loopback in the network. So long as I don't lose both links, my iBGP sessions should never drop. --The distribution switches will essentially act as route reflectors, cores peer with distribution, distribution peers with customer access routers (also 12008s). --My internal networks will probably be originated and 'pulled up' in the distribution switches, thus letting me simplify my routing tables at the core and customer access routers by only advertising aggregate prefixes to them instead of everything. --The new colo access switches will participate in limited iBGP with the distribution switches, the distribution switches will originate a default, and only a default, down to the access switches (to keep the routing table nice and simple) - I am also debating maybe doing the default in OSPF if I can figure out why it's not working out in my lab using stub areas. The colo access switches will advertise their SVI /28s and /29s as well as any subnets routed to customers, via BGP. While moving this functionality to iBGP instead of a traditional IGP will result in a 1 minute delay in the routes getting into the distribution table, I feel this is an acceptable delay since it is only once off (when the switch reloads), and it gains faster OSPF convergence which gets my ECMP back faster. - All internet traffic in the access/distribution switches will be in an internet VRF (vrf-lite in all the switches basically). This is mainly a management thing- I plan to use the main routing table for management access only- haul a single eth from every switch back to an isolated switch for a new management network. So I can actually get into the switches over ssh/telnet when the poo poo hits the fan. Part of this project will also be making sure we have working consoles in case that switch fails *grumble*. This introduces somewhat of a learning curve (remembering to type 'vrf internet' all the time), but I feel the management advantages outweigh the disadvantages. - OSPF is optimized as described in the Cisco doc above (200ms hellos for fast failure detection- in the future we will probably also look at doing BDF if the 3560 ever supports it), in addition to ispf to speed up spf calculations. - A major design goal is to keep customers out of the drat core/distribution layers (hey you kids, get off my lawn). We've been pretty poor about this up until this point, we have a couple of customers taking gig (copper mainly) out of distribution, and we tend to (ab)use the network for our own purposes too. Need to get 20 VLANs to an ESX box? Plug it into distribution! We also carry some of our internal network traffic (ugh) over VLANs in distribution. But that's another project. All of this up to this point seems to work fairly well in the lab. I get pretty much unnoticeable fail over (after a few tweaks) with my stack of 3550s (Core, DistA, DistB, Access). Running an Asterisk Echo Test with music playing into it results in pretty much uninterrupted music unless I do something terrible like pull out both gig links to the core or access. Reloading and hard powering down switches you're hard pressed to even hear a blip. I've come across a couple of problems, the biggest one was resulting from a distribution switch reboot and ECMP. Basically since OSPF comes up faster than BGP, my core was sending traffic for an access switch down to DistA, which didn't know how to handle it, so it sent it back up to the Core, back down to DistA etc. I managed to resolve this by adding a high metric static in each of the distribution switches, pointing to each other over the link between them. This way when a switch is still 'becoming active' after a reload, it will continue to pass traffic across to the other distribution switch which is still up, which will be able to forward the traffic as normal. My full table BGP customers I can continue to serve out of my customer access routers like I do now. I'll probably hang a dedicated switch off each of those GigE interfaces just for that, and keep them isolated from the distribution/core. There was a proposal to perhaps hang some these customers off 10/100/1000 aggregation switches, terminate L3 in the agg switch then have them to eBGP multihop to the distribution switches but this bugs me in 2 ways. -- we need to redistribute the customer's routes down to that agg switch via BGP. So if they drop their session it'll be 2+ minutes until the path back to them is good. -- Customers in distribution, get off my lawn. We do have some colocation customers who do HSRP with us for failover on our and their equipment, to continue to offer this I came up with the following solution: -- The customer will 'purchase' 4 switchports (in 2 adjacent switches), and a dedicated SVI/VLAN in 2 switches. 1 port out of each switch will go to the customer, the other 2 ports will be a dedicated 'tie' link to connect the 2 islands. Since I don't have any trunks up to the core this is the best I can think of, plus it gives the customer a dedicated link at their purchased speed to carry traffic which comes in over the secondary switch in the unlikely event that we lose all uplink on their primary switch. I'm sure there's more but this is starting to look like a pretty huge wall of text and it's getting late, if it helps I may have some Visio diagrams to look at tomorrow depending on if I'm motivated enough to work on them.
|
|
#
¿
May 18, 2007 08:48
|
|
|
inignot posted:I think you're looking for uplinkfast & backbonefast. PVST has a bunch of knobs besides portfast & bpduguard. Backbone fast is still going to cost me 30 seconds from what I'm reading, it saves 20 seconds of max_age timer but i still have 2x15 for listening and forwarding, but the situation that that would be detecting would be rare with my environment, uplinkfast would definitely save us some convergence time on the access switches though.
|
|
#
¿
May 18, 2007 19:35
|
|
|
jwh posted:That's not a good sign  jwh posted:Meaning, TCAM size is too small for full tables? jwh posted:That's a lot of layer 3. Are you confident that your IGP is going to reconverge AS-wide faster than spanning-tree in event of a link failure? Similarly, would these problems go away if you instead replaced your older gear with switches that supported RPVST+? jwh posted:I'm not much of an ethernet wizard, honestly, and I spend more time on the WAN side these days, but I almost feel like you're putting a heavy burden on your access layer. More intelligence at the access layer might mean more revenue opportunities, ease of management, and greater provisioning flexibility, but it also means more things that can break. Plus, if you need a customer VLAN to span multiple access layer devices, are you going to have to cross-connect those switches on an as-needed basis? jwh posted:Have you worked up all of the relevant routing protocol configurations with the vrf stuff? It can be a little screwy, ie, OSPF's vrf per-process instantiation versus mBGP address-family vpnv4. jwh posted:Well, you probably saw it too on c-nsp the other day, but apparently BFD has trouble getting below 250ms. That could have been a platform anomaly, I don't remember. If your tuned OSPF dead timer is 4 x hello interval, that's still really quick. jwh posted:I thought you were getting customer prefixes out of OSPF? Or am I misunderstanding? Are you talking about control plane traffic? 1) DistributionA (or B) had just rebooted, OSPF rapidly reconverged, BGP was still converging. 2) The Core switch(es) saw that they now had an extra path (via OSPF) to reach the loopback of the customer access switch (as this is iBGP, I am _not_ setting next-hop-self for BGP sessions or I lose my rapid recovery ECMP). 3) The core switch would now send traffic down to this distribution switch, which did not know how to reach the customer prefix, so it could not forward the traffic. I mitigated this with a high metric static to the other distribution switch which gets removed from the table when BGP is fully converged. Thinking forward this may be better handled by making these static routes for my prefixes only, so if BGP to the core comes up faster (thus replacing the static default with the BGP one) than the BGP to access, I don't create a Core-Distribution-Core routing loop. jwh posted:Yeah, ebgp-multihop is gross unless you're doing the neighbor loopback thing. -- Access switches would not know what prefixes the customer had until 2+ minutes had elapsed- the time for BGP scanner to run at distribution, and then again at access. -- I can't do BGP straight out of the access switch since it'll be a 3560/3750 and thus no full tables. Customers who only take default-only could potentially be served out of an access switch though. jwh posted:This one gives me the shakes. I guess if you can charge customer's for the cross-connect, it won't matter, and won't be like you're losing out on revenue producing interfaces. jwh posted:There's a lot to think about here, and you're obviously much more familiar with what you've worked up than I am, not to mention familiar with your business practices. That said, it sounds like you're in the business of providing colocation at the switchport level, as well as routed interfaces. Maybe an exercise would be to take your layer-2 access-layer out of the picture completely, and develop a framework that could accomodate both layer-2 colocation and layer-3 routed interface customers identically, sans ethernet access-layer infrastructure. Then, attach access-layer devices as if they were customer owned, but provider managed. Top-of-rack switching has only happened with 1 customer I think so far and that was a port issue- they had about a half dozen ports into our colo network for different customers of theirs, and didn't want to run their own common firewall/router for all their customers so we pressed them into letting us land a switch in their cabinet. This is an exception rather than the rule though, 95% of customers are regular-availability, single port customers. We don't have much of an issue where we're require top-of-rack anymore as the majority of our sales now are people who are taking 1/2, or an entire cabinet, we probably only have a handful (5, 6?) of shared cabinets on a floor of 120+. tl;dr on this, we'll still be doing layer2 colocation for the majority of the customers, but we will be limiting the layer2 domain to only a handful (5-15) customers, and the broadcast domain will not leave the switch so we have less issues like broadcast storms, or spanning-tree to worry about. The only customers getting dedicated SVIs in the access layer will be those who have purchased HA services. -edit- I forget, was the BFD issue in RRB? I think people have been seeing other issues in there related to CPU, could be bad scheduling. They were reporting BGP usage up to 80% of the CPU on boxes where it used to be 10% back on RRA. Why does the 7600 BU hate us. -/edit- Tremblay posted:As far as 7600/6500 goes the code trains are split now. More switching features will be implemented for 6k while more routing features will be making it into the 7k. I guess it mostly comes down to the capacity you need and topology (collapsed core or distributed). I guess wrt the 6500/7600 split I'm worried about : 1) Choosing 7600, hopefully getting some RSP720s- though probably not. Finding out that SRC release notes will say "The WS-X67XX switching modules will no longer be supported in SR". 2) Choosing 6500, getting screwed over by the 6500/7600 BU split and not getting decent (service provider) features in SX. I'm currently leaning toward the 6500 and hoping that SX will continue to add useful features for an iBGP only device. I'm probably going to keep all my eBGP in the GSRs for the foreseeable future. To make up for all these  , here's a picture of a kitten, no wait, my current layer2 setup: http://starshadow.com/~ragnar/731CoLo.pngEvery device has a Vl513 interface, used for management on the switches, for data plane on the routers and distribution. Vl401 and Vl421 terminate L3 in the dist switches, running HSRP for HA. Vl192 is our offnet management network that I really wish wasn't running in the production network, it's mostly out there to get ethernet to our cameras, console servers and muxes. Vl402 is one of our gigabit customer networks that we do BGP over (terminates in CustomerC or D I forget which). There's a customer in C201 that takes full tables from us. ragzilla fucked around with this message at 21:26 on May 18, 2007 |
|
#
¿
May 18, 2007 21:04
|
|
|
jwh posted:That'd be neat to look at; I managed to dodge route-target import/exports too, which turned out to be a good thing. I've been meaning to go back and lab the route-target stuff just in case we have a falling-out with Nokia, and decide to move our wan firewalls to another platform. jwh posted:I think a better question is why Cisco thought it was a good idea to compete with itself, just to capture a market that used a different nomenclature. It must have felt like a good idea at the time, but nowadays it's yucky for customers. I'm just glad I'm not in the market for one.
|
|
#
¿
May 18, 2007 22:42
|
|
|
Powercrazy posted:The 7600-S with the RSP already has a completely different code base, I can guarentee that the 67xx cards will work for the foreseeable future, I can also guarentee that 6500 is not going to get the same support as the new 7600 is. A safe (but expensive) bet is to go with the 7600. The RSP720 is a pretty awesome Sup, and combined with the new 7600-s as well as the new cards that will that will undoubtedly be coming out soon with the Fast Fabric Sync. I would be feeling pretty confident about my fail over options. Given our past purchasing habits some parts such as the chassis will probably be purchased from a company that does network rebuilds then sells the hardware pulled out to ISPs like us, so the chassis will probably be 7609 rather than 7609-S. Redundant Sups, while nice, may not be on the table (why do we need redundant sups in a manned datacenter, that's why we have a redundant chassis design) so the fast sup failover may not be a strong selling point there. If 67xx cards are going to stay in SR for the foreseeable future I'd probably (currently lean) toward 7609 chassis + Sup720 with an option for RSP720 upgrade (since they're going to act as RRs for the rest of the network the extra CPU could be useful for pushing out BGP updates and running scanner faster). 7609 chassis, Sup720, SR software? SR isn't going to go RSP only anytime soon is it, I don't imagine people with large 720+7600 implementations are going to be happy about forklifting all the sups in their network.
|
|
#
¿
May 18, 2007 23:00
|
|
|
obsidian440 posted:I hate to come off as lazy, but can I get some links to help me with doing this ? I didn't see anything that jumped out at me while messing with the logging options in pix. It looks like if you only want auth fails, (basically get rid of acl denys), you'll need to bump the logging up to Critical instead of Error severity. I typically tend to manage via pdm/asdm, but if you're managing through the console I think the command you're looking for is: code:Setting up cacti/syslog-ng is a bit beyond the scope of this thread, a bit of quick googling should get you plenty of information on them. jwh posted:That'd be neat to look at; I managed to dodge route-target import/exports too, which turned out to be a good thing. I've been meaning to go back and lab the route-target stuff just in case we have a falling-out with Nokia, and decide to move our wan firewalls to another platform. but the configs for the test layer3 access network I put together are up at: http://www.starshadow.com/~ragnar/switches/ Configs have (hopefully) been fully sanitized to protect the innocent. ragzilla fucked around with this message at 01:25 on May 19, 2007 |
|
#
¿
May 19, 2007 01:23
|
|
|
edit: double post
|
|
#
¿
May 19, 2007 01:25
|
|
|
NinjaPablo posted:I've got a 2620 that I am trying to setup MLPPP across 2 T1s on. Spent over an hour on the phone with the ISP trying to get this working. When I mentioned it was a 2620, he immediately said that it was probably too old of a version of IOS. MLPPP is supported in 12.0(7)T, mind showing us your configs? Is your ISP configured for MLPPP? Can you ping across the MLPPP bundle once it comes up/up?
|
|
#
¿
May 21, 2007 21:45
|
|
|
CrazyLittle posted:What's the newest firmware I can run on a Cisco 2621 with 8mb flash, 24mb dram? 12.1.27b or 12.2.12m If you upgraded the RAM to at least 32M you could run the latest which is 12.3.22 NinjaPablo posted:I was able to ping and telnet by IP address only when the MLPPP config was in place, or when I was only using a single T1 as PPP. As soon as I'd have the ISP update their end to not be MLPPP, and change back to HDLC, and I switched back to HDLC on my end, all normal traffic would work.
|
|
#
¿
May 21, 2007 23:22
|
|
|
InferiorWang posted:I have a question about spanning tree portfast. How many here make use of it, and where do you use it? As I understand it, I would want to use portfast on ports dedicated to end nodes only. Any sort of port that is linked to a switch in either direction shouldn't have portfast enabled. Am I right in this thinking? Yes. It enables a port to still have spanning tree enabled on it, but it skips the Listening/Learning states and heads straight to forwarding. If you do that into a switch or hub congratulations, you probably just created a loop.
|
|
#
¿
May 22, 2007 04:10
|
|
|
Korensky posted:The only situation where you'd compromise on performance in the 3750G series switches is if you're stacking them and joining the shared 32gig fabric together (in which case you have 2 x 16gig rings between the entire stack). If you do lots of traffic you'll notice the limitations of the 3750 (non-E variant) fairly quickly, the ring bandwidth is used for _all traffic_, even if it's between ports on the same switch. Due to the way to original StackWise system was engineered, the packets are source-stripped from the ring, ie the switch gets a packet, sticks it on the ring so everyone can get it, then when it gets back to the source switch it is stripped from the ring. The newer 3750-Es can do destination stripping, where the packet is stripped by the destination switch. They can also do local switching so packets going from port 1 to port 2 on the same switch, are switched inside that switch instead of going around the ring. http://www.cisco.com/en/US/products/hw/switches/ps5023/products_white_paper09186a00801b096a.shtml
|
|
#
¿
May 23, 2007 17:04
|
|
|
wolrah posted:Is there some wizard or guide where I can look and discover what model router I need to support a specific set of interfaces? Cisco Feature Navigator is useless in this regard. I don't think any 1600/1700 series hardware can do that. Your best bet's probably a 2621 or 2621XM which has 2 FE's built in, and 2 WIC slots (1 for WIC-1DSU-T1 and another for an ADSL WIC). Be forewarned that the ADSL WICs are quite expensive, it might be more cost effective to add another ethernet (with a WIC-1ENET) and plugging into a DSL modem/bridge.
|
|
#
¿
May 23, 2007 19:24
|
|
|
Jeff73 posted:T'aint so. From http://www.cisco.com/warp/public/473/21.html#vtp_ts_rec_ins I think this is something with DTP (switchports being set to switchport mode dynamic) than anything else, I just had a customer's switch (Foundry MLX) wipe the VLAN database on one of my cust aggregation switches, the switch was configured with just VLANs and it was in server mode. Nobody had ever configured the VTP domain/secret since we stopped using VTP. That's now in our standard configs (set VTP domain/secret).
|
|
#
¿
Jul 23, 2007 00:13
|
|
|
bj2001holt posted:My only complaint on the 5505 vs the 5510 are the licensing restrictions (only 3 vlans, 1 of those can only be used to make an interface management only). If you do trunking out of the 5505, you're supposed to be able to do up to 20 VLANs. -edit- ugh, I see what you mean about the licensing, without security plus it kind of sucks. -/edit- ragzilla fucked around with this message at 05:48 on Jul 31, 2007 |
|
#
¿
Jul 31, 2007 05:44
|
|
|
Already have an open TAC case but in case anyone here's seen it before: Turning up a new 7609 w/ RSP720s. We can get both RSPs up in SSO mode, but as soon as we turn on dcef-only fabric switching mode, the redundant RSP is no longer able to boot, it gets all the way up into the RP code, then abruptly drops to ROMMON and we get the following message on the active sup: code:
|
|
#
¿
Aug 2, 2007 03:37
|
|
|
Powercrazy posted:Do a show mod, and make sure that the RSP with the lowest firware revision is the active one. If they are both the same firmware and otherwise identical, then it sounds like you discovered a bug. It's SRB1, and yeah, there's a known bug (CSCsj12034), which is fixed in 12.2(33.1.1)SRB, but we're stuck waiting for SRB2 unless TAC can/will provide the rebuild. Both RSPs have the same Hw/Fw/Sw versions (both purchased brand new at the same time).
|
|
#
¿
Aug 2, 2007 15:22
|
|
|
Kind of off-topic but does anyone have any recommendations for IP assignment tracking/whois server software? I've been looking at IPPlan and FreeIPDB, so far IPPlan seems to be a better solution (integrated management and whois) but freeipdb's database layout seems to be better- but lacks the whois server.
|
|
#
¿
Aug 7, 2007 17:15
|
|
|
CrazyLittle posted:Is there any way to get an WIC-1ADSL to work inside a NM-2FE2W inside a Cisco 3640? I'm getting tired of trying different IOS loads. Anything with a Plus featureset is supposed to work: http://www.cisco.com/en/US/products/hw/routers/ps214/products_tech_note09186a00800ae37f.shtml Latest GD/LD/ED loads from FN: code:
|
|
#
¿
Aug 10, 2007 01:00
|
|
|
Tremblay posted:Do you really think you should be talking about this? Nothing he said there hasn't already been said on NANOG/C-NSP/Cisco Blog...
|
|
#
¿
Aug 10, 2007 04:08
|
|
|
delslo posted:I have 2 questions relating to my ASA5505 that I had posted earlier about getting. The cisco VPN is not using PPTP, it's using IPSec/L2TP so there's a couple of things to check: Do you have NAT traversal turned on on _your_ VPN config on the ASA? (Labelled NAT-T I believe in ASDM). Is the PIX blocking AH or ESP protocols?
|
|
#
¿
Aug 13, 2007 15:41
|
|
|
Arkady posted:Does anyone know of a way to make a 2950/60 switch or a 1800 series router to strip the 802.1p tagging? From the 2950 QoS FAQ. quote:Q. Can I override the incoming class of service (CoS) to a specific CoS value? code:
|
|
#
¿
Aug 24, 2007 00:51
|
|
|
Arkady posted:I've read that FAQ, but from my understanding all it does is override the COS with a different value, not strip it. Meaning I'd still be left with a COS value, be it 0, or something else. Am I wrong in this? If that doesn't work, you could try using the dscp-to-cos map, assuming the device doesn't also set DSCP bits? http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_9_ea1/configuration/guide/swqos.html#wpmkr1026216
|
|
#
¿
Aug 24, 2007 22:44
|
|
|
I can't think of anywhere better to ask this, and don't want to make a new thread Has anyone here ever terminated/scoped 50micron multimode before? We typically stick to 62.5 but our 10GbE xenpaks won't shoot far enough over it. The terminate/polish on our 50 micron looks good but when we scope it the edge of the core looks 'fuzzy'. Just wondering it that's normal...
|
|
#
¿
Aug 29, 2007 02:12
|
|
|
|
| # ¿ Apr 19, 2024 00:57 |
|
|
CrazyLittle posted:This thread's getting lonely. I have a fun bit of news: I just saved a bunch of money on my car insurance. No wait, Cisco pushed the SRB2 release back to late september (28th I think?). And the PM team will not be providing interim builds even though it's been stable for 'a couple of weeks'. Oh, and the devices I need to put it on go live this weekend, so I guess I need yet another maint window in early oct to do the code upgrade and apply dcef-only switching mode...
|
|
#
¿
Sep 13, 2007 00:58
|
|