[c-nsp] Server Load balancer in high availability configuration
Hi All, I've a network with 2 internet facing routers and connected to 2 internal firewalls through layer 2 switches ( full redundant configuration) I'm adding a DMZ to the firewalls interfaces, in which i need to have server load balancer like cisco CSS11xxx series to load balance web servers, I'm looking for help to design and configure this scenario. the 2 firewall DMZ interfaces are connected to 2 layer to switches to serve the DMZ where the web servers are located, should the firewalls be connected directly to the 2 SLBs instead?...how to configure the SLBS for this scenario?...also, in that case if the web servers need to contact an internal database, this will make all traffic from the DMZ web servers to the internal network pass again through the SLBs including the web servers management traffic... cisco has docuemnts for configuration only for 6500 modules in which 2 6500 switches have 2 firewall modules and 2 SLB modules, have anyone worked with the CSS11xxx series can give some guidance? all your help are highly appreciated. thanks a lot reagrds, Nad. ___ 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] Server Load balancer in high availability configuration
On Mar 21, 2010, at 1:11 PM, shadow floating wrote: I'm looking for help to design and configure this scenario. Take the servers out from behind the firewalls, they do no good and will make it far easier to DDoS your servers. Harden the server OS/apps/services. Use something like mod_backhand or LVM; or if you want to go the commercial route, avoid Cisco CSS like the plague, it's junk (and I think it's EoS/EoL, anyways). Cisco's current SLB blade/appliance is called ACE, though F5 or other hardware vendors can scale better for Interent-facing apps, IMHO. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken ___ 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] Protecting a sup2/msfc2 in 2010: CoPP the hard way
Dear Cisco, I've implemented my own form of CoPP on sup2/msfc2, using features of (18)SXF in a manner somewhat like the sup720. Could you please give us the same functionality a tad more directly? Clearly, there's stuff here that can mimic the essential behavior of formal CoPP (post-routing, pre-mls exception rate-limiter), without needing further shims, acls, or policers *after* receive adjacencies are matched. After all, cisco.com reveals that SXF will be supported until 2012 for the sup2; I think this is ample time! -Tk -- Dear List, Find below a basic outline of how I approached the issue of inbound CoPP on the sup2. I hope folks minimally find it amusing, perhaps even useful in their environments. Let me know if this works for you, or completely destroys your border/core/dist/agg layers upon application. As always, use at your own risk, YMMV, AMF YOYO, BYOB, etc. Best, -Tk -- Fellow geeks, We thought the sup2 was doomed to a life of uninteresting or mundane tasks, and was stuck with an anemic, woe-is-me! control-plane which couldn't *really* be fixed or improved in any substantive way. I figured there had to be a way around this. Indeed, PFC2 supports some mls special-case rate limiters--unfortunately, they're pretty darn broad/general, which will cause trouble if you're running protocols in/out of the MSFC... and heck, who wouldn't be? I also like TELNET and SSH to work when the box is under attack. I started with this basic mls config: mls qos mls rate-limit unicast cef receive 500 mls rate-limit unicast cef glean 1000 mls rate-limit unicast acl ingress 1000 mls rate-limit unicast acl egress 1000 mls rate-limit unicast l3-features 1000 But, as you likely know, this stomps on * and 0.0.0.0/0 heading towards MSFC; bad. Since this happens after the PFC and EARL have had their chance to examine the packet, I figured it was simply too late to expect any sort of clever post-routing fix to happen. Frustrated, I thought to look earlier the forwarding chain, perhaps finding some way to get 'selected' packets to not hit the MSFC/EARL at all--and instead punt them to the RP cpu directly (or as close as possible to input-phase). This would then deliver packets to the RP before routing and before cef receive adjacencies could be matched processed by the overly-broad mls rate-limiter. I figured if I could do that, I'd selectively avoid the mls stomp-stomp for specific, critical packets, while still retaining the everything else == 500 pps! mls rate-limiting functionality. I began reading here: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/qos.html#wp1671353 ...and noticed that indeed, the pfc can create punted paths, well ahead of any routing activity. That got me thinking, what will punt a packet for sure? ACL LOGGING! I then tried a simple ingress ACL on a uplink-facing port, like so: Extended IP access list proto-punt 10 permit ip host xx.xx.128.65 any log 20 permit ip host yy.yy.12.254 any log 30 permit ip host yy.yy.12.253 any log 40 permit tcp any any eq telnet log 50 permit ip any any ...and sure as heck, several configured BGP neighbors' updates and telnet session traffic were nicely bypassing the MSFC and MLS rate limits, when the acl was activated inbound on a uplink port; helo pre-routing punts. But, this is fairly sub-optimal--I wanted something a tad cleaner, ideally with specific policers + acl's in the path towards the RP's precious 300 mhz mips. To that end, I needed a way to redirect packets sooner. What follows list is a great list of what you ought not never do on a 6500, which will most assuredly drain packets straight into parts of the router you ought not frequently traffic: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml#acl I'd like to highlight one line: Policy-routed traffic, with use of match length, set ip precedence, or other unsupported parameters I banged' this out to test the theory: route-map puntwhat permit 10 match ip address puntzilla set ip precedence internet Extended IP access list puntzilla 10 permit ip host xx.xx.128.65 any 20 permit ip host yy.yy.12.253 any 30 permit ip host yy.yy.12.254 any 35 permit tcp any any eq 22 (4 matches) 40 permit tcp any any eq telnet (6 matches) ...after application of ip policy route-map on the inpu(n)t interface, we see that the PFC acl tcam was indeed getting programmed as we requested: test6509#sh tcam interface fastEthernet 6/1 acl in ip * Global Defaults shared permit ip any 224.0.0.0 15.255.255.255 redirect tcp any any fragments redirect tcp any any eq 22 (match) redirect tcp any any eq telnet (match) redirect ip host xx.xx.128.65 any (match) redirect ip host yy.yy.12.253 any (match) redirect ip host yy.yy.12.254 any (match) permit ip any any fragments
Re: [c-nsp] Insufficient memory to boot image on 827?
Steve unless some odd memory allocation is occurring and based on what you provided, then you do not have enough memory to load the image. One thing to take in consideration is that the images are compressed, so during the boot process the router will decompress the image and if you do not have enough memory, it will obviously fail to boot. You say that you are running the 12.4(5C), but what feature set (IP/FW, IP Plus, IP)? Take note, that if you are trying to boot the IP PUS image this is what is more than likely causing your issue. This image requires at least 32MB of RAM to boot. What is the file name that you copied to flash? Billy - Original Message - From: Steve Edmonson steve.j.edmon...@gmail.com To: cisco-nsp@puck.nether.net Sent: Saturday, March 20, 2010 4:31 PM Subject: [c-nsp] Insufficient memory to boot image on 827? Hello there I am trying to upgrade IOS on an 827 I have to 12.4(5c). The 827 has 24MB of DRAM, and this is the highest version that cisco.com says will run inside 24MB. After I load the image on to the 827 and reload, I get SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE! and the router reloads, tries to boot, runs out of RAM, reloads, etc, etc, etc. When booting from an image that does work, show ver confirms that there is 24MB of DRAM in the router CISCO C827 (MPC855T) processor (revision 0x701) with 23552K/1024K bytes of memory. Is there any way to get this image to boot, or do I have no choice but to upgrade the DRAM? TIA Steve ___ 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] Protecting a sup2/msfc2 in 2010: CoPP the hard way
On Mar 21, 2010, at 10:22 PM, Anton Kapela wrote: I've implemented my own form of CoPP on sup2/msfc2, using features of (18)SXF in a manner somewhat like the sup720. While this represents a lot of work and experimentation which is greatly to be admired, mightn't simple iACLs plus the GTSM and a few other standard BCPs achieve pretty much the same desired goal with quite a bit less effort? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken ___ 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] Protecting a sup2/msfc2 in 2010: CoPP the hard way
On Mar 21, 2010, at 12:39 PM, Dobbins, Roland wrote: While this represents a lot of work and experimentation which is greatly to be admired, mightn't simple iACLs plus the GTSM and a few other standard BCPs achieve pretty much the same desired goal with quite a bit less effort? Input/receive acls, as far as I'm aware, are not supported (on 65xx), regardless of cfc/dfc/etc status--and only exist in the GSR and 10k platforms. With regards to GTSM[1] -- indeed it's in the SX train and available for sup2 in SXE onwards. However, one bit gives gave me a bit of pause when reviewing it at 2am: If the value is less than the configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. I would appreciate anything you can share regarding how this is implemented internally on PFC/MSFC platforms. Silently discarded, how? At what point? All in all (and aside from CoPP), these two mechanisms are indeed great--but they're only great when implemented on $platform, and when it's clear how they work on $platform. I also argue that maintaining a flattened-out input ACL blocking packets to receive adjacencies puts the engineering effort-required slider up a few notches; I appreciate the clean/simple nature of CoPP and dislike loading up ACL cam, per port, with repetitive filters, across all or most ports. In my proposal and example previous, the service-policy and route-map pair are required to be applied to protocol-carrying interfaces, not customer/agg/dist-facing ports. The built-in mls rate-limiter handles spurious l2/l3 punts from glean/receive adj. across the entire chassis already -- I merely wanted a few 'narrow exceptions' to that for a handful of interfaces. ;) -Tk [1] http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html ___ 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] Protecting a sup2/msfc2 in 2010: CoPP the hard way
On Mar 22, 2010, at 1:17 AM, Anton Kapela wrote: Input/receive acls, as far as I'm aware, are not supported (on 65xx), regardless of cfc/dfc/etc status--and only exist in the GSR and 10k platforms. iACL = infrastructure ACL. It's merely a technique making use of normal inbound ACLs, processed in hardware on Sup2 (as well as later Sups). You're thinking of the rACL, which is supported on GSR and 7500 only, AFAIK. With regards to GTSM[1] -- indeed it's in the SX train and available for sup2 in SXE onwards. However, one bit gives gave me a bit of pause when reviewing it at 2am: If the value is less than the configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. Combine it with iACLs and you're set. I also argue that maintaining a flattened-out input ACL blocking packets to receive adjacencies puts the engineering effort-required slider up a few notches; I appreciate the clean/simple nature of CoPP and dislike loading up ACL cam, per port, with repetitive filters, across all or most port From my standpoint, it's a whole lot *easier* to generate an iACL than making use of the HWRL (or using CoPP), and it only has to be applied to edge interfaces on edge boxes, nowhere else. And it's the same on every box, irrespective of platform. The only prerequisite is a rational, summarizable IP addressing plan for one's loopbacks and p2p interfaces. If you take some time to plan it out, I think you'll find the iACL is pretty useful. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken ___ 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] Protecting a sup2/msfc2 in 2010: CoPP the hard way
On Mar 22, 2010, at 1:43 AM, Anton Kapela wrote: iACL at borders makes plenty of sense, but what about the rest of the interfaces platforms within it? It also includes internal edges such as the IDC distribution gateway edge, facing southbound towards the aggregation/access networks. If one's overall security posture is such that attackers can get into one's core infrastructure and cause problems at one's edges, one has problems mere technology cannot solve. ; I'm not saying that CoPP and HWRL are Bad Things - quite the contrary, they're Good Things. But you can get 90% or more of what you get from CoPP/HWRL via iACLs in exchange for much less effort - and since you have to do ACLs at your various edges anyways in order to enforce policy for traffic headed to/from your external DNS resolvers, Web portals, et. al., why not go ahead and add the iACL stanzas to those edge ACLs? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken ___ 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] Insufficient memory to boot image on 827?
Hi Steve, I had a similar thing with an 1801 - there was a memory command in the config allocating some of the Ram to IO. Can't remember exactly what the command was but worth checking! Regards Nigel Hello there I am trying to upgrade IOS on an 827 I have to 12.4(5c). The 827 has 24MB of DRAM, and this is the highest version that cisco.com says will run inside 24MB. After I load the image on to the 827 and reload, I get SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE! and the router reloads, tries to boot, runs out of RAM, reloads, etc, etc, etc. When booting from an image that does work, show ver confirms that there is 24MB of DRAM in the router CISCO C827 (MPC855T) processor (revision 0x701) with 23552K/1024K bytes of memory. Is there any way to get this image to boot, or do I have no choice but to upgrade the DRAM? TIA Steve ___ 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] Protecting a sup2/msfc2 in 2010: CoPP the hard way
On 21/03/2010 15:22, Anton Kapela wrote: Find below a basic outline of how I approached the issue of inbound CoPP on the sup2. I hope folks minimally find it amusing, perhaps even useful in their environments. Let me know if this works for you, or completely destroys your border/core/dist/agg layers upon application. As always, use at your own risk, YMMV, AMF YOYO, BYOB, etc. Wicked sick! Nick ___ 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] Flexible Netflow NBAR Autonomous 10 GbE probe
Misses, Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. Me and my partners, INVEA-TECH [0], are currently working on High-Speed Networking Solutions. Our flagship product is Flowmon probe that is a Hardware Accelerated Flexible Netflow NBAR Autonomous 10 GbE probe [1] : http://docs.google.com/viewer?url=http://www.cesnet.cz/doc/techzpravy/2009/flow-measurement-applications/flow-measurement-applications.pdf The advantage of autonomous NetFlow probe is the possibility to deploy NetFlow measurement where a dedicated source of NetFlow data is missing. Autonomous NetFlow probes allows user to set any parameter arbitrarily without fear that the bypassing traffic will be influenced. On the other hand when enabling NetFlow on routers one have to always be careful about the additional performance demands on hardware resources by monitoring process (please see the following article from Cisco entitled NetFlow Performance Analysis [2]). Probes are usually more flexible and allow to test new features such as different types of sampling, filtering or anonymization. For you to have a better overview of our company : We are young and progressive European IT company based on the results of several EU RD projects. We have world unique products for wire-speed packet processing (100 Gigabit Ethernet networks Ready). We look forward to your answer, Best Regards, [0] http://www.invea-tech.com [1] http://www.invea-tech.com/products/flowmon-probes [2] http://www.cisco.com/en/US/technologies/tk543/tk812/technologies_white_paper0900aecd802a0eb9.html Guillaume FORTAINE Tel : +33(0)631092519 ___ 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] Flexible Netflow NBAR Autonomous 10 GbE probe
Go away. On Sun, Mar 21, 2010 at 11:25 PM, Guillaume FORTAINE gforta...@live.com wrote: Misses, Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. Me and my partners, INVEA-TECH [0], are currently working on High-Speed Networking Solutions. Our flagship product is Flowmon probe that is a Hardware Accelerated Flexible Netflow NBAR Autonomous 10 GbE probe [1] : http://docs.google.com/viewer?url=http://www.cesnet.cz/doc/techzpravy/2009/flow-measurement-applications/flow-measurement-applications.pdf The advantage of autonomous NetFlow probe is the possibility to deploy NetFlow measurement where a dedicated source of NetFlow data is missing. Autonomous NetFlow probes allows user to set any parameter arbitrarily without fear that the bypassing traffic will be influenced. On the other hand when enabling NetFlow on routers one have to always be careful about the additional performance demands on hardware resources by monitoring process (please see the following article from Cisco entitled NetFlow Performance Analysis [2]). Probes are usually more flexible and allow to test new features such as different types of sampling, filtering or anonymization. For you to have a better overview of our company : We are young and progressive European IT company based on the results of several EU RD projects. We have world unique products for wire-speed packet processing (100 Gigabit Ethernet networks Ready). We look forward to your answer, Best Regards, [0] http://www.invea-tech.com [1] http://www.invea-tech.com/products/flowmon-probes [2] http://www.cisco.com/en/US/technologies/tk543/tk812/technologies_white_paper0900aecd802a0eb9.html Guillaume FORTAINE Tel : +33(0)631092519 ___ 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/
Re: [c-nsp] BGP Balancing
It's actually both, but i'm mostly concerned with inbound traffic. On 3/20/2010 1:39 PM, Paul Stewart wrote: For inbound traffic our outbound traffic? Or both? MED's are not going to help here... Paul -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Chris Gotstein Sent: March-20-10 1:19 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP Balancing We are a small ISP that is multi-homed to 2 providers. Each link is 45mbs and we are receiving full bgp routing tables from each provider. I've been trying to load balance the traffic going out over these two connections, but am looking for some advice on other tricks i can try. Unfortunately, only one provider sends MED metrics, so i'm unable to use the bgp med for path selection. I'm currently using 'bgp bestpath as-path multipath-relax' and 'maximum-paths 2'. One link still gets 75% of the traffic, which i believe is do to the fact it has a lower ip address than the other link. Any suggestions on configurations i can try to influence better path load balancing? -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 ch...@uplogon.com ___ 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] BGP Balancing
On 3/21/10 9:53 PM, Chris Gotstein wrote: It's actually both, but i'm mostly concerned with inbound traffic. Inbound is trickier than outbound. Many carriers offer a list of BGP communities which can be used to influence how they treat your advertisements, either by manipulating local preference, prepending, or both. Many are listed here: http://onesc.net/communities/ but ask your upstreams to be sure. Make small changes slowly. Verify with external looking-glass sites to ensure that you're getting the results you want. -- 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] BGP Balancing
Hi, Agree with Jay, AS path prepending is one good option to influence inbound traffic to load balance. Though you have to be precise with how many AS you are prepending to exactly load balance. But I have seen in web hosting environment that it sometime causes website user with problem of page not loading properly. These things need to be planned,and slowly implemented. Regards, Jawwad Paracha IBM On Mon, Mar 22, 2010 at 10:09 AM, Jay Hennigan j...@west.net wrote: On 3/21/10 9:53 PM, Chris Gotstein wrote: It's actually both, but i'm mostly concerned with inbound traffic. Inbound is trickier than out ound. Many carriers offer a list of BGP communities which can be used to influence how they treat your advertisements, either by manipulating local preference, prepending, or both. Many are listed here: http://onesc.net/communities/ but ask your upstreams to be sure. Make small changes slowly. Verify with external looking-glass sites to ensure that you're getting the results you want. -- 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/ ___ 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] BGP Balancing
Yup, AS prepend and BGP communities. Don't forget that you can selectively adjust those per net blocks you are advertising so net A comes in mostly in provider 1 and net B comes in provider 2 or some other variation. I didn't realize that when I first started doing BGP 15 years ago until someone mentioned it. On Mon, Mar 22, 2010 at 1:29 AM, Muhammad Jawwad Paracha jawwa...@gmail.com wrote: Hi, Agree with Jay, AS path prepending is one good option to influence inbound traffic to load balance. Though you have to be precise with how many AS you are prepending to exactly load balance. But I have seen in web hosting environment that it sometime causes website user with problem of page not loading properly. These things need to be planned,and slowly implemented. Regards, Jawwad Paracha IBM On Mon, Mar 22, 2010 at 10:09 AM, Jay Hennigan j...@west.net wrote: On 3/21/10 9:53 PM, Chris Gotstein wrote: It's actually both, but i'm mostly concerned with inbound traffic. Inbound is trickier than out ound. Many carriers offer a list of BGP communities which can be used to influence how they treat your advertisements, either by manipulating local preference, prepending, or both. Many are listed here: http://onesc.net/communities/ but ask your upstreams to be sure. Make small changes slowly. Verify with external looking-glass sites to ensure that you're getting the results you want. -- 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-...@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-...@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/
