[c-nsp] UDLD ?
We have had a few strange unidirectional link problems and I thought that I could detect them using UDLD. So I thought I knew how it worked. I I have a 6500 with a gig SFP LH mod connected to a 3750 with the same SFP.I enabled UDLD AGGRESSIVE mode on bot ends and they both reported seeing each other as neighbors. So I thought that if I disconnected one of the fibers that the UDLD would detect the unidirectional transition but instead both ends just reported link down. I thought that breaking on side of the fiber would only bring down one end LINK since the other still thought it was connected. I then disabled the UDLD and disconnect the fiber again and still had both ends show link failure. Q So why does both ends go down? Is this a new code feature for gig fiber ports or did I miss something? Jeff Fitzwater OIT Network Systems Princeton University ___ 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] WS-X6724+CFC and ES20 line cards
On Tue, 30 Jun 2009 17:49:05 +0400, nishal goburdhan nis...@is.co.za wrote: On Thu, Jun 25, 2009 at 08:20:26PM +0400, victor wrote: Even more than that :) because the design was verified, simulated and approved by a Cisco Systems lab in Raleigh (NC) Insubordination regarding this matter may result in an unpleasant conversation with my boss. I should probably insist on ordering ES20 :))) as a note, if you *are* thinking of ordering ES20 cards, don't. get the ES20+ cards instead. Do you mean 7600-ES+20G3C? I think it's just a next generation of 7600-ES20-GE3C. Please, explain. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ 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] UDLD ?
On Tue, 2009-06-30 at 09:59 -0400, Jeff Fitzwater wrote: We have had a few strange unidirectional link problems and I thought that I could detect them using UDLD. So I thought I knew how it worked. I ... I thought that breaking on side of the fiber would only bring down one end LINK since the other still thought it was connected. I then disabled the UDLD and disconnect the fiber again and still had both ends show link failure. Just tried this between a 3560 12.2(35)SE5 and a 2970 12.2(25)SEC2 with the same symptoms as you describe; disconnecting one fiber doesn't trigger UDLD but does give link down in both ends. This is also contrary to what I expected. UDLD is useful in another case though: Media converters and EoMPLS xconnected ports are transparent to UDLD but might not have link poisoning enabled. With UDLD you would discover the loss of connectivity to the neighbor even though the link doesn't go down. As long as the link actually goes down the UDLD isn't needed anyway. :-) Regards, Peter ___ 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] UDLD ?
I then disabled the UDLD and disconnect the fiber again and still had both ends show link failure. Q So why does both ends go down? Is this a new code feature for gig fiber ports or did I miss something? Are the ports set to auto? Auto-neg will notice one-way link, and not bring up the link. Tim: ___ 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] UDLD ?
On Tue, Jun 30, 2009 at 09:59:35AM -0400, Jeff Fitzwater wrote: Q So why does both ends go down? Is this a new code feature for gig fiber ports or did I miss something? GigE autonegotiation reports remote-fault to the other end. M. ___ 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] UDLD ?
GE/10G can detect a physical unidirectional fiber link itself, UDLD is not necessary to detect this type of failure. UDLD is needed for exactly the case you mention, or for cases where one side of the link is braindead but does not bring the physical link down (ie, software problem). HTH, Tim At 07:57 AM 6/30/2009, Peter Rathlev stated: On Tue, 2009-06-30 at 09:59 -0400, Jeff Fitzwater wrote: We have had a few strange unidirectional link problems and I thought that I could detect them using UDLD. So I thought I knew how it worked. I ... I thought that breaking on side of the fiber would only bring down one end LINK since the other still thought it was connected. I then disabled the UDLD and disconnect the fiber again and still had both ends show link failure. Just tried this between a 3560 12.2(35)SE5 and a 2970 12.2(25)SEC2 with the same symptoms as you describe; disconnecting one fiber doesn't trigger UDLD but does give link down in both ends. This is also contrary to what I expected. UDLD is useful in another case though: Media converters and EoMPLS xconnected ports are transparent to UDLD but might not have link poisoning enabled. With UDLD you would discover the loss of connectivity to the neighbor even though the link doesn't go down. As long as the link actually goes down the UDLD isn't needed anyway. :-) Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] UDLD ?
Thanks all for the info on UDLD. In my case the test did not work as expected because the port was in auto-negotiate, as it should be. Disabling it allowed the port to stay up even if the other end was down (no light). Enabling the UDLD worked as I would expect in this case. But in the end the auto should be enabled and the UDLD will detect converter issues or patch panel issues. The one thing I am curious about is, what happens if the other end is not CISCO but the next hop L2 is. Does the UDLD packet (01-00-0C-CC- CC-CC) pass thru? ( I would say yes). I would guess this could cause strange link failures and is why UDLD is not on by default. The best reference for UDLD is the rfc 5171 Jeff On Jun 30, 2009, at 11:25 AM, Tim Stevenson wrote: GE/10G can detect a physical unidirectional fiber link itself, UDLD is not necessary to detect this type of failure. UDLD is needed for exactly the case you mention, or for cases where one side of the link is braindead but does not bring the physical link down (ie, software problem). HTH, Tim At 07:57 AM 6/30/2009, Peter Rathlev stated: On Tue, 2009-06-30 at 09:59 -0400, Jeff Fitzwater wrote: We have had a few strange unidirectional link problems and I thought that I could detect them using UDLD. So I thought I knew how it worked. I ... I thought that breaking on side of the fiber would only bring down one end LINK since the other still thought it was connected. I then disabled the UDLD and disconnect the fiber again and still had both ends show link failure. Just tried this between a 3560 12.2(35)SE5 and a 2970 12.2(25)SEC2 with the same symptoms as you describe; disconnecting one fiber doesn't trigger UDLD but does give link down in both ends. This is also contrary to what I expected. UDLD is useful in another case though: Media converters and EoMPLS xconnected ports are transparent to UDLD but might not have link poisoning enabled. With UDLD you would discover the loss of connectivity to the neighbor even though the link doesn't go down. As long as the link actually goes down the UDLD isn't needed anyway. :-) Regards, Peter ___ 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/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] WS-X6724+CFC and ES20 line cards
On Tue, 30 Jun 2009 18:56:17 +0400, victor vi...@list.ru wrote: On Tue, 30 Jun 2009 17:49:05 +0400, nishal goburdhan nis...@is.co.za wrote: On Thu, Jun 25, 2009 at 08:20:26PM +0400, victor wrote: Even more than that :) because the design was verified, simulated and approved by a Cisco Systems lab in Raleigh (NC) Insubordination regarding this matter may result in an unpleasant conversation with my boss. I should probably insist on ordering ES20 :))) as a note, if you *are* thinking of ordering ES20 cards, don't. get the ES20+ cards instead. Do you mean 7600-ES+20G3C? I think it's just a next generation of 7600-ES20-GE3C. Please, explain. He-he. Didn't notice the period after don't. For me it was don't get the ES20+ cards instead. :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ 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] tacacs+ an nexus 5010
Hi all. Can someone help me out here. I'm having trouble getting tacacs+ to work an a nexus 5010. When ever I'm trying to access the nexus the debug prints.: Skipping DEAD TACACS+ server 10.0.100.233 I can ping and telnet to the tac-server from the nexus. Am I missiing somthing in my config ?? my conf. vrf context management ip name-server 10.2.4.63 10.2.4.64 10.2.4.65 ip host aasnxu1 10.2.8.14 ip host helios 10.0.100.233 tacacs-server key 7 x tacacs-server host 10.0.100.233 aaa group server tacacs+ REG_TAC server 10.0.100.233 deadtime 5 use-vrf management aaa authentication login default group REG_TAC aaa authentication login error-enable tacacs-server directed-request vrf context management ip route 0.0.0.0/0 10.2.8.1 aasnxu1# sh tacacs-server Global TACACS+ shared secret: timeout value:5 deadtime value:0 total number of servers:1 following TACACS+ servers are configured: 10.0.100.233: available on port:49 following TACACS+ server groups are configured: group REG_TAC: server 10.0.100.233 on port 49 deadtime is 5 vrf is management /Arne ___ 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] Fun with interface counters.
I assume this is either a bug, or something else equally enjoyable. Today, I noticed that one of our switches was acting up, so I logged into it and did the usual show interfaces, sh proc cpu sort, etc etc. I noticed that the switch's uplink interface indicated that it was doing 700Mbps to the router it is connected to, the router indicated that it was only getting 200Mbps from the switch. So either there is a counter bug, or the switch was sending traffic that was being dropped by the router or dropped later by the switch (after it was counted?), or something else equally amusing? Does anyone have any thoughts on this/seen this before? Thanks! ___ 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] Fun with interface counters.
On Tue, 30 Jun 2009, Drew Weaver wrote: I noticed that the switch's uplink interface indicated that it was doing 700Mbps to the router it is connected to, the router indicated that it was only getting 200Mbps from the switch. I've seen similar discrepancies with 3550s gigabit uplinked to 6509s, just not enough times or long lasting enough to spend any time investigating. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] MPLS/BGP - want to add backup IPSEC VPN
I have a few MPLS routers running BGP as the routing protocol. I added a public IP'ed interface on a free ports on the same router, and I'm able to get to it and use it for Internet bound traffic if I wish. I would like to configure an IPSEC VPN to provide backup if the MPLS provider fails. I'm having a hard time with Cisco TAC on this, mainly them getting back to me. dumb'ed down diagram is at: http://chrisserafin.com/design.jpg I just want a basic split tunnel VPN in the event the primary MPLS/BGP link goes down. I'm assuming let BGP take care of the MPLS side and add static routes with a very high weight for the VPN failover? All comments welcome...looking for help on this. --chris ___ 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] Non export of netflow of dscp bits from PCF3A
We use Fluke's Netflow Tracker for netflow analysis. I've run into a weird one though. Our netflow export from our distribution switches which are running 12.2(33)SXI1 does not seem to export the dscp bits, but our core switches running 12.2(33)SXI1 as well, do export the dscp bits. The difference is the distribution switch is a PFC3A where the core switches are PFC3Bs. Anyone seen this issue before? I've verified that the netflow configurations are identical, and that the packets do have the attributes set as they pass throught he distribution. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 ___ 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] OT: Help on Cisco ITP Configuration Guide - 12.4(11)SW3
Hello, I am trying to download the Cisco ITP configuration guide for the * 12.4(11)SW3* software release. The file can be seen in the ITP configuration guides list http://www.cisco.com/en/US/products/sw/wirelssw/ps1862/products_feature_guides_list.html . Unfortunately, it keeps on prompting me for a CCO login. I have provided several valid CCO credentials (some with service contract privileges), but the file cannot be obtained. I would appreciate if you could help me obtain this file. I am migrating the configuration on some Cisco ITPs with 12.2(33)IRC, but it appears Cisco has changed the command syntax altogether on the new platform. The popular *cs7* commands are no longer recognized. Your urgent assistance is deeply appreciated. Felix ___ 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] Fun with interface counters.
Trunk port or access port? One of the main places I've seen mismatching amounts of tx/rx is on trunk ports, where either the switchport trunk allowed vlan doesn't match on both sides, or in the case of the router interface, you only have .1Q subinterfaces configured for certain VLANs, but other VLANs are flooding across the link. -Geoff On Tue, Jun 30, 2009 at 4:59 PM, Drew Weaverdrew.wea...@thenap.com wrote: I assume this is either a bug, or something else equally enjoyable. Today, I noticed that one of our switches was acting up, so I logged into it and did the usual show interfaces, sh proc cpu sort, etc etc. I noticed that the switch's uplink interface indicated that it was doing 700Mbps to the router it is connected to, the router indicated that it was only getting 200Mbps from the switch. So either there is a counter bug, or the switch was sending traffic that was being dropped by the router or dropped later by the switch (after it was counted?), or something else equally amusing? Does anyone have any thoughts on this/seen this before? Thanks! ___ cisco-nsp mailing list cisco-...@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] using a /29 mask on a /30 point-to-point
I have a new ISP for one of our locations, and we currently have a pair of Cisco PIXs in an active/standby config. The new ISP wants to give us a /30 for this MetroE WAN link, with one of the IPs being used for their equipment on their side of the circuit (aka, our default gateway). This only gives us one IP address for our Primary's external interface, and none left over for the secondary firewall's external int (which it requires to be in the same subnet as Primary's ext int). The ISP refuses to issue a /29 instead, due a corp policy stemming from a mis-configured customer many years ago. What are my options to get this to work? I really don't want to lose my redundant firewalls, and adding a router (a single point of failure) to just get redundant firewalls seems self-defeating. Could I configure the subnet on my side of the WAN as a /29? My broadcast address would be wrong, but since its basically a point-to-point anyway, I shouldn't need broadcasts. I realize this is semi-evil, and might get my Internet drivers license revoked, but what would I break by doing this? -- deny ip any any (4393649193 matches) ___ 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, FWSM
By any chance does anybody here know the new terminology used for ASA and FWSM? Renelson ___ 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 a /29 mask on a /30 point-to-point
Hi, On Tue, Jun 30, 2009 at 03:44:35PM -0400, Deny IP Any Any wrote: What are my options to get this to work? Change ISPs. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpLxIVsARtLh.pgp Description: PGP signature ___ 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 a /29 mask on a /30 point-to-point
If switching ISPs is not a choice, although I agree it is a good one, then I need a little more information. Are you running PIX's that are pre 7.x or 6.3(5)? I have not tried this before on the 6.3(5) line, but you might be able to leave off this line: failover ip address outside x.x.x.x If you're using 7.x +, you can leave off the standby command. As long as you're monitoring and accessing the device from the inside of your network, you can get by with the single address on the outside. -ryan -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, June 30, 2009 4:46 PM To: Deny IP Any Any Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] using a /29 mask on a /30 point-to-point Hi, On Tue, Jun 30, 2009 at 03:44:35PM -0400, Deny IP Any Any wrote: What are my options to get this to work? Change ISPs. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ 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] OT: Help on Cisco ITP Configuration Guide - 12.4(11)SW3
Same here... -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Randy Sent: Tuesday, June 30, 2009 4:02 PM To: cisco-nsp@puck.nether.net; Felix Nkansah Subject: Re: [c-nsp] OT: Help on Cisco ITP Configuration Guide - 12.4(11)SW3 --- On Tue, 6/30/09, Felix Nkansah felixnkan...@gmail.com wrote: From: Felix Nkansah felixnkan...@gmail.com Subject: [c-nsp] OT: Help on Cisco ITP Configuration Guide - 12.4(11)SW3 To: cisco-nsp@puck.nether.net Date: Tuesday, June 30, 2009, 12:54 PM Hello, I am trying to download the Cisco ITP configuration guide for the * 12.4(11)SW3* software release. The file can be seen in the ITP configuration guides list http://www.cisco.com/en/US/products/sw/wirelssw/ps1862/products_feature_guides_list.html . Unfortunately, it keeps on prompting me for a CCO login. I have provided several valid CCO credentials (some with service contract privileges), but the file cannot be obtained. I would appreciate if you could help me obtain this file. I am migrating the configuration on some Cisco ITPs with 12.2(33)IRC, but it appears Cisco has changed the command syntax altogether on the new platform. The popular *cs7* commands are no longer recognized. Your urgent assistance is deeply appreciated. Felix ___ 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/ ...tried but I keep getting prompted for my cco login as well. -Randy ___ 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] OT: Help on Cisco ITP Configuration Guide - 12.4(11)SW3
At the location below there is a file called Access to Cisco IP Transfer Point (ITP) User Documentation and Release Notes, which contains the following text: Cisco restricts the use and distribution of Cisco IP Transfer Point (ITP) user documentation and release notes. If you desire access and are a current or prospective Cisco ITP customer or a Cisco employee, please e-mail: itp-user-doc-requ...@cisco.com with your Cisco.com user ID. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Felix Nkansah Sent: Tuesday, June 30, 2009 22:54 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OT: Help on Cisco ITP Configuration Guide - 12.4(11)SW3 Hello, I am trying to download the Cisco ITP configuration guide for the * 12.4(11)SW3* software release. The file can be seen in the ITP configuration guides list http://www.cisco.com/en/US/products/sw/wirelssw/ps1862/products_feature_ guides_list.html . Unfortunately, it keeps on prompting me for a CCO login. I have provided several valid CCO credentials (some with service contract privileges), but the file cannot be obtained. I would appreciate if you could help me obtain this file. I am migrating the configuration on some Cisco ITPs with 12.2(33)IRC, but it appears Cisco has changed the command syntax altogether on the new platform. The popular *cs7* commands are no longer recognized. Your urgent assistance is deeply appreciated. Felix ___ 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] SNMP query to get status of a bgp peer in a vrf
Hi, I've spent some time already trying to locate the mib that has the status (and admin status) of bgp peer that is in a vrf. There is cbgpPeerPrevState oid but it only seems to cover ipv4 peers (at least when I query the ASRs we try to monitor). I can get the number of prefixes learnt from a peer using cbgpPeerAcceptedPrefixes oid, but not the status. Any ideas if it's possible at all? And if so - which MIB contains that information? kind regads Pshem ___ 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 a /29 mask on a /30 point-to-point
I am not sure exactly how you are trying to configure the PIX, but I guess you need to have an IP for each PIX, and then a VIP in the same subnet used for real traffic forwarding. You can tell your SP to use /30, so for example, they allocate 192.168.1.1 for their side, and 192.168.1.2 for your side. You can configure on your devices a /28 subnet, allocating PIX #1 192.168.1.4/28, and PIX #2 192.168.1.5/28, then configure the VIP to be 192.168.1.2, as you SP is expecting you to do... Set your default gateway to point at 192.168.1.1, and you are done. The only caveat I see is that if for some reason you would need to reach the other (public) IP's on the /28 you have abused, you won't be able to reach it... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Deny IP Any Any Sent: Tuesday, June 30, 2009 22:45 To: cisco-nsp@puck.nether.net Subject: [c-nsp] using a /29 mask on a /30 point-to-point I have a new ISP for one of our locations, and we currently have a pair of Cisco PIXs in an active/standby config. The new ISP wants to give us a /30 for this MetroE WAN link, with one of the IPs being used for their equipment on their side of the circuit (aka, our default gateway). This only gives us one IP address for our Primary's external interface, and none left over for the secondary firewall's external int (which it requires to be in the same subnet as Primary's ext int). The ISP refuses to issue a /29 instead, due a corp policy stemming from a mis-configured customer many years ago. What are my options to get this to work? I really don't want to lose my redundant firewalls, and adding a router (a single point of failure) to just get redundant firewalls seems self-defeating. Could I configure the subnet on my side of the WAN as a /29? My broadcast address would be wrong, but since its basically a point-to-point anyway, I shouldn't need broadcasts. I realize this is semi-evil, and might get my Internet drivers license revoked, but what would I break by doing this? -- deny ip any any (4393649193 matches) ___ 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] Fw: Data Centre Best pratices
Would anyone like to have a stab at this Hi, I am at the beginning of building a best practices document for data centre design. I am wondering if anyone can poiunt me to the right document that I can start with. I am looking at a Cisco centric solution. Following documents are currently being looked at. http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_Infra2_5/DCI_SRND_2_5_book.html http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd804be7e2_ps2706_Products_White_Paper.html Any pointers and help would be highly appreciated. Thanks in advance. Shine ___ 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] MPLS/BGP - want to add backup IPSEC VPN
On Tue, 2009-06-30 at 14:11 -0500, ChrisSerafin wrote: I have a few MPLS routers running BGP as the routing protocol. I added a public IP'ed interface on a free ports on the same router, and I'm able to get to it and use it for Internet bound traffic if I wish. I would like to configure an IPSEC VPN to provide backup if the MPLS provider fails. I'm having a hard time with Cisco TAC on this, mainly them getting back to me. dumb'ed down diagram is at: http://chrisserafin.com/design.jpg I just want a basic split tunnel VPN in the event the primary MPLS/BGP link goes down. I'm assuming let BGP take care of the MPLS side and add static routes with a very high weight for the VPN failover? And the VPN-link needs to carry MPLS traffic too? MPLSoGRE could be an option, but support is very limited AFAIK. Otherwise some extra equipment doing L2TPv3 might work. Performance limitations might very well rule this out. If MPLS isn't needed a simple GRE tunnel would of course do. You could even create a new tunnel per VRF if you need reachability in several of these. It scales bad concerning administration though. Regards, Peter ___ 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] Fun with interface counters.
Drew Weaver wrote: I assume this is either a bug, or something else equally enjoyable. Today, I noticed that one of our switches was acting up, so I logged into it and did the usual show interfaces, sh proc cpu sort, etc etc. I noticed that the switch's uplink interface indicated that it was doing 700Mbps to the router it is connected to, the router indicated that it was only getting 200Mbps from the switch. So either there is a counter bug, or the switch was sending traffic that was being dropped by the router or dropped later by the switch (after it was counted?), or something else equally amusing? Does anyone have any thoughts on this/seen this before? The default interval for updating the counters is five minutes. If the traffic is bursty it isn't unusual for the interface counters to disagree, sometimes substantially. I believe that the load interval timer starts on boot or when counters are cleared on the interface so don't expect them to line up with NTP. For faster response and better granularity you can use the load-interval [seconds] interface-level command. Minimum supported value is 30 seconds. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ 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] tacacs+ an nexus 5010
On Tue Jun 30 13:47 , Arne Larsen / Region Nordjylland sent: Hi all. Can someone help me out here. I'm having trouble getting tacacs+ to work an a nexus 5010. When ever I'm trying to access the nexus the debug prints.: Skipping DEAD TACACS+ server 10.0.100.233 I can ping and telnet to the tac-server from the nexus. Am I missiing somthing in my config ?? my conf. vrf context management ip name-server 10.2.4.63 10.2.4.64 10.2.4.65 ip host aasnxu1 10.2.8.14 ip host helios 10.0.100.233 tacacs-server key 7 x tacacs-server host 10.0.100.233 aaa group server tacacs+ REG_TAC server 10.0.100.233 deadtime 5 use-vrf management aaa authentication login default group REG_TAC aaa authentication login error-enable tacacs-server directed-request vrf context management ip route 0.0.0.0/0 10.2.8.1 aasnxu1# sh tacacs-server Global TACACS+ shared secret: timeout value:5 deadtime value:0 total number of servers:1 following TACACS+ servers are configured: 10.0.100.233: available on port:49 following TACACS+ server groups are configured: group REG_TAC: server 10.0.100.233 on port 49 deadtime is 5 vrf is management Is there a chance you have a mismatch TACACS key? -chris ___ 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 a /29 mask on a /30 point-to-point
--- On Tue, 6/30/09, Deny IP Any Any denyipany...@gmail.com wrote: From: Deny IP Any Any denyipany...@gmail.com Subject: [c-nsp] using a /29 mask on a /30 point-to-point To: cisco-nsp@puck.nether.net Date: Tuesday, June 30, 2009, 12:44 PM I have a new ISP for one of our locations, and we currently have a pair of Cisco PIXs in an active/standby config. The new ISP wants to give us a /30 for this MetroE WAN link, with one of the IPs being used for their equipment on their side of the circuit (aka, our default gateway). This only gives us one IP address for our Primary's external interface, and none left over for the secondary firewall's external int (which it requires to be in the same subnet as Primary's ext int). The ISP refuses to issue a /29 instead, due a corp policy stemming from a mis-configured customer many years ago. What are my options to get this to work? I really don't want to lose my redundant firewalls, and adding a router (a single point of failure) to just get redundant firewalls seems self-defeating. Could I configure the subnet on my side of the WAN as a /29? My broadcast address would be wrong, but since its basically a point-to-point anyway, I shouldn't need broadcasts. I realize this is semi-evil, and might get my Internet drivers license revoked, but what would I break by doing this? -- deny ip any any (4393649193 matches) ___ 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/ ...well for one thing, in the event the active pix died, the standby would source outbound PAT'd traffic from an address that doesn't belong to you. I agree with gert - change ISP's -Randy ___ 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] Fw: Data Centre Best pratices
Hello: Hi, I am at the beginning of building a best practices document for data centre design. I am wondering if anyone can poiunt me to the right document that I can start with. I am looking at a Cisco centric solution. Following documents are currently being looked at. Not Cisco-specific, but I would check out The Uptime Institute. They have a wealth of information about Data Center design. http://www.uptimeinstitute.org Regards, Mike ___ 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] RES: Fun with interface counters.
Are both interfaces configured with 'load-interval 30'? Furthermore that could be due to lack of 64-bit interface counter support on the router. -Mensagem original- De: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] Em nome de Drew Weaver Enviada em: terça-feira, 30 de junho de 2009 18:59 Para: 'cisco-nsp@puck.nether.net' Assunto: [c-nsp] Fun with interface counters. I assume this is either a bug, or something else equally enjoyable. Today, I noticed that one of our switches was acting up, so I logged into it and did the usual show interfaces, sh proc cpu sort, etc etc. I noticed that the switch's uplink interface indicated that it was doing 700Mbps to the router it is connected to, the router indicated that it was only getting 200Mbps from the switch. So either there is a counter bug, or the switch was sending traffic that was being dropped by the router or dropped later by the switch (after it was counted?), or something else equally amusing? Does anyone have any thoughts on this/seen this before? Thanks! ___ 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] Fw: Data Centre Best pratices
Data center best practices? Are you a content house? Are you an ISP? Are you a colo provider? Given that there are multiple best practices for those scenarios alone not to mention if you are a content house your network is built to support your application... that's one hell of a long paper you are writing. Don't forget to add the EU/US differences... Why not just publish a book? Second, and not to be rude, but if you don't know where to find necessary starting points for a document of this nature, are you sure you are the best person to be writing it? On Jun 30, 2009, at 2:47 PM, Shine Joseph wrote: Would anyone like to have a stab at this Hi, I am at the beginning of building a best practices document for data centre design. I am wondering if anyone can poiunt me to the right document that I can start with. I am looking at a Cisco centric solution. Following documents are currently being looked at. http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_Infra2_5/DCI_SRND_2_5_book.html http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd804be7e2_ps2706_Products_White_Paper.html Any pointers and help would be highly appreciated. Thanks in advance. Shine ___ 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/
[c-nsp] OT: Best Online Antispam Service
Hi Team, I am interested in subscribing to a GOOD online email filtering service, through which all emails destined to an enterprise domain transit, are scanned and filtered for spam and viruses, before legitimate mails relayed to the destination mail server. As a bonus, the service should also store emails for some time if the destination mail server is down. Much as IronPort and Barracuda appliances do a good antispam job, they are typically placed onsite for which reason the network bandwidth still gets chocked with arriving spam. Please share your experienced recommendations with me on this one. It's better for me than following google search. Felix ___ 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] RES: Fun with interface counters.
On Tue, 30 Jun 2009, Leonardo Gama Souza wrote: Are both interfaces configured with 'load-interval 30'? In my case yes. Furthermore that could be due to lack of 64-bit interface counter support on the router. I've seen that via SNMP, but never noticed the CLI interface rate counters having such issues. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Conditional BGP w/ multiple non-exist prefixes - bug?
Hi Matt, Interesting, I was unaware that conditional adv didn't support route-maps with the continue-clause. I don't have boxes handy to try it but what if you were to have two sequences in you non-exist route map - route-map non-exist permit 5 match ip-address prefix-list A route-map non-exist permit 10 match ip-address prefix-list B (the advertise route map still has only one seq.) during the non-exist eval process, if there is a hit against seq 5, you break out of the route-map. Conversely if there isn't a hit against 5, 10 would be evaluated - if a hit break out, if no hits, still break out. -Randy --- On Mon, 6/29/09, Matt Carter m...@iseek.com.au wrote: From: Matt Carter m...@iseek.com.au Subject: RE: [c-nsp] Conditional BGP w/ multiple non-exist prefixes - bug? To: 'Randy' randy_94...@yahoo.com, Cisco Mailing list cisco-nsp@puck.nether.net Date: Monday, June 29, 2009, 9:45 PM Hi Randy, Thank you for your speedy reply :) It was my first choice to use the continue clause and regular fall-through but despite the fact there is nothing listed under the Restrictions for BGP Route-Map continue, it appears unsupported by the Conditional BGP feature. Can configure the route-map just fine, but when Conditional BGP comes along you will get % conditional-nonexist used as BGP condition route-map, continue match not supported :( I have worked out that basically if I try to OR the prefixes in a route-map sub block, only the first prefix list will be evaluated ie if we have prefix list A before prefix list B route-map FOO match ip address prefix A B and then use that as a non-exist map for conditional BGP; - removal of A from BGP table will trigger state change - removal of B from BGP table will not do anything if you reverse the positioning in the route-map sub block such that B is before A route-map FOO match ip address prefix B A i then get reversed behaviour for conditional BGP - removal of A from BGP table will do nothing - removal of B from BGP table will trigger state change which is an aweful lot like the behaviour i was getting when i had two completely separate conditional BGP setups and only the first one that is entered appears to work, reversing the order they are entered reverses which one works and which one doesnt. strange. a version of IOS that supports route-maps with the *continue* clause will more that likely work for you. see BGP Route-map Continue Regards, ./Randy ...I haven't tried this but a regular fall-through route-map should be able to accomplish this as well. Your non-exist routemap( for the corresponding advertise-map) will have two sequences. eg: route-map non-exist 5 match ip-addr prefix-list a match as-path 1 route-map non-exist 10 match ip addr prefix-list b match as-path 2 ip prefix-list a permit 172.27.100.0/22 ip prefix-list b permit 172.28.0.0/23 ip as-path access-list 1 permit ^65420 ip as-path access-list 2 permit _65534$ (addresses and ASN's used in example are *private*) Regards, ./Randy ___ 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] Question about Cisco PIX VPN
Hi all, I'm configuring a PIX 501 running v6.3.5 code to terminate VPN connections from remote users. I've got the config intact, but need to learn how the PIX handles these connections internally. Here's the relevant config: access-list nonatvpn permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0 ip pool vpnswclient 192.168.1.2-192.168.1.254 nat (inside) 0 access-list nonatvpn and I've got vpngroups defined per-user to pull from the vpnswclient pool and split-tunnel based on the nonatvpn acl. So my inside network is 192.168.0.0/24, and the vpnclients will get addressed into 192.168.1.0/24 (correct?), and there will be no NAT on communication between them. My question is, are my vpn clients in the same broadcast domain as my inside interface, or will they be required to unicast to 192.168.0.x addresses? Is there a way to influence how they can communicate? I've been looking all over Cisco's website and can find plenty of configuration examples, but nothing explaining how communication between the inside and vpn clients is handled. -- Jared Gillis - ja...@corp.sonic.net Sonic.net, Inc. Network Operations2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.3400 (Support)http://www.sonic.net/ ___ 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 a /29 mask on a /30 point-to-point
On Tue, 2009-06-30 at 15:44 -0400, Deny IP Any Any wrote: Could I configure the subnet on my side of the WAN as a /29? My broadcast address would be wrong, but since its basically a point-to-point anyway, I shouldn't need broadcasts. I realize this is semi-evil, and might get my Internet drivers license revoked, but what would I break by doing this? To clear up: The PIX uses only two addresses, one for the active unit and one for the standby unit. The address for the standby unit is only used to reach the standby when the primary is still active/live. Upon failover the standby unit becomes active and takes over the IP adress of the former active. Every NAT/PAT is carried over statefully between the pair. A failover is pratically invisible for neighbors. If you couldn't change ISP and absolutely _had_ to do something that would almost certainly make your successor hate you, then you _could_ configure the PIX with a /29 mask where the addressing is thus: - PIX primary address is your side of the ISP assigned /30 - PIX secondary address is one of the broadcast addresses from the ISP assigned /30 (the one that is a valid host address in the /29) - Insert a static /30 route for the other part of the /29. Example, if the ISP assigned 10.0.0.0/30 for your link and took 10.0.0.1 for themselves (in v7+ format): ! *** pix *** interface GigabitEthernet0/0 nameif outside security-level 0 ip address 10.0.0.2 255.255.255.248 standby 10.0.0.3 ! route outside 10.0.0.4 255.255.255.252 10.0.0.1 ! Please just change ISP. :-) Regards, Peter ___ 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] Question about Cisco PIX VPN
On Tue, 2009-06-30 at 16:56 -0700, Jared Gillis wrote: So my inside network is 192.168.0.0/24, and the vpnclients will get addressed into 192.168.1.0/24 (correct?), and there will be no NAT on communication between them. Correct, your nat (inside) 0 acccess-list nonatvpn My question is, are my vpn clients in the same broadcast domain as my inside interface, or will they be required to unicast to 192.168.0.x addresses? Is there a way to influence how they can communicate? No, they're not in the same broadcast domain. The PIX sort of terminates the clients on the outside interface. Ex: assigned IP addresses must be routed to the outside. With the sysopt connection permit-ipsec you implicitly allow all traffic from VPN users. Alternatively you open up your outside ACL to permit relevant traffic. PIX/ASA v7 and newer have the vpn-filter feature for fine grained control of what VPN users can and cannot reach. I've been looking all over Cisco's website and can find plenty of configuration examples, but nothing explaining how communication between the inside and vpn clients is handled. Product support lists some configuration examples that might be of interest: http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2030/prod_configuration_examples_list.html Regards, Peter ___ 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 a /29 mask on a /30 point-to-point
Using Peter's example below, just leave off the 10.0.0.3 standby address. The failover and state information will still be passed between the firewalls and you can get by with a /30. If for some reason you're running 6.3(5), go to Kingston.com and buy yourself 2 sets of (2) 64MB CL2 100Mhz low profile DRAM and upgrade to 7.x. 6.3 code is a disaster to troubleshoot. -ryan Example, if the ISP assigned 10.0.0.0/30 for your link and took 10.0.0.1 for themselves (in v7+ format): ! *** pix *** interface GigabitEthernet0/0 nameif outside security-level 0 ip address 10.0.0.2 255.255.255.248 standby 10.0.0.3 ! route outside 10.0.0.4 255.255.255.252 10.0.0.1 ! Please just change ISP. :-) Regards, Peter ___ 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] ASA, FWSM
On Tue, 30 Jun 2009, Renelson Panosky wrote: By any chance does anybody here know the new terminology used for ASA and FWSM? Could you clarify what you mean by new terminology? Thanks 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/
Re: [c-nsp] ASA, FWSM
I don't think it is virtual context? There are some limiltations Regards -mike On Jun 30, 2009, at 6:23 PM, Justin M. Streiner strei...@cluebyfour.org wrote: On Tue, 30 Jun 2009, Renelson Panosky wrote: By any chance does anybody here know the new terminology used for ASA and FWSM? Could you clarify what you mean by new terminology? Thanks 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] DNS rewrite global capabilities
These claims depend on the level of attack. Firewalls do have features, for instance, they can proxy a tcp-syn connection and not send it to the server if it doesn't get an ack. If the firewall can sustain the attack, and the server doesn't have syn-cookies, this would be a mitigation of a ddos by the firewall. Also they obviously block traffic, which is a security benefit. Also, what if the attack has spoofed source addresses, and is evasive of profiling. In other words, what are you going to null route. The ingress path of the attack packets would have to be traced and cut off at the border of upstream providers, killing legit traffic as well. While the real sources are hunted down, this would be the effort to mitigate the attack. An advanced firewall or load balancer (that multiplex's the connections) would be able to mitigate this attack. So to me, it doesn't look like a one thing fits solution. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Roland Dobbins Sent: Monday, June 29, 2009 10:17 AM To: Cisco-nsp Subject: Re: [c-nsp] DNS rewrite global capabilities On Jun 29, 2009, at 8:33 PM, Jonathan Brashear wrote: t seems like the ability to rewrite DNS against certain DDoS attacks Marketing claims aside, firewalls have no utility whatsoever in terms of defending against DDoS attacks, and actually tend to make the situation worse and the server behind them *more* vulnerable to DDoS, and not less, due to the limitations of the stateful capacity they embody. You'd be far better off using S/RTBH as a reaction tool, and depending upon your application and its importance/scale, may wish to investigate other tools intended to protect firewalls and the things behind them from DDoS (full disclosure; I work for a company which makes such tools). But even more than that, putting your public-facing DNS (or any other kind of server) behind a firewall is a very serious architectural mistake; firewalls in front of public-facing servers provide no security value whatsoever, and degrade the overall security posture due to the issues denoted above. Far, far better to bring your public- facing DNS servers out from behind the firewall, employ all the various host- and application-/service-specific BCPs, ensure your DNS architecture is properly designed and scaled, and make use of S/RTBH, et. al. to deal with DDoS. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Unfortunately, inefficiency scales really well. -- Kevin Lawton ___ 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] DNS rewrite global capabilities
On Jul 1, 2009, at 11:02 AM, Quinn Mahoney wrote: irewalls do have features, for instance, they can proxy a tcp-syn connection and not send it to the server if it doesn't get an ack. Doesn't scale. Server alone handle this much better, even without syn- cookies. Also they obviously block traffic, which is a security benefit. So do stateless ACLs in hardware - much more efficiently. Also, what if the attack has spoofed source addresses, and is evasive of profiling. In other words, what are you going to null route. The ingress path of the attack packets would have to be traced and cut off at the border of upstream providers, killing legit traffic as well. Appropriate detection/classification/traceback tools and S/RTBH handle most of this; the rest is where intelligent DDoS mitigation capabilities come into play. Stateful firewalls don't do this, and the stateful part is what makes them fall down. An advanced firewall or load balancer (that multiplex's the connections) would be able to mitigate this attack. Again, they a) don't do what you're asserting they do and b) don't scale. This isn't a matter of opinion, it's a matter of operational experience and fact. Putting stateful firewalls in front of servers is both unnecessary and counterproductive. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Unfortunately, inefficiency scales really well. -- Kevin Lawton ___ 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] DNS rewrite global capabilities
The server alone handles a syn attack much better, Without a firewall proxying the tcp connection? That would depend on how many servers there are and what the firewalls can handle. The server never gets traffic from the spoofed addresses with the firewall, or from a load-balancer that multiplex's the tcp connections. Also they obviously block traffic, which is a security benefit. So do stateless ACLs in hardware - much more efficiently. I wouldn't say much more efficiently, since more advanced load balancers and firewalls route via asic's and fpga's. Also, what if the attack has spoofed source addresses, and is evasive of profiling. In other words, what are you going to null route. The ingress path of the attack packets would have to be traced and cut off at the border of upstream providers, killing legit traffic as well. Appropriate detection/classification/traceback tools and S/RTBH handle most of this; the rest is where intelligent DDoS mitigation capabilities come into play. Stateful firewalls don't do this, and the stateful part is what makes them fall down. If the packet is the same as a normal request but a spoofed address, you're going to have some trouble even with automated systems looking for no syn/ack, and then hunting the source down and automatically blocking the true sources at the ingress of the upstreams. That's even if such an effective system actually existed. While the load-balancer or advanced firewall never sent the connection to the server, and the device is designed to be able to handle allocating memory for bogus connections. Again, they a) don't do what you're asserting they do and b) don't scale. This isn't a matter of opinion, it's a matter of operational experience and fact. Putting stateful firewalls in front of servers is both unnecessary and counterproductive. Microsoft.com runs without a stateful firewall. However that wasn't my argument. My argument was the claims you made depend on the level and type of attack, and that the arbor networks system is not effective in all situations. Hence the one size fits all solution is not adequate in all situations, and the solution is not always effective. Anyways I have always been impressed with their products. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Roland Dobbins Sent: Wednesday, July 01, 2009 12:10 AM To: Cisco-nsp Subject: Re: [c-nsp] DNS rewrite global capabilities On Jul 1, 2009, at 11:02 AM, Quinn Mahoney wrote: irewalls do have features, for instance, they can proxy a tcp-syn connection and not send it to the server if it doesn't get an ack. Doesn't scale. Server alone handle this much better, even without syn- cookies. Also they obviously block traffic, which is a security benefit. So do stateless ACLs in hardware - much more efficiently. Also, what if the attack has spoofed source addresses, and is evasive of profiling. In other words, what are you going to null route. The ingress path of the attack packets would have to be traced and cut off at the border of upstream providers, killing legit traffic as well. Appropriate detection/classification/traceback tools and S/RTBH handle most of this; the rest is where intelligent DDoS mitigation capabilities come into play. Stateful firewalls don't do this, and the stateful part is what makes them fall down. An advanced firewall or load balancer (that multiplex's the connections) would be able to mitigate this attack. Again, they a) don't do what you're asserting they do and b) don't scale. This isn't a matter of opinion, it's a matter of operational experience and fact. Putting stateful firewalls in front of servers is both unnecessary and counterproductive. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Unfortunately, inefficiency scales really well. -- Kevin Lawton ___ 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] DNS rewrite global capabilities
On Jul 1, 2009, at 12:09 PM, Quinn Mahoney wrote: Without a firewall proxying the tcp connection? That would depend on how many servers there are and what the firewalls can handle. The server never gets traffic from the spoofed addresses with the firewall, or from a load-balancer that multiplex's the tcp connections. There isn't a firewall made which has the capacity to handle this more efficiently than a well-configured server or server farm. I wouldn't say much more efficiently, since more advanced load balancers and firewalls route via asic's and fpga's. I certainly would, and do; they none of them run into the mpps, as routers can and do. If the packet is the same as a normal request but a spoofed address, you're going to have some trouble even with automated systems looking for no syn/ack, and then hunting the source down and automatically blocking the true sources at the ingress of the upstreams. Not with appropriate detection/classification/traceback tools. This isn't new technology. And blocking at the edges isn't generally accomplished automatically, but manually, upon demand. Intelligent DDoS mitigation devices can and do black automatically. That's even if such an effective system actually existed. They do, see above. While the load-balancer or advanced firewall never sent the connection to the server, and the device is designed to be able to handle allocating memory for bogus connections. They never send the legitimate traffic, either, being overwhelmed by the DDoS. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Unfortunately, inefficiency scales really well. -- Kevin Lawton ___ 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] MPLS/BGP - want to add backup IPSEC VPN
If you're the customer (having only CE routers), this is a classic primary/backup problem, only this time using BGP as the core routing protocol. If you're the provider (using MPLS between your BGP routers to offer whatever services), you can run MPLS over GRE over IPSec on the backup link (just watch for MTU issues). We built a pretty large network using it and after the initial kinks it works perfectly. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ -Original Message- From: Peter Rathlev [mailto:pe...@rathlev.dk] Sent: Tuesday, June 30, 2009 11:51 PM To: ChrisSerafin Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN On Tue, 2009-06-30 at 14:11 -0500, ChrisSerafin wrote: I have a few MPLS routers running BGP as the routing protocol. I added a public IP'ed interface on a free ports on the same router, and I'm able to get to it and use it for Internet bound traffic if I wish. I would like to configure an IPSEC VPN to provide backup if the MPLS provider fails. I'm having a hard time with Cisco TAC on this, mainly them getting back to me. dumb'ed down diagram is at: http://chrisserafin.com/design.jpg I just want a basic split tunnel VPN in the event the primary MPLS/BGP link goes down. I'm assuming let BGP take care of the MPLS side and add static routes with a very high weight for the VPN failover? And the VPN-link needs to carry MPLS traffic too? MPLSoGRE could be an option, but support is very limited AFAIK. Otherwise some extra equipment doing L2TPv3 might work. Performance limitations might very well rule this out. If MPLS isn't needed a simple GRE tunnel would of course do. You could even create a new tunnel per VRF if you need reachability in several of these. It scales bad concerning administration though. Regards, Peter ___ 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] Non export of netflow of dscp bits from PCF3A
Works like designed. The PFC3A doesn't export QoS informations. This has been one major reason to go for the B version for us some times ago at Qimonda. (rem: QoS-netflow-collecting seems a L2-netflow-feature; this is supported in the B versions only) Matthew Huff schrieb: We use Fluke's Netflow Tracker for netflow analysis. I've run into a weird one though. Our netflow export from our distribution switches which are running 12.2(33)SXI1 does not seem to export the dscp bits, but our core switches running 12.2(33)SXI1 as well, do export the dscp bits. The difference is the distribution switch is a PFC3A where the core switches are PFC3Bs. Anyone seen this issue before? I've verified that the netflow configurations are identical, and that the packets do have the attributes set as they pass throught he distribution. Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -- Dirk Kurfuerst Tel. +49 811 99829 130 Fax: +49 89 97007 200 GSM: +49 178 7072043 e-mail: dirk.kurfue...@isarnet.de http://www.isarnet.de http://www.isarflow.de IsarNet AG Terminalstrasse Mitte 18 85356 Muenchen Sitz der Gesellschaft: Oberding Handelsregister Muenchen, HRB 127295 USt.-ID Nr. DE203054669 Vorstand: Andreas Perthel, Harald Weikert Vorsitzender des Aufsichtsrates: Andreas Gallenmueller ___ 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/
