Re: [c-nsp] Applying ACL
my preferred method is to upload the acl with tftp, ofcourse with the
first line permit tcp any any established
also I have created a script on the tftp server (which works only with
non-named access-lists), which extracts the acls from a router
configuration file, and places each acl on a different file:
#!/bin/sh
myfile=$1
\rm /tftpboot/acls/*
for i in `grep access-list $myfile | grep -v as-path | awk ' { print
$2 } ' | sort | uniq`
do
echo no access-list $i acls/acl-$i
grep access-list $i $myfile acls/acl-$i
echo end acls/acl-$i
done
therefore I apply the changes with this method
router# wri net (- to tftp server)
tftpserver# vi router-confg
tftpserver# ./abovescript router-confg
router# copy tftp://tftpserver/acls/acl-140 running-config
Best Regards,
John
Jeff Kell wrote:
Gert Doering wrote:
But usually you're dead in the water as soon as you copy-and-paste a
new version of the ACL and the first line gets active, prohibiting any
further lines to go through...
...unless that first line is a 'permit tcp any any established'
Still might want to do a 'reload in 5' right before, just in case you lock
yourself out of the playhouse :-)
Jeff
___
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] Windows Vista, Gratuitous ARP and DHCP conflicts
Asbjorn Hojmark - Lists wrote: You're saying that gateways with proxy arp enabled will respond to ARP requests when the target IP is INSIDE the subnet? That only happens when you have 'ip local-proxy-arp' configured. It should be apparent that's not the case, or nothing would work on that subnet ever. If one was running Private VLAN in that subnet, it would. Presumably only if one also disabled icmp redirects. ___ 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] Windows Vista, Gratuitous ARP and DHCP conflicts
Justin Shore wrote: Phil Mayers wrote: It's all good up until this point. The g-arp that Vista sends uses a BS MAC (a multi-cast MAC no less) for the THA (target hardware address). It That's odd. uses 0.0.0.0 for the SPA (source protocol address). Herein lies the That's normal. So a host can send ARPs without a valid SPA? Sending with an SPA of 0.0.0.0 is part of the duplicate address detection that certainly every version of windows from win98 onwards, most linux /sbin/dhclient-script setups and MacOSX have used. So yes. My Google-fu is weak finding the relevant RFCs however. The rationale is that of course during DAD you don't *have* a valid SPA. problem. Any device that performs proxy-arp functions will respond to this ARP because 1) it has a connected network to the target device in question and 2) it knows based on the SPA that the sending host is not already in that subnet (otherwise the local host would respond to the ARP itself). When the proxy-arp device responds, in our case the You're saying that gateways with proxy arp enabled will respond to ARP requests when the target IP is INSIDE the subnet? It should be apparent that's not the case, or nothing would work on that subnet ever. Proxy-ARP is supposed to kick in when a router receives an ARP request for a TPA that's part of a subnet on another interface. In the case of our VisionNet 202s the modem is pulling an IP even in bridged mode Ah, I see. unless you explicitly disable the built DHCP client which is on by default. That means that the modem has a connected route to the TPA's subnet thus meeting the requirements for proxy-arp and allowing it to reply to the g-arp with its own MAC in the reply. This was easily proven once we realized this by disabling the DHCP client on the modem. It no longer had a connected route to the TPA's subnet and would no longer respond to the g-arps. It was a very annoying and costly problem for us. I had to watch the DHCP conflicts for signs of the problem, debug the DHCP server to find out which PVC the DECLINE was coming in on, cross-referenced the VPI/VCI to a specific customer and generate a truck roll to go out and either replace the modem or switch it to bridged modem and disable the DHCP client. Needless to say that was a lot of truck rolls. Yes - I can imagine that was very tedious! This may not be what Kurt is seeing but this may help him find a more workable solution. Justin ___ 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] [Query] Bgp Session timers
Hi, Not only that, don't forget BGP walker :) The BGP scanner process normally runs every 60 sec Default BGP Scanner Behavior BGP monitors the next hop of installed routes to verify next-hop reachability and to select, install, and validate the BGP best path. By default, the BGP scanner is used to poll the RIB for this information every 60 seconds. During the 60 second time period between scan cycles, Interior Gateway Protocol (IGP) instability or other network failures can cause black holes and routing loops to temporarily form. So if you don't use some kind of event driven notification like: BGP Support for Next-Hop Address Tracking and BGP Support for Fast Peering Session Deactivation there's a possibility that your traffic would be blackholed for up to 60 sec Regards, Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Christoph Loibl Sent: vrijdag 1 juni 2007 8:53 To: Simon Leinen Cc: Danny; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] [Query] Bgp Session timers Hi! On Jun 1, 2007, at 12:21 AM, Simon Leinen wrote: Arie Vayner \(avayner\) writes: Danny, With iBGP the timers for BGP are not really important... You actually need to worry about the IGP convergence. The reason for that is that usually when a link fails, you don't really expect the BGP session to the RR to go down, but just use the redundant IGP path. Yes, but what about when a router fails, in particular a border (eBGP+iBGP) router? In such a case, iBGP timers (or the configuration of a mechanism such as BFD) will determine how long it takes for other routers that the eBGP routes from the dead router have to be dropped. This can be very important, because using the dead router's eBGP routes can mean blackholing traffic. No need to adjust the iBGP timers in that case. Your bgp-next-hop (which is ideally a loopback-ip of the crashed router) will simply disapear from your internal routing-table, and all iBGP neighbors (also the RRs) will remove all routes that are unreachable (because of the unreachable next-hop) from their tables. You only rely on the convergence-time of your igp (ospf? isis? ...?) to remove the dead loopback-ip from its table and the calculation of BGP that is triggered when the loopback-ip disappears. Stoffi -- CHRISTOPH LOIBL mailto:[EMAIL PROTECTED] |No trees were killed in the creation of this message. http://pix.tix.at |However, many electrons were terrible inconvenienced. CL8-RIPE PGP-Key-ID: 0x4B2C0055 +++ ___ 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] Applying ACL
Gert Doering wrote: Hi, On Wed, May 30, 2007 at 01:33:21PM -0700, Kevin Graham wrote: If you are wiping them out, you should always remove them to be safe (even if weren't default-deny behavior when missing, there is an unavoidable window between creation and completion). Just to correct this small bit: default in IOS for packet ACLs is default-permit *if the ACL is completely missing*. But usually you're dead in the water as soon as you copy-and-paste a new version of the ACL and the first line gets active, prohibiting any further lines to go through... At least on the 6500 platforms, I believe the defined behaviour for named ACLs is that the changes are only applied once you exit the sub-mode? ...which makes it a particular shame that the commands: no all abort ...don't exist in that sub-mode. ___ 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] Device export in ACS-SE
Dear Gurus, Any one know a way to export a list of all network devices in appliance ACS-SE? I need to do some scripts to automate the validation of data. Our net have often changes, manual validation is too hard... I tried read the binary backup, but it has no public format. Our ACS is an ACS-SE 4.1, but suggestion on ACS for windows are appreciated too. Thanks, Kratz ___ 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] 3725 packet loss
On Thu, May 31, 2007 at 05:27:24PM -0400, Scott Dunn wrote: Hi We are seeing 2-4% packet loss on a 60Mbps link with 3725 when traffic reaches about 35-40Mbps (based 30s load interval) (FYI the circuit has been tested multiple times and is clean). I suspect that the traffic is bursting to 60Mbps for short period and causing the loss. Easy to verify. Configure a MQC policy with a policer with a conform action to transmit and an exceed action to transmit. Then watch for matches in the exceed line of 'sh policy-map interface blah'. If you see them you are bursting. Also, you would be seeing drops in the 'sh int blah' on output drops if you are bursting, overrunning the tx side line rate, and filling up the outputqueue. The Cisco command interpreter seems to indicate that the buffers need tuning as I'm getting lots of failures vs hits for the larger buffers. VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 13 @ 1w6d): 10 in free list (0 min, 100 max allowed) 84 hits, 685 misses, 11 trims, 11 created 685 failures (0 no memory) Large buffers, 5024 bytes (total 1, permanent 0, peak 4 @ 1w4d): 1 in free list (0 min, 10 max allowed) 14 hits, 671 misses, 131 trims, 132 created 671 failures (0 no memory) Huge buffers, 18024 bytes (total 1, permanent 0, peak 3 @ 1w4d): 1 in free list (0 min, 4 max allowed) 11 hits, 660 misses, 128 trims, 129 created 660 failures (0 no memory) No they don't. And you shouldn't be hitting the system buffers for transit traffic anyway. Those buffers are only for process switched traffic. I don't have any experience playing with buffer sizes and was hoping for some insight before experimenting, Thanks Scott ___ 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] Best Routing Protocol for Scenario
Can you draw a jpeg that shows the layout? That's a lot easier than trying to draw it from email. Rodney On Thu, May 31, 2007 at 01:11:38PM -0400, Paul Stewart wrote: Hi folks... A while back (month or so) I posed a few questions about Policy Based Routing - thinking that was best way to conquer a new challenge... now I'm not so sure so looking for input. Here's the layout and what I want to accomplish Customer premise has a Cisco 3662 router. From the 3662 we have 2 TI's leaving and 2 Ethernet connections leaving towards a 6509 back in our data center. The 2 T1's go to a remote POP where they terminate on a Cisco 3640 router. The Cisco 3640 router connects to a Cisco 7206VXR which in turn connects via TLS back to the same 6509 in our data center. The ethernet connections leaving the customer site from the Cisco 3662 connect directly back to the 6509 with speeds of 6 Mb/s X 800Kb/s each. The T1's are full 1.544 Mb/s. So, one router at customer premise that needs to connect back to one router in our data center using 4 paths. The pair of T1's and the pair of ethernet ports should be bonded or load balanced. Traditionally this has been done via OSPF/CEF on our side of things. We want all VOIP traffic passing between the customer site and our data center to travel via the T1 circuits and all Internet traffic to go via the ethernet connections. I'm looking for the best routing protocol in this scenario that will allow me to use route-maps (or other alternatives) to identify source IP and destination IP subnets and apply priority. At the same time if the far end of each connection is unavailable then I want the traffic to fallover to the other connections as a backup automatically. I had though at one point that OSPF would be ideal but I'm not aware of a way to apply a route-map to OSPF specifying only certain traffic prefers a certain path. We do this all the time with BGP so I though maybe iBGP could be applied here but I have the feeling that there is a better solution Open to ideas and appreciate it... Paul ___ 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] Applying ACL
On Fri, Jun 01, 2007 at 10:11:16AM +0300, John Kougoulos wrote: my preferred method is to upload the acl with tftp, ofcourse with the first line permit tcp any any established ... Gert Doering wrote: But usually you're dead in the water as soon as you copy-and-paste a new version of the ACL and the first line gets active, prohibiting any further lines to go through... My handy script, aclmaker, takes care of most of these issues automatically. It uploads a test version of the ACL with a different name to assure that the syntax is OK, then modifies the access-group statement for each interface that references the ACL to point to the test ACL, then re-uploads the new ACL with the right name, and finally switches the access-group statements back to the new ACL under its correct name so that the switchover to the new ACL happens in one stroke. If you use aclmaker, you will only get locked out if you write an ACL that locks you out. There are never any partial ACLs applied to an interface, and the window where the interface has no ACL applied to it is minimized. You can edit ACLs with your favorite text editor, even if they're hundreds of lines long, and then upload them to the router. It also supports a diff command so you can compare a locally edited ACL to the one on the router. http://sourceforge.net/project/showfiles.php?group_id=25401 You can also do things like this on the command line on your Unix host: # copy every ACL on the router into an individual file on the local host for acl in $(aclmaker list); do aclmaker get $acl; done # run a command on the Cisco and pipe its output to a local shell command aclmaker cmd 'show ip route' | wc -l # test an ACL for syntax errors before uploading it aclmaker test FILENAME Requires a Unix-ish system with Perl and a few Perl modules. One of these days I'll upgrade it to work with RANCID which should make it a bit easier to use (assuming you've already climbed over RANCID's learning curve). ___ 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] ipv6ip vs gre
What's the difference between an ipv6ip tunnel and a gre tunnel? ___ 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] ipv6ip vs gre
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 matthew zeier wrote: What's the difference between an ipv6ip tunnel and a gre tunnel? v6 packets in an ipv6ip tunnel are directly encapsulated in an IPv4 header where v6 packets in a GRE tunnel are encapsulated in a GRE header and then the IPv4 header. See http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_configuration_guide_chapter09186a00801d6604.html#wp1027177 - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYD4DE1XcgMgrtyYRAlpiAJ0QYuktvB+RMYdkfvFmob+mP7OoQQCgvri6 jgdIT1PMe9rElK9FWE0BTaE= =Xslu -END 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/
[c-nsp] SUP-32 and SIP-400
Hello list I was under the impression that sip-400 required sup-720-3b/3bxl or greater because the sup-32 doesn't have fabric connectivity. http://www.cisco.com/en/US/products/hw/routers/ps368/products_data_sheet0900aecd8027c9e6.html According to this document, only the supervisor Engine 720-3B and 720-3BXL are listed. But when I tried sloting sip-400 into a chassis with sup-32 it came up just fine. Is this something that has changed recently or has sup-32 always supported the sup-400. According to this http://www-search.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/ol_4164.htm#wp2565000 It's only the sip-600 that isn't supported on sup-32. What about performance difference between sip-400 with sup32 vs. sup-720 ? Regards MKS ___ 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] display last lines of logging
I've had some preliminary discussions with them about some of these ideas. Unfortunately the way it's implemented today it's not as simple as it seems. I'm not sure I will be able to make these happen unfortunately. The event logs are a different infrastructure so they had some of this capability designed in to it. Rodney On Thu, May 31, 2007 at 01:03:35AM +0930, Brad Gould wrote: How about rtr#sh log last x where x=minutes? Brad Rodney Dunn wrote: Good suggestion. Let me see if I can convince development to code it. We have some of those things with the event log infrastructure already. UUT_#sh monitor event-trace ssm ? all Show all the traces in current buffer backShow trace from this far back in the past clock Show trace from a specific clock time/date from-boot Show trace from this many seconds after booting latest Show latest trace events since last display parameters Paramters of the trace On Thu, May 24, 2007 at 05:26:01PM +0300, Tassos Chatzithomaoglou wrote: I was wondering Is there a way to display the x last lines of the log of a router (through the cli) ? Like the CatOS sh logging buffer -x is doing. -- Tassos ___ 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/ -- Brad Gould, Network Engineer Internode PO Box 284, Rundle Mall 5000 Level 3, 132 Grenfell Street, Adelaide 5000 P: 08 8228 2999 F: 08 8235 6999 [EMAIL PROTECTED]; http://www.internode.on.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/ ___ 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] ipv6ip vs gre
On Fri, 1 Jun 2007, Gert Doering wrote: Hi, On Fri, Jun 01, 2007 at 07:41:01AM -0700, matthew zeier wrote: What's the difference between an ipv6ip tunnel and a gre tunnel? Well, one is using IPv6-IP encapsulation, and the other is using GRE encapsulation. Sort of like what is the difference between a BMW and a Chrysler? - both are transport vehicles, but they look different... One important difference: ipv6-ip encapsulation is an IPv6 only solution, while GRE is more general one (with some more byte overhead). However if you want to run IS-IS on the tunnel you should use GRE since CLNS can be transfered over GRE... Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 ___ 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] Private ASN
Is there a way to setup BGP with a customer using a private ASN and still be able to route that IP block over the internet? I am removing private ASN from leaving our network but I have not tested the implementation where traffic originating from Private AS can pass pass thru to the internet. Any ideas? Thanks Raman ___ 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] Ever-changing support for non Cisco branded transceivers
6500 with two 6704-10GE's, all non-Cisco branded XENPAKs except for one LW wan phy. Under SRA3, the non-Cisco's report unapproved but work, and DOM works: show interface status Te8/1 notconnect 1full10G unapproved Te8/2 notconnect 1full10G unapproved Te8/3 notconnect 1full10G unapproved Te8/4 notconnect 1full10G unapproved Te9/1 notconnect 1full10G unapproved Te9/2 notconnect 1full10G unapproved Te9/3 notconnect 1full10G 10Gbase-LW Te9/4 notconnect 1full10G unapproved show interface transceiver --- --- --- Te8/1 30.5 0.00 83.2 1.0 -40.0 Te8/2 30.0 0.00 31.6 -1.2 -40.0 Te8/3 29.4 0.00 33.0 -1.2 -40.0 Te8/4 26.1 0.00 32.9 -1.9 -40.0 Te9/1 30.8 0.00 80.0 0.6 -40.0 Te9/2 30.6 0.00 32.0 -1.4 -40.0 Te9/3 29.0 0.00 29.1 -- -2.1 -40.0 Te9/4 29.7 0.00 31.0 -1.2 -40.0 Same box, same config, immediately following an upgrade from SRA3 to SRA4. Now all of the non-Cisco xenpaks show up in show int status correctly, but DOM stops working: show interface status Te8/1 notconnect 1full10G 10Gbase-ER Te8/2 notconnect 1full10G 10Gbase-LR Te8/3 notconnect 1full10G 10Gbase-LR Te8/4 notconnect 1full10G 10Gbase-LR Te9/1 notconnect 1full10G 10Gbase-LR Te9/2 notconnect 1full10G 10Gbase-LR Te9/3 notconnect 1full10G 10Gbase-LW Te9/4 notconnect 1full10G 10Gbase-LR show interface transceiver --- --- --- Te9/3 31.0 0.00 29.6 -- -2.1 -40.0 Anyone have any idea whats going on here? Is this just a bug/oversight or intentional meddling with the non Cisco branded optics support. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] Best Routing Protocol for Scenario
Sure, checkout http://www.nexicom.net/~turbo/customernetwork.vsd It's in Visio... We want the voice traffic to take the T1's and the data traffic to take the bridged ADSL ethernet connections we have this working now using static routing but I want dynamic routing in place - trying to identify best dynamic routing protocol to use Someone suggested EIGRP which makes some sense...;) Thanks, Paul -Original Message- From: Rodney Dunn [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 8:38 AM To: Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Best Routing Protocol for Scenario Can you draw a jpeg that shows the layout? That's a lot easier than trying to draw it from email. Rodney On Thu, May 31, 2007 at 01:11:38PM -0400, Paul Stewart wrote: Hi folks... A while back (month or so) I posed a few questions about Policy Based Routing - thinking that was best way to conquer a new challenge... now I'm not so sure so looking for input. Here's the layout and what I want to accomplish Customer premise has a Cisco 3662 router. From the 3662 we have 2 TI's leaving and 2 Ethernet connections leaving towards a 6509 back in our data center. The 2 T1's go to a remote POP where they terminate on a Cisco 3640 router. The Cisco 3640 router connects to a Cisco 7206VXR which in turn connects via TLS back to the same 6509 in our data center. The ethernet connections leaving the customer site from the Cisco 3662 connect directly back to the 6509 with speeds of 6 Mb/s X 800Kb/s each. The T1's are full 1.544 Mb/s. So, one router at customer premise that needs to connect back to one router in our data center using 4 paths. The pair of T1's and the pair of ethernet ports should be bonded or load balanced. Traditionally this has been done via OSPF/CEF on our side of things. We want all VOIP traffic passing between the customer site and our data center to travel via the T1 circuits and all Internet traffic to go via the ethernet connections. I'm looking for the best routing protocol in this scenario that will allow me to use route-maps (or other alternatives) to identify source IP and destination IP subnets and apply priority. At the same time if the far end of each connection is unavailable then I want the traffic to fallover to the other connections as a backup automatically. I had though at one point that OSPF would be ideal but I'm not aware of a way to apply a route-map to OSPF specifying only certain traffic prefers a certain path. We do this all the time with BGP so I though maybe iBGP could be applied here but I have the feeling that there is a better solution Open to ideas and appreciate it... Paul ___ 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] Private ASN
You should be able to do it easily (sounds like you have it already setup). Check out this link http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009 3f27.shtml It explains what you are wanting to do. Joseph -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raman Sud Sent: Friday, June 01, 2007 10:53 AM To: cisco-nsp@puck.nether.net Cc: cisco-nsp@puck.nether.net Subject: [c-nsp] Private ASN Is there a way to setup BGP with a customer using a private ASN and still be able to route that IP block over the internet? I am removing private ASN from leaving our network but I have not tested the implementation where traffic originating from Private AS can pass pass thru to the internet. Any ideas? Thanks Raman ___ 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] Different bootldr and system versions
Sorry about the rapid-fire questions over the past few days. I can't seem to find an answer to this. I've got a newer system image, but not a bootloader for my 6509. I'm considering going from this: boot system flash sup-bootflash:c6sup22-psv-mz.121-19.E1.bin boot bootldr bootflash:c6msfc2-boot-mz.121-19.E1.bin To this: boot system flash disk0:c6sup22-psv-mz.121-26.E8.bin boot bootldr bootflash:c6msfc2-boot-mz.121-19.E1.bin Note the different versions above. Is this kosher? BTW, I think when I first started configuring this thing, I left the bootloader out entirely and it worked. Is that viable? Thanks, Rick Kunkel ___ 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] Private ASN
Sure, just remove the private ASN using the Cisco config to do so, and to the Internet it will look like the prefix originated from your ASN. Phil On Jun 1, 2007, at 1:52 PM, Raman Sud wrote: Is there a way to setup BGP with a customer using a private ASN and still be able to route that IP block over the internet? I am removing private ASN from leaving our network but I have not tested the implementation where traffic originating from Private AS can pass pass thru to the internet. Any ideas? Thanks Raman ___ 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] Private ASN
Thanks guys -Original Message- From: Phil Bedard [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 12:36 PM To: Raman Sud Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Private ASN Sure, just remove the private ASN using the Cisco config to do so, and to the Internet it will look like the prefix originated from your ASN. Phil On Jun 1, 2007, at 1:52 PM, Raman Sud wrote: Is there a way to setup BGP with a customer using a private ASN and still be able to route that IP block over the internet? I am removing private ASN from leaving our network but I have not tested the implementation where traffic originating from Private AS can pass pass thru to the internet. Any ideas? Thanks Raman ___ 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] APC Cabinets with SIde Air Distribution
On Fri, 1 Jun 2007, Rick Martin wrote: I am interested in what others are doing to accommodate hot isle/cold isle configurations with the cold isle in the front of the cabinet? As most of you are aware the fan tray on the 6500 is on the left side drawing cool air in the left and expelling hot air out the right. I believe the airflow in the non-NEBS 6509s is right to left. The fan tray pulls the air through the chassis rather than pushing it - makes for better airflow. I haven't used these specific cabinets, but in the past when I had gear that threw off a lot of heat, we rigged up some angled baffles between the cabinets to get the hot aisle/cold aisle arrangement and to keep the exhaust from one device from being drawing into devices in the adjacent cabinet. 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] APC Cabinets with SIde Air Distribution
The best solution for this is the 6509 NEB chassis. Failing that I've installed 6513's in 2 post racks rather than 4 post - as the attached cable management gave a good 6 or 8 inches of airspace. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Martin Sent: Friday, June 01, 2007 2:40 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] APC Cabinets with SIde Air Distribution We are in the process of a hardware refresh on our core network which will see about 10 Catalyst 6500's replace existing 6006's and older 6509's. All will have either Sup 720 or Sup 32. Hardware has been ordered and is arriving daily. I am interested in what others are doing to accommodate hot isle/cold isle configurations with the cold isle in the front of the cabinet? As most of you are aware the fan tray on the 6500 is on the left side drawing cool air in the left and expelling hot air out the right. With our current configuration we have cabinets with an outside measurement of 22 which leaves very little room for air flow on the sides, shortly after installing this equipment in 1999 we wound up removing the sides of all cabinets. Of course this resulted in the exhaust from one switch being drawn in the intake of the next. We want to fix this situation with this hardware refresh project and have been looking at the APC 29 wide cabinet (PN AR3150) with APC's Side Air Distribution Fan (PN ACF201BLK). Can anybody comment on this setup? Or perhaps offer different/better solutions for air flow management? Thanks for your comments, and or advice. Rick Martin Network Engineering Team Lead State of Arkansas, Department of Information Systems ___ 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] APC Cabinets with SIde Air Distribution
Correct, horizontal chassis have right to left airflow, exhausting hot air on the left. WRT cabinets, Panduit offers one that is designed to work with 6500 and converts airflow to front-back. See: http://www.panduit.com/products/brochures/105309.pdf Tim At 05:49 PM 6/1/2007 -0400, Justin M. Streiner opined: I believe the airflow in the non-NEBS 6509s is right to left. The fan tray pulls the air through the chassis rather than pushing it - makes for better airflow. Tim Stevenson, [EMAIL PROTECTED] Routing Switching CCIE #5561 Technical Marketing Engineer, Data Center BU Cisco Systems, 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/
