[c-nsp] Limiting Broadcast and Multicast
Hi guys My network has a huge L2 broadcast coming from the clients connected (through DSLAMs)the customer edge facing interfaces are on a 76k with 7600-ES20-GE and 7600-ES20-10G, AFAIK these cards dont support Storm-control--what other variants and options do i have in limiting these garbage before it gets to my network. TIA Hash ___ 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] PIX 7.2 behaviour for NAT exemption
Hello all, I am looking at a firewall configuration, which has multiple DMZs. Of these, here are the configurations for three DMZs DMZ A: security level 50 DMZ B: security level 20 DMZ C: security level 0 Subnet X belongs to DMZ A subnet Y belongs to DMZ B Subnet Z belongs to DMZ C Rules: Subnet X on DMZ A is 'NAT exempted' with another subnet Y on DMZ B (using ACL) Subnet X is allowed 'ip any' access (incoming access-list), on DMZ A access-list On DMZ C, there is a 'permit ip any any' (incoming access-list) PIX software: v7.2(1) Analysis: Because subnet X is 'nat exempted', it will translate as-is for any traffic originating towards and from (bi-directional behaviour) the subnet Y. BUT, this will also translate the subnet X, *as is*, on the DMZ C (if DMZ A subnet tries to direct any traffic towards DMZ C subnet). Understanding: Given the above configuration (and my analysis), if there is any traffic originating from DMZ A (higher) to DMZ C (lower), it will be allowed. Also, if there any traffic originating from DMZ C to DMZ A (lower to higher), the traffic will be allowed because the ACLs allow those and because the NAT exemption rule will translate the subnet on all DMZs (assuming there was an attempt initially to send traffic towards DMZ C, from DMZ A) It's been a year now that I touched a PIX, and now am unable to remember how this works. Would be nice if someone here could help me validate my understandng of the above. Thanks in advance. -- Warm regards, Amol Sapkal --- When I'm not in my right mind, my left mind gets pretty crowded --- ___ 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: Alternantive to REB(route bridge Encapsulation)-2nd try
Hi guys I am trying to find a Feature that will be able to replace Route bridge Encapsulation..because we are migrating to the 12.2S and does not support that feature..any thoughts or Ideas will be useful. Thanks TIA Hash ___ 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] Good 10GE Metro switch
Hi, On Mon, Aug 11, 2008 at 05:08:23PM -0400, Joe Loiacono wrote: PS - Should I worry (alot) about being at or slightly above the 40 Km distance? The key question is, how much loss (in dB) do you have on that line, and on the tolerances of the X2 optics in question - a best case X2 will transmit with +4.0 dBm, while a worst case X2 will transmit with -4.7 dBm, according to: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/0btransc.html - so with a receiver sensitivity of -15.8 dBm, you have a power budget of 11.1 dB to 19.8 dB. 11.1 dB is very tight for a 40km span - you need good fibers, and nearly no patches in between (every patch brings about 0.5 dB loss). You need to ask your carrier about the attenuation of the fiber path. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgphcyZP1IKzv.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] Fwd: Alternantive to REB(route bridge Encapsulation)-2nd try
Hi, On Sat, Aug 16, 2008 at 06:09:56PM +0300, Hash Aminu wrote: I am trying to find a Feature that will be able to replace Route bridge Encapsulation..because we are migrating to the 12.2S and does not support that feature..any thoughts or Ideas will be useful. Thanks Makes me wonder why you would want to migrate to a dead IOS train that doesn't deliver what you want... But if you insist on feeling the pain, the alternative to RBE is classical ATM bridging - setup a BVI interface, a bridge-group, and put the ATM VC into the bridge group. Nasty, does not scale well (maximum of 255 bridge- groups), and much more convoluted configuration. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgp0nResdsztk.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] PIX 7.2 behaviour for NAT exemption
Hello Amol: By my reading you are correct. The basic rule is nat from higher to lower, ACL from lower to higher. You have to have NAT translations when going from a higher security level to a lower security level, so from DMZ A to DMZ B or C in your example. If you don't want that traffic to be translated, you'll need a NAT statement that exempts all traffic back and forth between the two security areas. As an example: Nat (dmz-c) 0 0 access-list to-dmz-b Nat (dmz-b) 0 0 access-list to-dmz-c Access-list to-dmz-b permit ip subnet z subnet y Access-list to-dmz-c permit ip subnet y subnet z These would be in addition to any translations you *want* to occur, using 'nat (interface) 1' Hope that helps, Mike From: Amol Sapkal [EMAIL PROTECTED] Date: Sat, 16 Aug 2008 18:31:59 +0400 To: cisco-nsp cisco-nsp@puck.nether.net Subject: [c-nsp] PIX 7.2 behaviour for NAT exemption Hello all, I am looking at a firewall configuration, which has multiple DMZs. Of these, here are the configurations for three DMZs DMZ A: security level 50 DMZ B: security level 20 DMZ C: security level 0 Subnet X belongs to DMZ A subnet Y belongs to DMZ B Subnet Z belongs to DMZ C Rules: Subnet X on DMZ A is 'NAT exempted' with another subnet Y on DMZ B (using ACL) Subnet X is allowed 'ip any' access (incoming access-list), on DMZ A access-list On DMZ C, there is a 'permit ip any any' (incoming access-list) PIX software: v7.2(1) Analysis: Because subnet X is 'nat exempted', it will translate as-is for any traffic originating towards and from (bi-directional behaviour) the subnet Y. BUT, this will also translate the subnet X, *as is*, on the DMZ C (if DMZ A subnet tries to direct any traffic towards DMZ C subnet). Understanding: Given the above configuration (and my analysis), if there is any traffic originating from DMZ A (higher) to DMZ C (lower), it will be allowed. Also, if there any traffic originating from DMZ C to DMZ A (lower to higher), the traffic will be allowed because the ACLs allow those and because the NAT exemption rule will translate the subnet on all DMZs (assuming there was an attempt initially to send traffic towards DMZ C, from DMZ A) It's been a year now that I touched a PIX, and now am unable to remember how this works. Would be nice if someone here could help me validate my understandng of the above. Thanks in advance. -- Warm regards, Amol Sapkal --- When I'm not in my right mind, my left mind gets pretty crowded --- ___ 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] Verizon TLS
Huh? FA0/0 connects directly to the TLS and FA0/1 connects to the customer switch. The TLS passes through the router before it ever hits their public switch. [EMAIL PROTECTED] wrote: Servers | 7206VXR -TLS 2651XM --- Public switch --- Firewall --- LAN CPE config: interface FastEthernet0/0 desc TLS side no ip address speed 100 full-duplex ! interface FastEthernet0/0.xxx encapsulation dot1Q xxx ip address 192.168.1.2 255.255.255.252 (rate limit to 10M) no cdp enable [snip] ip route 0.0.0.0 0.0.0.0 192.168.1.1 Your diagram and config conflict with each other; according to the config, you're routing to the TLS *through* the switch. According to the diagram, the 2651XM is directly connected to the TLS, and is directly connected to the switch. My guess is that the switch leaks traffic between VLANs. The easiest workaround is probably just to connect the 2651XM directly to the TLS. They didn't have the problem with the T1s since they weren't going through the switch. ___ 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] ip cef load sharing
Dan the reason your having issues is not MTU related, it's NAT related, because you have 3 ADSL lines each doing NAT against a different outside IP when you turn on per-packet load sharing you end up with flows to the same destination having different source IP addresses. Your only option is per-destination load balancing (ie the default), one way you can tweak this a little without breaking to much is to change the standard algorithm to include ports. Try adding ip cef load-sharing algorithm include-ports destination into your global config once you've removed your per-packet load sharing and see how you go. You are never going to get perfect load balancing in your scenario but if you have enough hosts on your LAN it should be sufficient enough, one way you can do per-packet is if you get another IP routed down all 3 adsl lines and put it on a loopback and NAT everything against that. Ben - Original Message - From: Dan Letkeman [EMAIL PROTECTED] To: Rodney Dunn [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Saturday, August 16, 2008 3:29 AM Subject: Re: [c-nsp] ip cef load sharing Still seem to have the same problem even with this: interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 ip tcp adjust-mss 1300 duplex auto speed auto interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 ip load-sharing per-packet duplex auto speed auto Dan. On Fri, Aug 15, 2008 at 12:49 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Aug 15, 2008 at 12:35:01PM -0500, Dan Letkeman wrote: ip load-sharing per-packet I tried adding this to F0/1 and the trace route works now(it randomly picks either line), but there seems to be issues with maybe the MTU? If I try to browse websites i get page errors and some of the pictures and pages don't load. Yep...try configuring ip tcp adjust-mss 1300 or so on the ingress interface from the LAN. Any ideas? Thanks, Dan. On Fri, Aug 15, 2008 at 12:12 PM, Rodney Dunn [EMAIL PROTECTED] wrote: Try ip load-sharing per-packet on both egress interfaces. On Fri, Aug 15, 2008 at 12:00:46PM -0500, Dan Letkeman wrote: Hello, I have a 2621 router running 12.3(26) and I would like to setup load sharing to multiple adsl lines. When I do a traceroute on the router it randomly picks a dsl line and seems to work fine. But when I do traceroute tests from a workstation it always seems to take the same adsl line. Is there something else I need to add to the configuration to make it pick random lines, or is there a timeout of some sorts before it will select the next ip route Here is my config: ! interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 duplex auto speed auto ! ip http server ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.10 ip route 0.0.0.0 0.0.0.0 192.168.10.11 ! The two adsl modem/routers I have are 192.168.10.10, and 192.168.10.11 Thanks, Dan. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ip cef load sharing
There are a couple of companies that can help with this, too, though it's not Cisco-related: http://www.sharedband.com/ http://www.mushroomnetworks.com/ http://www.xrio.com/website/ Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Steele Sent: Saturday, August 16, 2008 6:36 PM To: Dan Letkeman; Rodney Dunn; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ip cef load sharing Dan the reason your having issues is not MTU related, it's NAT related, because you have 3 ADSL lines each doing NAT against a different outside IP when you turn on per-packet load sharing you end up with flows to the same destination having different source IP addresses. Your only option is per-destination load balancing (ie the default), one way you can tweak this a little without breaking to much is to change the standard algorithm to include ports. Try adding ip cef load-sharing algorithm include-ports destination into your global config once you've removed your per-packet load sharing and see how you go. You are never going to get perfect load balancing in your scenario but if you have enough hosts on your LAN it should be sufficient enough, one way you can do per-packet is if you get another IP routed down all 3 adsl lines and put it on a loopback and NAT everything against that. Ben - Original Message - From: Dan Letkeman [EMAIL PROTECTED] To: Rodney Dunn [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Saturday, August 16, 2008 3:29 AM Subject: Re: [c-nsp] ip cef load sharing Still seem to have the same problem even with this: interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 ip tcp adjust-mss 1300 duplex auto speed auto interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 ip load-sharing per-packet duplex auto speed auto Dan. On Fri, Aug 15, 2008 at 12:49 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Aug 15, 2008 at 12:35:01PM -0500, Dan Letkeman wrote: ip load-sharing per-packet I tried adding this to F0/1 and the trace route works now(it randomly picks either line), but there seems to be issues with maybe the MTU? If I try to browse websites i get page errors and some of the pictures and pages don't load. Yep...try configuring ip tcp adjust-mss 1300 or so on the ingress interface from the LAN. Any ideas? Thanks, Dan. On Fri, Aug 15, 2008 at 12:12 PM, Rodney Dunn [EMAIL PROTECTED] wrote: Try ip load-sharing per-packet on both egress interfaces. On Fri, Aug 15, 2008 at 12:00:46PM -0500, Dan Letkeman wrote: Hello, I have a 2621 router running 12.3(26) and I would like to setup load sharing to multiple adsl lines. When I do a traceroute on the router it randomly picks a dsl line and seems to work fine. But when I do traceroute tests from a workstation it always seems to take the same adsl line. Is there something else I need to add to the configuration to make it pick random lines, or is there a timeout of some sorts before it will select the next ip route Here is my config: ! interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 duplex auto speed auto ! ip http server ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.10 ip route 0.0.0.0 0.0.0.0 192.168.10.11 ! The two adsl modem/routers I have are 192.168.10.10, and 192.168.10.11 Thanks, Dan. ___ 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/ ___ 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/
