[c-nsp] 4506 - disconnected ports generating traffic?
I have a very strange bug and am not getting much from my ticket with Cisco. I have a switch that has physically disconnected interfaces that show as up, are generating traffic (input, plus output drops), and logs show MAC addresses flapping between these interfaces. Plugging a cable in (whether or not there is a device at the other end), in some cases stopped this from happening. Has anyone run across this or similar behavior? 1 6 Sup II+10GE 10GE (X2), 1000BaseX (SFP) WS-X4013+10GE 248 10/100/1000BaseT (RJ45)V, Cisco/IEEE WS-X4548-GB-RJ45V 348 10/100/1000BaseT (RJ45)V, Cisco/IEEE WS-X4548-GB-RJ45V 448 10/100/1000BaseT (RJ45)V, Cisco/IEEE WS-X4548-GB-RJ45V 548 10/100/1000BaseT (RJ45)V, Cisco/IEEE WS-X4548-GB-RJ45V 648 10/100/1000BaseT (RJ45)V, Cisco/IEEE WS-X4548-GB-RJ45V This interface has nothing connected to it, but not the output drops and input traffic CLT-ACCESS-B2F1-1#sho int g5/27 GigabitEthernet5/27 is up, line protocol is up (connected) Hardware is Gigabit Ethernet Port, address is 0023.5e78.744a (bia 0023.5e78.744a) MTU 1500 bytes, BW 10 Kbit, DLY 10 usec, reliability 255/255, txload 229/255, rxload 229/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000-TX input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 05:03:57, output never, output hang never Last clearing of show interface counters 00:02:41 Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 59099365 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 89862000 bits/sec, 45921 packets/sec 30 second output rate 89862000 bits/sec, 45921 packets/sec 6696953 packets input, 1638126423 bytes, 0 no buffer Received 6696922 broadcasts (88192 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 6696953 packets output, 1638126423 bytes, 0 underruns These two interfaces have nothing connected: .Jun 14 00:11:35.578 UTC: %C4K_EBM-4-HOSTFLAPPING: Host CI:SC:OX:XX:XX in vlan 4 is flapping between port Gi5/28 and port Gi5/25 (the MAC address that is flapping is from the core switch that this access switch is linked to) Here is the interface configuration: interface GigabitEthernet5/27 power inline auto max 7900 switchport access vlan 4 switchport trunk encapsulation dot1q switchport trunk native vlan 4 switchport trunk allowed vlan 4,25 switchport mode access load-interval 30 qos trust dscp tx-queue 1 bandwidth percent 25 tx-queue 2 bandwidth percent 25 tx-queue 3 bandwidth percent 30 priority high shape percent 30 tx-queue 4 bandwidth percent 20 no cdp enable Thanks for any help or thoughts about what to look at or check. Josh Higham ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS with Voice and Video
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mikael Abrahamsson On Wed, 28 Jan 2009, Pelle wrote: That depends on the type of video, is it video conferencing (IP/VC) or streaming video (IP/TV)? IP/VC are interactive video, and have more or less the same requirements on latency, jitter and loss as VoIP. IP/TV on the other hand can handle more latency, jitter and loss. I am of another opinion. I don't believe in putting bursty traffic into LLQ. LLQ should be used for deterministic traffic (ie 20 pps VOIP or equivalent broadcast video with basically fixed pps and bw/s). Some platforms drop packets when it's over the prio limit and to protect from starvation of other classes I recommend putting a policer on the priority class anyway. In this case I am talking about video conferencing, and it will both be policed and have CAC in place. So while it does have variable bandwidth (depending on compression ratios), I will be accounting for maximum utilization. Given that, it appears to be viable either with both as priority, or video as non-priority bandwidth reservation. It sounds like it's only an issue if you either don't police it (so priority could burst to full link utilization), or if video can burst up to and above the police rate (which would then risk dropping VOIP priority traffic). Thanks for the help, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] QoS with Voice and Video
This isn't specifically Cisco but hopefully is fairly on-topic. What is the best practice (and real world) handling for voice and video queues? I am working on QoS implementation over our enterprise WAN (provider supplied MPLS) and was told that it was ok to combine voice and video in the priority queue, or even put video as priority and give voice a dedicated, but not priority, class. This is counter to everything that I knew/heard, which is that voice is low bandwidth and not bursty, where video is high bandwidth and bursty, so it could starve other queues. My options are: * voice as priority, with video dedicated non-priority * voice and video combined as priority * video as priority, with voice dedicated non-priority Does the queue starvation concern only matter if the priority queue is using near 100% of the circuit? I do have the ability to control the bandwidth used at other points if that helps. I want to avoid creating jitter in either the voice or video classes. Does anyone have any input or references about what the best approach is? Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Fwd: VLAN 1 through routed ports
From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Engelhard Labiro On Fri, Jan 9, 2009 at 2:22 AM, Justin Shore jus...@justinshore.com wrote: And by all means DO NOT USE VLAN 1. That's what bit me in the ass last night. An unconfigured 7600 LAN port with switchport, mode access and no access vlan defined was a piece in the puzzle of the cluster that was my evening last night. VLAN 1 is evil and anyone that uses it intentionally is a fool. agreed. ours always shutdown vlan 1 and define other vlan as native in trunk ports. this we can sure that user traffic is not using vlan 1. [...] If you shutdown vlan 1, the control traffic is still tagged with vlan 1, eg CDP, VTP. But your user traffic will not tagged with vlan 1 if you defined other vlan as native Either I'm misunderstanding what you are saying, or this is incorrect. The native VLAN identifier just dictates what frames are tagged, it doesn't control whether they are sent. So if the native vlan is 999, with a default config port is in vlan 1, if the port receives traffic it will still be sent over the trunk, but tagged with vlan 1 (rather than untagged if vlan 1 was native). Changing the native VLAN would not have prevented the problem that Justin is describing. The only solution to that is making sure that vlan 1 isn't used in production, so even if frames are generated there is no destination. Shutting down the vlan 1 SVI will make sure that no traffic from VLAN 1 is routed, which is a way of enforcing the policy restriction described above. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] VPN Routing vs Static Routing
Traffic is encrypted for a VPN based on the output interface; the VPN policy is applied to the interface the traffic goes out (often the public interface). Static routes apply to inbound traffic to determine the outbound interface. If the static route (default route or more specific) doesn't point the traffic out the interface with the VPN policy, the VPN won't come into play. You may be able to test this outside the lab by utilizing an unused interface, or at least an interface without a VPN. Create a VPN there for some generic network (some random website) not routed through that interface, then check that traffic continues to flow normally. Add a static route for the network and verify that it does hit the VPN tunnel (you won't see the tunnel come up, but you can watch debugs to see when the Pix tries to establish it). Thanks, Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nimal David Sirimanne Sent: Tuesday, October 07, 2008 1:38 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] VPN Routing vs Static Routing Hi guys, Assume that i have a VPN link from Cisco Pix to remote network 10.10.10.0/24. What would happen if i set another static route on the Cisco PIX to this same network 10.10.10.0/24. What would happen? Would the static routing take precedent? Will the VPN link break? Will the PIX IOS detect the conflict? Ideally, i'd love to test this out on a test network, but i can't, so perhaps if anyone has any experience with this, can you enlighten me? Thanks! Nimal ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] C2960G and output drops
[mailto:[EMAIL PROTECTED] On Behalf Of Gert Doering one of our switches is misbehaving, and I'm wondering whether this is a configuration thing, or a hardware limitation. GigabitEthernet0/10 is up, line protocol is up (connected) 5 minute input rate 19432000 bits/sec, 32108 packets/sec 5 minute output rate 380792000 bits/sec, 46406 packets/sec As you see, the ports are far from saturated, and even the load from all ingress ports (380 Mbit + 27 Mbit + 26 Mbit) is far from the capacity of the egress port (G0/10). As an aside, you can get more accurate numbers by configuring 'load-interval 30' on each interface. In the last discussion on this list I believe there wasn't an significant CPU impact. ciao Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Virtualization in an enterprise
I am currently investigating using vrf-lite within our company to support some research requests. I have some hesitation about maintaining it, though, especially in a smaller enterprise environment (4 network techs, ~10 branches). I am comfortable with the technology, but don't want to increase the complexity of the network without significant advantages. More importantly, I don't want to limit the applicant pool if we need to hire someone down the road. Does anyone here have input on support and maintenance of this within an enterprise environment? We have sites connected by MPLS (BGP with the provider, but no other MPLS or vrf type features) with redundancy through an IPSEC VPN over our internet links. Thanks for any input that you can provide. Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Virtualization in an enterprise
I am currently investigating using vrf-lite within our company to support some research requests. I have some hesitation about maintaining it, though, especially in a smaller enterprise environment (4 network techs, ~10 branches). I am comfortable with the technology, but don't want to increase the complexity of the network without significant advantages. More importantly, I don't want to limit the applicant pool if we need to hire someone down the road. Does anyone here have input on support and maintenance of this within an enterprise environment? We have sites connected by MPLS (BGP with the provider, but no other MPLS or vrf type features) with redundancy through an IPSEC VPN over our internet links. Thanks for any input that you can provide. Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Full meshed corporate network, QoS - best practices
Sergey Voropaev We can configure shaping for every single class. For example we can create class OFFICE_1---OFFICE_2 and shape it to 1Mb/s. And then shape all this classes by parent shaper applied to outbound interface. But this is also unacceptable because of if traffic to OFFICE_2 will be forwarded from TWO sites like as OFFICE_1 there will congestion on OFFICE_2's PE-router. Is there QOS solution for such design? The only way to do this (that I know about) is to purchase QoS of some sort from the SP. You configure your routers to send the correct markings to the SP, and they will shape at the point of contention. They will have some limitations on the number of classes and queue allocation, but the queue/drop/forward decision will be made at the point of congestion so you don't have to worry about doing any of that on your end. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Capture expressions on an FWSM (was Re: Telnet FROM a PIX Appliance?)
Tony Varriale wrote: Any chance you could give the group more details before saying it can't be trusted? I'm afraid I don't have any concrete details to add, but I've found capture expressions on Firewall Service Modules to be quite inconsistent. Presumably this is something to do with the modules interaction with the chassis? I haven't had the time to lab this, and I haven't always had problems, but I now generally work to the mantra that the absence of a packet in an FWSM capture is not proof that the packet does not exist, but the presence of a packet in a capture does prove it's existence. Perhaps there is a cisco documentation on this, listing known caveats and limitations? I found the same situation with the ASA (version 8.0 code). Normally you would expect the packet capture to be the very first code path, but this is demonstrably not true. In my case I had a span port on a switch and would get the packet, but a capture on the firewall did not show it. The absence of a packet is not proof that the packet doesn't exist Thanks, Josh - Original Message - From: Higham, Josh [EMAIL PROTECTED] To: cisco-nsp@puck.nether.net Sent: Monday, June 30, 2008 10:41 AM Subject: Re: [c-nsp] Telnet FROM a PIX Appliance? [mailto:[EMAIL PROTECTED] On Behalf Of Ziv Leyes I guess it's more as a working right educational purpose, so you won't use your firewall as a debugging client. In newer versions there's the packet tracker that can help you debug connectivity problems. Ziv As an FYI, the ASA/Pix packet capture cannot currently be completely trusted (version 8.0). I found an annoying bug where I would capture the frame on a span session monitoring the port connected to the firewall, but it wouldn't show up on the firewall capture. The packet in question was also being dropped by the firewall, but with no logging (and with a permit ip any any rule in place). The 'fix' was to apply a nat translation and then remove it. TAC was completely unhelpful (worst ever TAC experience). Blocking outbound sessions on the firewall also means that it can't be used to bounce an attack, if compromised. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ARP-cache Timeouts for ASA5520
12. There are currently 34 entries in the ARP table Is there a layer 3 device between your firewall and the majority of your hosts (ie is the number of devices in the ASA local scope fairly static)? If so, you should have no problem reducing the ARP cache to the minimum. The CPU impact of the ARP timeout is based on having to do an ARP request and wait for the response at expire time. This scales directly with the number of hosts in the various layer 2 domains, but I couldn't see the ASA having any problems processing 34 ARP even at the minimum timeout. You'll also need to make sure that the hosts don't have the same arp limitations, and that actually might be slightly more of a problem. Anyway, 5 minutes should be perfectly fine in your environment. I agree with the poster that said you should probably just ditch these if HA is a hard requirement, but sometimes budgets and requirements make for clunky solutions. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Giving customers access to your gear.
[mailto:[EMAIL PROTECTED] On Behalf Of Justin M. Streiner On Tue, 3 Jun 2008, Richey wrote: I've got a customer with a T1. They have been bought out by a large hotel chain. They are pretty much demanding that they have SNMP full read access to our router that is at their location as well as a copy of the config for the router. This is not their router, it is ours and we 7. Lock down the console and aux ports. It's an easy step to overlook, but after getting a call from my NOC at my previous job necause a customer with two routers managed by us decided to have a consultant do password recoveries on them (without my employer's knowledge or consent) so they could 'tune' (read: break and not know how to fix) HSRP, over a holiday weekend, it's something I will not overlook again... The only way to avoid this is disabling password recovery. I'm not certain if this is what you are suggesting here, but nothing in the running configuration of the aux/con ports can prevent a recovery. Other than that, though, the reactions seem a bit on the harsh side, for someone requesting _read_ access to the system, assuming that it is strictly used for their business. I could see a charge for the time involved, and having one-off configurations is not good, but I don't think it requires a flatout refusal. There are a few things that I see that could be problems, definitely not an exhaustive list. 1) Passwords - they will be able to get your vty password, so use local user accounts and AAA. 2) Routing - they may be able to get some info about your internal network. Counter this by requiring that they switch to static routing (and lose any current redundancy) if they desire this, or possibly eBGP (not sure if this is a good idea or work, but basically don't show them your IGP). 3) Security issues - these are issues regardless, so having them exposed to the customer just means you need to be more proactive. 4) Management IP addressing could be an issue (revealing that by interface). The alternative is to manage it differently, but again that falls into the 'one off' scenario. Verizon and other providers are willing to rent/lease you hardware, and configure it, but it is always treated as a customer CPE. This means that it is not part of their network (no IGP, management addressing schemes, etc), and has no information to be revealed (as far as I know... I have only actually been in this situation a couple of times). Anyway, that's the Devil's Advocate argument. I don't think the request is worth dismissing out of hand. Thanks, Josh 8. Back the configuration up regularly, using a backup system with journaling/version control capabilities so you can see changes over time. RANCID is quite useful for this. I ended up writing something in-house, but the code is not packaged in a releasable format, so I haven't turned it out to the masses yet. 9. Specifically note what actions are and are not allowed in the service agreement (see above). 10. Affix stickers to the router explicitly stating that unauthorized access is prohibited. 11. Talk with your legal counsel about reasonable limitations of liability in circumstances like this. [1] - http://www.cymru.com/Documents/secure-ios-template.html my 2 cents :) jms ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LWAPP Problems
If an access point has connected to a controller, I believe that it attempts to connect to that controller as part of the discovery process. It is another of those 'invisible' configuration errors, that only raises its head months or years after the fact. You could test with a new access point, or change your management IP address and bounce an AP. You can also watch LWAPP debug on the console while power cycling the access point, and/or span the port and verify. Thanks, Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 7:37 AM To: Fred Reimer; Rupert Finnigan; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LWAPP Problems Interesting. Why does it work? -- Regards, Jason Plank CCIE #16560 e: [EMAIL PROTECTED] -- Original message -- From: Fred Reimer [EMAIL PROTECTED] ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco WCL- 4402 - Max AP LAG
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Cartier Sent: Wednesday, May 21, 2008 11:08 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco WCL- 4402 - Max AP LAG I've heard somewhere...and possibly read somewhere that in order to get the full 50 AP allotment out of a Cisco Wireless LAN Controller 4402 model, 50 AP, you have to Port-Channel/LAG the two Gigabit ports together. Not correct, to my knowledge. We have the 4404 100 AP units and none of our channels are bonded. During the AP discovery process the controller assigns the AP to a given port to maintain distribution, so I can't see any reason why it would be necessary to have them bonded. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Maintenace management
Purchase enough where you have a vendor who will manage it for you and the cell number of an account rep at Cisco that you can call if there are problems. Another important item is to make everything coterminus (generally the end of the year) so that you can set aside time and make sure to cover everything that you need, rather than doing it on an ad-hoc basis. We recently had an RMA delayed by several days because the TAC entitlement DB did not match the account entitlement DB, even though the contracts had been purchased months before. I can't imagine what actually happened or why the process even uses two different databases. Thanks, Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Mayers Sent: Monday, May 19, 2008 11:01 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Maintenace management All, We seem to have an incredibly hard time managing our maintenance contracts. Quite aside from the vagaries of CCO (Sorry sir, your contracts have disappared from your profile, no TAC access for *you*) we are unable to gather all our maintenance into one (or a small number of) contract(s) and what contracts we have are very difficult to inventory. It goes without saying that SCC is a bad joke. Do any of you manage to do it better? How? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3750 etherchannel only using 1 port
[mailto:[EMAIL PROTECTED] On Behalf Of Paul I did the test etherchannel of course and it's working properly, but since I am using the cef load balancing (two 0.0.0.0 routes with the same cost) and it's going out two port channels the algorithm for that must be exactly the same as the one for the etherchannel, which explains why on etherchannel #1 the packets are going out port #1, and on etherchannel #2 the packets are going out port #2.. This is a very interesting phenomenon :) Painful. Can you do per-packet routing rather than per-flow in your environment? Alternatively drop etherchannel altogether and just make them all L3 links, with 4 way equal cost routes. If you are stuck on etherchannel you might be able to change the algorithm so that it's less effective but different (src IP rather than src dst XOR or whatever). Hope that's of some use. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Securing virtual networks
What methods are available for making sure that no traffic leaks between virtual networks? I am looking at doing some sort of virtualization for a small enterprise network (so no software based provisioning) and want to either prevent or detect misconfigurations. If I restrict the address ranges I can use netflow and ACLs, but that removes one of the benefits. This isn't a hostile environment, but would include a guest network so malicious attacks are possible, along with the obvious virus issues. We have a collapsed core, so I would be using VLANs within the LAN, and GRE tunnels across the WAN. We can't count on a typo breaking something because some of the networks will be infrequently utilized. Any suggestions? Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Securing virtual networks
From: Nate Carlson [mailto:[EMAIL PROTECTED] On Thu, 13 Mar 2008, Higham, Josh wrote: What methods are available for making sure that no traffic leaks between virtual networks? I am looking at doing some sort of virtualization for a small enterprise network (so no software based provisioning) and want to either prevent or detect misconfigurations. What type of virtualization are you talking about? Something like VMWare/Xen, or network virtualization? Network virtualization. If I restrict the address ranges I can use netflow and ACLs, but that removes one of the benefits. This isn't a hostile environment, but would include a guest network so malicious attacks are possible, along with the obvious virus issues. OK - so put the guest network off on it's own VLAN, and isolate it. I know that I can isolate it in a VLAN, but I want to avoid having a single point of failure. If someone puts a port into the wrong VLAN, and the user gets a DHCP address (two segregated user access networks, for example) we might not know until it actually causes a problem by releasing a virus (or worse, a directed malicious attack). This is historically the reason for using physical seperation, but that's no longer viable. I am just wondering if there are any good ways to protect against user error, or if people just ignore it. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] I need help. Cisco Etherswitch PoE Module Not PoweringIP Phones
[mailto:[EMAIL PROTECTED] On Behalf Of Felix Nkansah This is to provide more info towards helping me solve the problem. When I do show power inline in the module, I get the output below in the first lines. Module Available Used Remaining (Watts) (Watts)(Watts) -- - - 1 n/an/a n/a Do a 'show power inline' from the router, you should see the following: PowerSupply SlotNum. Maximum Allocated Status --- --- - -- INT-PS 0 240.00024.400 PS GOOD Interface Config DevicePoweredPowerAllocated - -- ------- Gi1/0 auto Unknown On24.400 Watts Big beef; if you do not have a module that uses inline power, there is no way to determine whether you have an AC-IP power supply (the show command isn't available). Next big item, undocumented and took the TAC over an hour to figure out, you must permit VLAN 1 (and I think CDP?) on the trunk to the internal switch for power to work. Hope that helps. Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] eigrp and ospf on same switch
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Steele Sent: Saturday, March 01, 2008 11:32 PM On 02/03/2008, at 4:55 AM, Dan Letkeman wrote: Is there a simple explanation as to how the metric is calculated for eigrp? 5 things, Bandwidth, Delay, Reliability, Load and MTU. Most people should really only need to worry about the first two when modifying for redistribution, that is bandwidth and delay, the remaining 3 can generally just be set to 255 1 and 1500 respectively, unless you see fit to change them for a specific reason. A small note, the default for EIGRP is to only consider bandwidth and delay, so the other values will have no impact. You can change this behaviour, but shouldn't do it unless you really know what you're doing (I have never seen it in production myself). Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Result of Duplicate SEQ on Prefix List
In a case like this I find it easiest to test by creating a fake prefix list and running the command. Check whether the line was replaced, or if you get an error. I believe that you get an error, but it's easy to safely test. If it does replace the line there is the chance of a bug which wouldn't be detected in this manner, but it's a good first step if you are wondering about how an ACL or prefix list behaves. Thanks, Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Koch Sent: Thursday, February 21, 2008 3:34 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Result of Duplicate SEQ on Prefix List hi all - if by mistake a prefix list was added with the same sequence number, would there be any negative result? the prefix list would be referenced in a route map which sets metric for hsrp-active/standby so if i have ip prefix-list HSRP-S seq 2 permit 10.10.10.0/27 and the following is added by mistake ip prefix-list HSRP-S seq 2 permit 10.10.11.0/24 would there be any impact? the related route maps look like this ! route-map ospf-connected permit 5 match ip address prefix-list HSRP-A set metric 50 set metric-type type-1 ! route-map ospf-connected permit 10 match ip address prefix-list HSRP-S set metric 100 set metric-type type-1 ! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] internal enterprise MPLS/VRF recommendations
I have a couple of internal groups that need some level of private connectivity within our network, and I'm looking at some high level input about the various options. We currently have an MPLS network between most sites, with IPSEC connectivity for a few minor sites as well as backup for all locations. Number of sites is small and will stay in that range (10-20). We need to be able to connect networks internally, but maintain security. One example is guest networks, which must be able to traverse the internally network to have internet redundancy, as well as hit DMZ servers at all locations. We also have some internal non-network labs that need to be connected across sites without impacting the production network. We do have a fair amount of control to dictate the limits of what can be handled. While we could use full MPLS and have complete transparency, it is also possible to just restrict the traffic to certain networks. However it'd be nice to building it fairly flexible from the ground up. There are several options that I can think of, but I would like input about the weaknesses or complexity and any options that I might be missing. 1) ACLs on interfaces, but route traffic as normal 2) L2TPv3 tunnels 3) VRF at each site, route between sites normally 4) VRF at each site with GRE tunnels between 5) MPLS carried internally as well as externally 6) ... ? Thanks for your help, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5510 Code
Second the bugginess of 8.0 I had two problems, one was with an ACL where a permit entry was not being hit, fixed by a reboot and the other as follows: Inside network: 192.168.100.0/24 DMZ network: 172.16.0.0/24 No nat in place. I could ping from 192.168.100.66 to any host in the 172.16.0.0 network. From 192.168.100.100 I could only ping two hosts on the 172.16.0.0 network. Doing a packet capture on the firewall showed no return ICMP, but a capture on the switchport showed the echo-reply. Even worse the Cisco security team blew me off and said that if the capture didn't work, then data isn't reaching the firewall. As an interim fix we did a nat for that IP address and everything worked. Then I removed the nat and everything still worked. Overall I'm not that thrilled with code quality to date. Might even look at downgrading to 7.x Thanks, Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Steele Sent: Friday, January 25, 2008 1:16 AM To: William Cc: [c-nsp] Subject: Re: [c-nsp] ASA5510 Code I'd recommend 7.2(2) I've got it running on a few 5510's that have been up without a crash for about a year, 8.0 does bring some really nice new features but unless you need them i'd steer clear of it for now as i've encountered a few annoying bugs. Cheers Ben On 25/01/2008, at 6:57 PM, William wrote: Hey, I'm implementing a ASA5510 for L2L VPN, EzVPN, VPN Client and other basic firewall functions, can the list recommend a stable version of code for my application? thanks for your time! W ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Two access-list questions..for Internet router
[mailto:[EMAIL PROTECTED] On Behalf Of jacob c Sent: Tuesday, January 22, 2008 8:46 AM 1) Does anyone see any issue with ONLY allowing 1.1.1.65 /27 range into my network since that is my only Public IP Range? Make sure that you include your interface IP (if you have a routed block), but I think that's a pretty common configuration. 2) Is it best practice (performance-wise) to put my hardened access-list which includes the statment above on the s0/2 interface for the gigabit ethernet interface? Put it on S0/2; drop the traffic as early as you can. To the other poster regarding the 1.1.1.x addresses; I think that was just an attempt to keep the question generic. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560/3750 12.2(44)
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Louis I recently upgraded some switches 3750 from 12.2(35) ipbase to 12.2(44) and now the ip tacacs source-interface command is missing Anyone else seen this?. I upgraded my lab 3560 to same rev of code and found the same command missing. I believe that the source-interface command is silently dropped if the interface doesn't exist. Not sure if that's what you hit, but it's caught me on several occasions. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco 1841 Router CRC errors
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Storey On 18/12/2007, at 7:42 AM, Paul - Talk Talk wrote: We have upgrade our lease line from 4mb copper to 10mb fibre which meant we had to change our router. The old router was a Cisco 2620 and the new Router is a Cisco 1841. Between the Cisco Router and our Cisco 3550 layer three switch is a bandwidth management box, which is an Allot NetEnforcer AC-402. On the old the old set-up using the Cisco 2620 everything worked fine. On the new set-up with the Cisco 1841 we are seeing a lot of CRC errors until the whole thing falls over. From our side nothing has changed except the router which was supplied by the ISP. We did find out that the FE0/0 interface on the Cisco 1841 was set to auto, but this has now been set to Full Duplex 100mb which matches the Allot NetEnforcer. Taking the NetEnforcer out and connecting to the Cisco 1841 directly to the Cisco 3550 stops the errors, but as said before switching back to the Cisco 2620 also stops the errors. On one particular PC I have cannot auto negotiate and cannot be set to 100/full without producing errors. I have to run it in 100 half. At least this one is only a PC. Its got a Broadcom NIC. My suggestion would be, if you can spare two ports on the switch, to create a VLAN and stick the two interfaces that would normally connect directly to each other into that VLAN. Otherwise, try different cables between the two, set the port to 100/half, and try different interfaces if you can. I may have other issues with the PC above, such as a dodgy cable. I havnt gone so far to test that out yet as its bandwidth requirements are low, 100/half does just fine. I can't imagine that running half-duplex is a good idea. I have had interfaces on the 28xx series (in particular with the HWIC ethernet) where they have had to be set to auto/auto on both sides to not produce errors. This includes connecting to a Cisco switch on the other end. Since your upstream is 10Mb you can probably also get away with running 10/Full, although it makes increasing bandwidth in the future a bit more cumbersome. Thanks, Josh ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] WIC errors
We just had this crop up last week, with a genuine Cisco WIC. TAC said they have seen it before, and reseating (2-3 times) should resolve the problem. We have not tried the fix yet, though (would like to know if it works). Notably in our case the T1 interface was administratively down, fwiw. Thanks, Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Mattinen Sent: Monday, July 09, 2007 6:07 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] WIC errors Neal R wrote: Is it genuine Cisco or a counterfeit? Hint ... 92% off sales on Ebay of Cisco ... aren't. I know I have a bunch of counterfeits, but the trouble WIC is a stewart version with a Cisco hologram on the board. As far as I know, it's an official one. If not that what version of software are you running? Seems unlikely this would be a code issue but sometimes I ask and find its blah.bleh.1T or something like that for the version, which is definitely cause for considering an upgrade. 12.4.10a on a 2811. ~Seth ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
