Re: [c-nsp] hardware fault on sup720.
On Apr 29, 2011, at 5:58 AM, Phil Mayers wrote: You'll need to provide more details about your config, topology and nature of the adjacent devices before someone can answer your question properly. thanks Phil, I decided instead of doing a live insert risking a switch lock up (someone responded directly to me stating they have seen 6500's crash during a line card insert) we'll schedule a window for this. The safe harbor line of code has had several updates since the last time this switch was rebooted for upgrades (@3 years ago), so its an opportunity to do other maintenance at the same time. but to answer your question, this switch holds only static routes and multiple LACP uplinks to other L2 switches. take care and have a great weekend, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] hardware fault on sup720.
hello, a confidence building question… we have a sup720 in a 6500 which has developed a 'minor fault'. The unit is up and still forwarding but Cisco recommends we replace the module asap. I have a second sup720 (verbatim). There is only one SUP in the chassis at this time. my plan is to insert the new 720, sync the config then fail the primary and pull it out. seem sane? how long does the fail over process take? thanks for your time, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] 6500's SLA check feature
These are run on the RP. Remember, you're trying to measure the performance of the forwarding plane on your routers, not the management plane. thanks Nick. wasn't seriously considering it, discovered it by accident, thought id ask. for a brief weak moment there i thought it might be the cadilac of naglios. -g -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] 6500's SLA check feature
Good morning, the ip sla monitor feature set in 6500's. are these 'safe' to use from a system resource contention perspective if you have several (@60) defined?is the code executed on dedicated silicon?are they reliable or would it be better to not use them and rely on a dedicated to the task box? thanks for your time, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] Understanding 10G line card oversubscription
the 6500's are not very well suited for many roles these days in DC land, especially if your into HPC.if you are using a policy engine such as the FWSM, you now only have 4G if your traffic has to pass threw it. if memory serves me correctly. We started seeing input drops which lead us to start a deployment OSPF-ECMP so we could balance and route around the core 6500.. kinda sad when you consider the cost of the kit.we bought a pair of extreme switches last round, they blow the socks of anything we have had from Cisco (so far!) in terms of features, performance and cost of ownership. just my opinion, i may be way off base. greg On Mar 21, 2011, at 5:26 PM, Mack McBride wrote: There is the 4 port group which I believe is the same as a port pair on a 6708. Ie. No free switching. Based on some comments by Tim Stevenson, the link between the four port group and the fabric asic is 10G rather than the 16G in the 6708. But he mentions some of the same chips (metro, r2d2) so the architecture can't be much different from the 6708. Then there is the fabric group which is switched locally without going over the fabric. show asic slot x sh int interface capabilities | inc ASIC Of course a diagram would be really helpful but those usually come with an NDA. 6708 results: ASIC Name Count Version KUMA 2 (3.0) METRO_ARGOS 2 (3.0) METRO_KRYPTON 2 (3.0) SSA 2 (9.0) R2D2 8 (2.0) TIANGANG 4 (54.0) Tex/1 Ports-in-ASIC (Sub-port ASIC) : 1,4-5,7 (1) Tex/2 Ports-in-ASIC (Sub-port ASIC) : 2-3,6,8 (2) My understanding of the chips is as follows: R2D2(per port) - Tiangang (port pair) - Metro argos - SSA (Fabric complex) Metro Krypto interfaces to the EARL complex aka PFC (local switching/routing to avoid fabric) Kuma acts as a bus bridge (not relevant to fabric switching) The assumption is that the Tiangang is replace with another chip that can handle 4 ports. I assume the new FPGA - Metro link is somehow different on the 6716 but I don't know how. The 6704 skips the tiangang chips and directly connects the R2D2 to the Metro. From a Cisco doc (http://www.cisco.com/en/US/docs/ios/vswitch/command/reference/vs_02.pdf): ASIC Name Count Version KUMA 2 (2.0) METRO_ARGOS 2 (2.0) METRO_KRYPTON 2 (2.0) SSA 2 (8.0) R2D2 4 (2.0) Short answer seems to be that the 6716 is basically the same despite claims to the contrary Mack -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Monday, March 21, 2011 1:51 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Understanding 10G line card oversubscription On 03/21/2011 06:33 PM, Mack McBride wrote: The 6716 is going to have similar limitations but I don't have a good document on how the port asics connect My understanding is that the 6716 is quite different from the 6708. There's no free local switching within port groups AFAIK. The differences have been discussed on the list before. If someone can verify the connection method and limitations on the 6716 it would be appreciated. Do you have specific IOS commands? We've got a few in service. ___ 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/ Gregory Whynott Networks and Storage Ontario Institute for Cancer Research MaRS Centre, South Tower 101 College Street, Suite 800 Toronto, Ontario, Canada M5G 0A3 647-294-2813 | www.oicr.on.ca -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] debug to see what IP is trying to log in via telnet
wouldn't the IP of the host it speaks of in the logs? or does it just say failed log in from somewhere out on the network…? my logs have a src… %SEC-6-IPACCESSLOGP: list denied tcp 88.243.16.148(3900) - 10.142.7.1(23), 1 packet -g On Feb 23, 2011, at 2:40 PM, Alan Buxey wrote: hi, okay...i appear to have mislaid some memory cells over the past month which coincides with a major bout of unable to drive google/bing or cisco.com properly(!) ;-) basically, auth logs show a device somewhere is trying to log into some switches with wrong user/pass. and I cant recall/dig how to debug on the switch to see what IP is causing the mischief the obvious 'debug telnet' only debugs the negotiation/method/junk rather than provide anything usefulany chance someone can throw me a line to jog my memory on this score? cheers alan ___ 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/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] ASA
sounds scary, if i were your manager I'd be concerned and full of doubt about your intentions. you want to allow remote administration of the device at a company (i assume) and are not sure how to do 'day 1 of school' configurations. the next question will be my terminal froze when configuring our firewall from home, how do you remove a 'deny any any' statement remotely when you can't reach the device anymore? google 'configure ssh cisco asa' -g On Feb 16, 2011, at 7:21 AM, Eric Van Tol wrote: -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Deric Kwok Sent: Monday, February 14, 2011 2:34 PM To: Cisco Network Service Providers Subject: [c-nsp] ASA Hi How can I be easy to do? 1/ disable httpd access from inside/management ip? 2/ allow ssh from outside int 3/ only allow dedicated access to https from outside interface I'm sorry, but do you *ever* look at the 'Getting Started' documentation or use Google? ___ 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/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] Fwd: ASA [AR]
I think someone got canned this morning. 8( -g Begin forwarded message: From: Qwest Autoresponse qwest...@qwest.commailto:qwest...@qwest.com Date: February 16, 2011 11:10:18 AM EST To: Greg Subject: Re: [c-nsp] ASA [AR] Thank you for contacting Qwest, we appreciate your business. The email address you have sent to is no longer accepting messages. We apologize for the inconvenience offer the following contact information to redirect your request. Residential: 800-244- Small Business: 800-603-6000 Large Business: 800-777-9594 Federal Government: 800-879-1023 Mid-Markets: 800-763-5843 http://www.qwest.com/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] ASA bug?
Thought I'd get some opinions before I ask Cisco… I have an ASA5540 with several DMZ zones defined. Several months ago a project required a new zone. This was created, but the project was put on hold and we created a deny any any on the outside interface into this new zone, just to be safe. fast forward several months later. project is back on the table. I'm asked to allow http/s into the new zone. I have a brain failure and forget that we put a 'deny any any' statement in a few months back. We have a few hundred lines of ACLs and several DMZs, so things can be not so clear to see when viewing the config.. appended to the bottom of the list is my new 'allow http/s' into new zone.works fine from inside but not from the internet. I'm wondering why.. so I define a ACL which i'll use in a capture: access-list capacl1 extended permit ip any host x.x.x.x access-lsit capacl1 extended permit ip host x.x.x.x any simple enough. host x.x.x.x is a host in the new dmz zone. I apply it to the new dmz interface: capture cap1 access-list capacl1 interface newdmz real-time from an internet host I attempt a connection to port 80: ggw@76.65.229.23:~$ telnet x.x.x.x 80 I see the packets egress the newdmz interface: 1: 15:55:11.839525 802.1Q vlan#560 P0 x.x.x.x.2716 192.168.53.19.1433: . 3365025458:3365025459(1) ack 2402449091 win 64453 2: 15:55:11.840303 802.1Q vlan#560 P0 192.168.53.19.1433 x.x.x.x.2716: . ack 3365025459 win 64374 3: 15:55:12.070079 802.1Q vlan#560 P0 192.168.53.19.1433 x.x.x.x.2716: . 2402449090:2402449091(1) ack 3365025459 win 64374 4: 15:55:12.070202 802.1Q vlan#560 P0 x.x.x.x.2716 192.168.53.19.1433: . ack 2402449091 win 64453 5: 15:55:21.180608 76.65.229.23.61388 x.x.x.x.443: S 2533989180:2533989180(0) win 65535 mss 1260,nop,nop,sackOK 6: 15:55:24.070659 76.65.229.23.61388 x.x.x.x.443: S 2533989180:2533989180(0) win 65535 mss 1260,nop,nop,sackOK 7: 15:55:30.085978 76.65.229.23.61388 x.x.x.x.443: S 2533989180:2533989180(0) win 65535 mss 1260,nop,nop,sackOK I see packets egressing the dmz interface into the dmz zone…In my mind this is not a firewall issue as the packets are being forwarded into the zone, as expected. the reality is there was a deny ip any any into newzone applied to the outside interface. I should not of seen these packets when running a capture on the dmz interface, correct? this caused me to spin my wheels on this for 1/2 a day till I noticed the acl in the outside_in section… soon as I removed the acl element from the outside_in, things worked.. am I not understanding something here or does this look wrong? thanks for your time, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] ASA bug?
sorry you are correct, that would of been useful information. I also neglected to mention that we ran tcpdump on the target machine within the DMZ, the packets were not actually leaving the fw interface, even tho the capture indicated they were. I have a second ASA5540 not in use (is for a redundancy project), if i get some cycles this week i'll apply the same config/OS to it and avoid filling out change control requests.. Cisco Adaptive Security Appliance Software Version 8.2(2)5 Device Manager Version 6.2(5) Compiled on Wed 03-Feb-10 20:02 by builders System image file is disk0:/asa822-5-smp-k8.bin Hardware: ASA5580-20, 8192 MB RAM, CPU AMD Opteron 2600 MHz -g On Jan 25, 2011, at 11:27 AM, Peter Rathlev wrote: On Tue, 2011-01-25 at 10:48 -0500, Greg Whynott wrote: [...] capture cap1 access-list capacl1 interface newdmz real-time [...] I see packets egressing the dmz interface into the dmz zone…In my mind this is not a firewall issue as the packets are being forwarded into the zone, as expected. the reality is there was a deny ip any any into newzone applied to the outside interface. I should not of seen these packets when running a capture on the dmz interface, correct? this caused me to spin my wheels on this for 1/2 a day till I noticed the acl in the outside_in section… soon as I removed the acl element from the outside_in, things worked.. That does sound strange. Just tried something similar on an ASA 5550 8.2(4) with no problems; the capture shows/doesn't show the expected packets fine. You didn't mention platform and version, which is always a good thing if you want people to test it on something similar. Can you recreate this on another pair of interfaces on the same box, i.e. not towards the dmz interface mentioned here? And can you recreate it on the same interface? -- Peter -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] ASA bug?
Alan, thats a very handy command. while it would of identified what was blocking the traffic right away, saving me a few hours of wheel spinning, it doesn't shed much light onto why the ASA is indicating it is forwarding packets out the interface. thanks for responding, greg On Jan 25, 2011, at 11:28 AM, Alan Buxey wrote: hi, use the lovely handy (though basic) packet tracer feature of the ASA to find out why and where the rule is failing! alan -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] ASA bug?
Hi Peter, have a meeting to run to, i'll hit your questions in point form, sorry.. - 8.2(2)5 - i am not aware of any ssl licensing issues, i should look into that and see if we are affected. thanks. - i was never one for GUI's, but after 17 years of cli i'm starting to warm up to them.. i'll give it a look, while no one is around. - I have in/out ACLs on most interfaces, including the outside interface. within the outside_in policy there was an ACL: access-list outside_in extended deny tcp any object-group OEB_NETWORK (OEB_NETWORK is the 'new dmz zone' I'm referencing.) on the OEB dmz interface there is another policy applied to traffic leaving the OEB interface into the OEB dmz, into_oeb. I added to this policy: access-list into_oeb permit tcp any object-group OEB_NETWORK eq 80. I expected this to allow traffic to pass. it wasn't until later when I removed the above ACL from the outside_in policy that things started to work. i think that answers your question.(?) Typically I add policy as close to the zone as possible, but because this project was put on hold, I added a deny-any-to-oeb within the outside_in policy because at that time the into_oeb policy did not exist nor was defined.. it wasn't until i got the requirements yesterday that I started to define the policy. hosts in this DMZ are not permitted outbound comms, if i (which i did during debugging) permitted it, it would work properly. k gotta run, thanks for your reply, greg On Jan 25, 2011, at 12:14 PM, Max Pierson wrote: Hi Greg, That does look quite strange indeed. As Peter said, it would be much more helpful if you could send what code you're working on. We we're on 8.2.(1 i believe) and never had any issues similar to what you described. Had to move to 8.3 due to the SSL licensing issue, and now on 8.3.2 (still have not had any issues after I fixed Cisco's wonderful mess it made of my tunnels on the config conversion) but that's another story I hear ya about having alot of config to look through. Management wanted to do the pay as we grow and went with a 5540 to start. We're now on our second so you could imagine the amount of config we had (almost 100 or so tunnels and to many to remember DMZ's with hundreds of lines of ACL's). Needless to say, I love the cli, but when you have to scale like that, it's just easier on the eyes (and mind lol) to just use the ASDM. As far as your issue, I see that you mention initially had deny any any on the outside - DMZ , then towards the bottom of your post, you say that you removed outside_in. Do you mean outside - said DMZ was remove at the bottom and all started working?? Or did you remove an ACL in that zone set outside to inside and it fixed the issue?? Can the host in this DMZ get packets out and if so, what are you seeing when they attempt to come back in the outside interface?? Max On Tue, Jan 25, 2011 at 10:27 AM, Peter Rathlev pe...@rathlev.dkmailto:pe...@rathlev.dk wrote: On Tue, 2011-01-25 at 10:48 -0500, Greg Whynott wrote: [...] capture cap1 access-list capacl1 interface newdmz real-time [...] I see packets egressing the dmz interface into the dmz zone…In my mind this is not a firewall issue as the packets are being forwarded into the zone, as expected. the reality is there was a deny ip any any into newzone applied to the outside interface. I should not of seen these packets when running a capture on the dmz interface, correct? this caused me to spin my wheels on this for 1/2 a day till I noticed the acl in the outside_in section… soon as I removed the acl element from the outside_in, things worked.. That does sound strange. Just tried something similar on an ASA 5550 8.2(4) with no problems; the capture shows/doesn't show the expected packets fine. You didn't mention platform and version, which is always a good thing if you want people to test it on something similar. Can you recreate this on another pair of interfaces on the same box, i.e. not towards the dmz interface mentioned here? And can you recreate it on the same interface? -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https
Re: [c-nsp] ASA bug?
Hi David, i seen that after i sent the original email and took a chance no one would notice. the telnet command was using 443, not 80. I was trying them both and doing some copy/pasting from the terminal whilst putting the email together. my bad, sorry for the confusion. from a machine on the internet (the outside interface), the telnet x.x.x.x 443 was issued. the policy applied to the outside interface would of dropped this packet. the bug I'm reporting is we see what appears to be the dropped traffic egressing the dmz interface.we should not see this as it was dropped at the outside interface and should never of made it this far. even tho we see the capture indicating packets were being sent out onto the wire, this isn't the case. the target machine in that zone while running tcpdump does not see any packets arriving from the firewall for these connection attempts, hence the reason we don't see any reply acks. (no local OS firewalls running) hope that clears things. I have the text buffers from the entire terminal sessions, went over it again to make sure i wasn't making any silly mistakes. it seems like this was what was actually happening.. i'm going to see if i can test this same zone again as we won't go live with it for another week or so.. failing that I'll uncrate the other 5540 and do a verbatim config on it in an effort to reproduce. take care, greg On Jan 25, 2011, at 2:03 PM, David White, Jr. (dwhitejr) wrote: snip from an internet host I attempt a connection to port 80: ggw@76.65.229.23:~$ telnet x.x.x.x 80 I see the packets egress the newdmz interface: 1: 15:55:11.839525 802.1Q vlan#560 P0 x.x.x.x.2716 192.168.53.19.1433: . 3365025458:3365025459(1) ack 2402449091 win 64453 2: 15:55:11.840303 802.1Q vlan#560 P0 192.168.53.19.1433 x.x.x.x.2716: . ack 3365025459 win 64374 3: 15:55:12.070079 802.1Q vlan#560 P0 192.168.53.19.1433 x.x.x.x.2716: . 2402449090:2402449091(1) ack 3365025459 win 64374 4: 15:55:12.070202 802.1Q vlan#560 P0 x.x.x.x.2716 192.168.53.19.1433: . ack 2402449091 win 64453 5: 15:55:21.180608 76.65.229.23.61388 x.x.x.x.443: S 2533989180:2533989180(0) win 65535 mss 1260,nop,nop,sackOK 6: 15:55:24.070659 76.65.229.23.61388 x.x.x.x.443: S 2533989180:2533989180(0) win 65535 mss 1260,nop,nop,sackOK 7: 15:55:30.085978 76.65.229.23.61388 x.x.x.x.443: S 2533989180:2533989180(0) win 65535 mss 1260,nop,nop,sackOK I see packets egressing the dmz interface into the dmz zone…In my mind this is not a firewall issue as the packets are being forwarded into the zone, as expected. But the traffic you captured is NOT the telnet to port 80 session. Are you translating the port somewhere upstream before it reaches the ASA? Or are you translating on the ASA? the reality is there was a deny ip any any into newzone applied to the outside interface. If the 'deny' statement was applied inbound on the outside interface, and this was also where the connection was initiating from, then yes - traffic would have been denied. Note that if the telnet was initiated from the dmz interface, then the ACL would not have blocked it. Sincerely, David. I should not of seen these packets when running a capture on the dmz interface, correct? this caused me to spin my wheels on this for 1/2 a day till I noticed the acl in the outside_in section… soon as I removed the acl element from the outside_in, things worked.. am I not understanding something here or does this look wrong? thanks for your time, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] 6500 SUP720 datacenter setup
Its been awhile and things may of changed but as I recall, it can only handle up to 4Gbits of traffic total so that may be a bottle neck. you can run multiple context and in transparent mode, giving each customer an instance. I think you would be better off with an external solution, and aggregate if you need more bandwidth. FWSM is getting long in the tooth and I can't see it being around much longer unless there are huge improvements made in terms of the amount of traffic it can process. greg On Jan 23, 2011, at 2:34 PM, Lars Eidsheim wrote: I am looking for advice regarding a 6500 layout in a datacenter setup. The 6500 has SUP720-3B running 12.2(33) SXI4 Adv.IP Services. The initial design was to terminate and route customers on the 6500 using a unique VLAN for each customer and allocate a IP subnet for each VLAN. An issue about this solution is firewalling and we will need to firewall some customers. According to other threads the IOS firewalling feature is limited on the 6500 platform and should be avoided. A stateful portbased firewall using ACLs would be sufficient for our need if it would be the same as in router IOS. A quick solution would be to terminate all customers on a router, eg a 7200, which would do the job, but we would have all traffic routed over a single interface which would make the router a bottleneck. Another solution might be to use FWSM as a transparent firewall (see diagram below). I would prefer to terminate interfaces on the 6500 rather than on the FWSM in a routed setup. Vlan 200 (WAN 1) (x.y.z.1/30) | | .---. |6500 SUP720| '---' | | Vlan 100 (CUST A) (a.b.c.1/30) Vlan 101 (CUST B) (a.b.c.5/30) Vlan 102 (CUST C) (a.b.c.9/30) I would be happy to hear your thoughts and experience on the subject. Regards, Lars Eidsheim This email has been scanned and secured by Intellit This communication is for use by the intended recipient and contains information that may be privileged, confidential and exempt from disclosure or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any dissemination, use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. ___ 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/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] using BGP communitys with route-maps on ASR
Hello, I'm attempting to address a routing issue using route-maps and local-preferences. On Cisco's site and a few other sources i've found, the method is to specify the route map while in the BGP router config as such: ip community−list 1 permit :10 route−map THISWAY permit 10 match community 1 set local−preference 200 router bgp neighbour 192.168.1.2 remote-as neighbour 192.168.1.2 route-map THISWAY in I am working with an ASR1004 and the last line is not accepted. route-map is not an option for the neighbor attribute. INTERNETASR1(config-router)#neighbor 192.168.1.2 ? description Neighbor specific description disable-connected-check one-hop away EBGP peer using loopback address ebgp-multihopAllow EBGP neighbors not on directly connected networks fall-oversession fall on peer route lost ha-mode high availability mode inherit Inherit a template local-as Specify a local-as number password Set a password peer-group Member of the peer-group remote-asSpecify a BGP neighbor shutdown Administratively shut down this neighbor timers BGP per neighbor timers transportTransport options ttl-security BGP ttl security check update-sourceSource of routing updates version Set the BGP version to match a neighbor ASR1004(config-router)#neighbor 192.168.1.2 did something change or have i messed up somewhere? thanks for your time, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] using BGP communitys with route-maps on ASR
I did not, will it have the same affect? thanks for your time and help Viijay! -g On Jan 14, 2011, at 11:52 AM, Ramcharan, Vijay A wrote: Did you try applying policy under the address family in question? labrtr01(config)#router bgp 65001 labrtr01(config-router)#nei 1.1.1.1 ? description Neighbor specific description disable-connected-check one-hop away EBGP peer using loopback address ebgp-multihopAllow EBGP neighbors not on directly connected networks fall-oversession fall on peer route lost ha-mode high availability mode inherit Inherit a template local-as Specify a local-as number password Set a password peer-group Member of the peer-group remote-asSpecify a BGP neighbor shutdown Administratively shut down this neighbor timers BGP per neighbor timers transportTransport options ttl-security BGP ttl security check update-sourceSource of routing updates version Set the BGP version to match a neighbor labrtr01(config-router)#addr ipv4 labrtr01(config-router-af)#nei 1.1.1.1 ? activateEnable the Address Family for this Neighbor advertise-map specify route-map for conditional advertisement advertisement-interval Minimum interval between sending BGP routing updates allowas-in Accept as-path with my AS present in it capability Advertise capability to the peer default-originate Originate default route to this neighbor distribute-list Filter updates to/from this neighbor dmzlink-bw Propagate the DMZ link bandwidth filter-list Establish BGP filters inherit Inherit a template maximum-prefix Maximum number of prefixes accepted from this peer next-hop-self Disable the next hop calculation for this neighbor next-hop-unchanged Propagate next hop unchanged for iBGP paths to this neighbor prefix-list Filter updates to/from this neighbor remove-private-as Remove private AS number from outbound updates route-map Apply route map to neighbor route-reflector-client Configure a neighbor as Route Reflector client send-community Send Community attribute to this neighbor send-label Send NLRI + MPLS Label to this peer slow-peer Configure slow-peer soft-reconfigurationPer neighbor soft reconfiguration soo Site-of-Origin extended community translate-updateTranslate Update to MBGP format unsuppress-map Route-map to selectively unsuppress suppressed routes weight Set default weight for routes from this neighbor labrtr01(config-router-af)#nei 1.1.1.1 Vijay Ramcharan -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Greg Whynott Sent: Friday, January 14, 2011 11:37 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] using BGP communitys with route-maps on ASR Hello, I'm attempting to address a routing issue using route-maps and local- preferences. On Cisco's site and a few other sources i've found, the method is to specify the route map while in the BGP router config as such: ip community−list 1 permit :10 route−map THISWAY permit 10 match community 1 set local−preference 200 router bgp neighbour 192.168.1.2 remote-as neighbour 192.168.1.2 route-map THISWAY in I am working with an ASR1004 and the last line is not accepted. route-map is not an option for the neighbor attribute. INTERNETASR1(config-router)#neighbor 192.168.1.2 ? description Neighbor specific description disable-connected-check one-hop away EBGP peer using loopback address ebgp-multihopAllow EBGP neighbors not on directly connected networks fall-oversession fall on peer route lost ha-mode high availability mode inherit Inherit a template local-as Specify a local-as number password Set a password peer-group Member of the peer-group remote-asSpecify a BGP neighbor shutdown Administratively shut down this neighbor timers BGP per neighbor timers transportTransport options ttl-security BGP ttl security check update-sourceSource of routing updates version Set the BGP version to match a neighbor ASR1004(config-router)#neighbor 192.168.1.2 did something change or have i messed up somewhere? thanks for your time, greg -- This message and any attachments may
Re: [c-nsp] Catalyst 6509-E with dual supervisors, 6000W AC power supply with 120V inputs
the GE cards use about 325 watts each, sup720 @340watts, IDSM not sure probably about 300 too. if your power supplies produce 6000 watts each, you will be fine and be able to run in redundant power mode. I know of no issues running a 6500 at 120, aside from efficiency. -g On Jan 13, 2011, at 11:29 AM, Ramcharan, Vijay A wrote: Are there folks out there who have been forced to run their Catalyst 6500-E switches on 120V circuits? Other than the expected lower power output and the inability to fully populate the switches (depending on model), are there any issues with running on the 120V circuits? Expected configuration is as follows: 6509-E with dual VS-720-10G Supervisors 3 x 6748-GE-TX line cards 1 x IDSM2 2 x 6000W AC PS, each with dual 120V circuits According to Cisco's Power Calculator, the switch should be able to run in redundant power mode with the above configuration with less than 80% utilization on one power supply. Thank you for any feedback. Vijay Ramcharan ___ 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/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] local privilege level question
thanks Daniele, thats it! take care, greg On Jan 11, 2011, at 5:41 PM, Daniele Orlandi wrote: On Tuesday 11 January 2011 21:58:10 Greg Whynott wrote: hello, on an ASR1004 we have local accounts where the privilege level is set to 15. when I type 'en' it still asks for the enable password. is there away to prevent this behavior so that persons with local accounts/15 priv can execute level 15 commands without being prompted? we are not using any external sources for authentication, its all local. Hi Greg, Try enabling aaa authorization exec default local none because the privilege is assigned in authorization phase. Ciao, -- Daniele Vihai Orlandi Bieco Illuminista #184213 ___ 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/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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] local privilege level question
hello, on an ASR1004 we have local accounts where the privilege level is set to 15. when I type 'en' it still asks for the enable password. is there away to prevent this behavior so that persons with local accounts/15 priv can execute level 15 commands without being prompted? we are not using any external sources for authentication, its all local. thanks for your time, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. ___ 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/
