[c-nsp] RSP720 rommon images
Hi, Does anyone know where i can download the latest rommon images shown below? http://www.cisco.com/en/US/docs/routers/7600/rommon/rsp720_rommon.html#wp157863 I'm mostly interested in the following two: rsp720_rp-rm2.srec.122-33r.SRD2 rsp720_sp-rm2.srec.122-33r.SRD2 I found only SRB3 rommons on CCO, but i'm already using SRB4. -- 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/
Re: [c-nsp] BGP Hold Time Expired, but why?
Is this a GSR? --- On Tue, 22/7/08, Christian Koch [EMAIL PROTECTED] wrote: From: Christian Koch [EMAIL PROTECTED] Subject: Re: [c-nsp] BGP Hold Time Expired, but why? To: Oliver Boehmer (oboehmer) [EMAIL PROTECTED] Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Tuesday, 22 July, 2008, 1:58 AM same issue, no differences...got me On Sun, Jul 20, 2008 at 2:53 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: I don't know, but I would try it.. Looks weird.. oli -- *From:* Christian Koch [mailto:[EMAIL PROTECTED] *Sent:* Saturday, July 19, 2008 7:07 PM *To:* Oliver Boehmer (oboehmer) *Cc:* cisco-nsp *Subject:* Re: [c-nsp] BGP Hold Time Expired, but why? config look ok as far as i can see, i actually dont have bgp router-id set in the bgp config... you think if i add that with the loopback ip, it would make a difference? config router bgp 65000 no synchronization bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart bgp dampening neighbor Backbone peer-group neighbor Backbone remote-as 65000 neighbor Backbone update-source Loopback1 neighbor Backbone version 4 neighbor Backbone send-community neighbor 10.10.10.2 peer-group Backbone neighbor 10.10.10.3 peer-group Backbone no auto-summary On Sat, Jul 19, 2008 at 12:29 PM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: Hmm, %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol initialization looks unexpected, not sure what's happening.. just a hunch, but can you double-check your config regarding loopback addresses, bgp router-id and things? Possibly add some bgp debug (deb bgp all events, deb bgp all, deb bgp all keep) and see if something weird pops up? What does the neighbor's (10.10.10.3) log say? oli From: Christian Koch [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 3:08 PM To: Oliver Boehmer (oboehmer) Cc: cisco-nsp Subject: Re: [c-nsp] BGP Hold Time Expired, but why? hmm, i didnt check cef/mpls on the new path, i should try that.. there is connectivity between the loopbacks the session comes back up right after the timer expires.thats what puzzles me actually 3-4 is about how long i kept it down for.. Jul 16 14:29:22 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:22 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:22 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on TenGigabitEthernet2/2 from FULL to DOWN, Neighbor Down: Interface down or detached Jul 16 14:29:22 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is DOWN (Interface not operational) Jul 16 14:29:22 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:23 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:33 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is UP Jul 16 14:30:19 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on TenGigabitEthernet2/2 from LOADING to FULL, Loading Done Jul 16 14:30:37 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is DOWN (Discovery Hello Hold Timer expired) Jul 16 14:31:39 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is UP Jul 16 14:32:38 EDT: %BGP-3-NOTIFICATION: received from neighbor 10.10.10.3 4/0 (hold time expired) 0 bytes Jul 16 14:32:38 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol initialization Jul 16 14:32:45 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Up On Sat, Jul 19, 2008 at 3:24 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: No clue what's happening.. I've seen issues in the past with TCP PMTUD when the path converges over a link with a different MTU (which is happening in your case), but as BGP will not send packets larger than 4k, this shouldn't be an issue here. How long did you take down the link before bringing it back up? I assume longer than 3 minutes? Have you checked CEF and MPLS along the new path? You have IP connectivity between the loopbacks aR1 and bR2? Does the session come back up eventually, or will it stay down? oli Christian Koch wrote on Saturday, July 19, 2008 8:38 AM: sorry forgot to specify the bgp session from aR1 to bR2 is the session in question ck On Sat, Jul 19, 2008 at 2:21 AM, Christian Koch [EMAIL PROTECTED] wrote:
Re: [c-nsp] Transparent Proxy
On Tuesday 22 July 2008 00:16:02 Rhino Lists wrote: access-list 111 deny tcp any any neq www access-list 111 deny tcp host 192.168.1.188 any access-list 111 permit tcp any any log Try this for your ACL, instead: deny tcp host ip.of.squid.box any eq www permit tcp your.ip.net.block your.block.net.mask any eq www Obviously, make sure your (I'm assuming) Squid box is setup to properly capture the redirected packets and forward them to port it's listening on for processing. However, as others have noted, consider WCCP - it scales better. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] RSP720 rommon images
yeah, go to CCO download software router software platform RSP Type ROMMON http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=IOS%20ROMMON%20Softwaremdfid=268438002treeName=RoutersmdfLevel=Modelurl=nullmodelName=Cisco+7609+RouterisPlatform=NtreeMdfId=268437899modifmdfid=281939433imname=Cisco+7600+Series+Route+Switch+Processor+720+with+10+Gigabit+Ethernet+Uplinkshybrid=Yimst=Y On Tue, Jul 22, 2008 at 3:05 AM, Tassos Chatzithomaoglou [EMAIL PROTECTED] wrote: Hi, Does anyone know where i can download the latest rommon images shown below? http://www.cisco.com/en/US/docs/routers/7600/rommon/rsp720_rommon.html#wp157863 I'm mostly interested in the following two: rsp720_rp-rm2.srec.122-33r.SRD2 rsp720_sp-rm2.srec.122-33r.SRD2 I found only SRB3 rommons on CCO, but i'm already using SRB4. -- 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/
Re: [c-nsp] RSP720 rommon images
Christian, The only rommon available there is for the CEF720 67xx modules. -- Tassos Christian Koch wrote on 22/7/2008 2:58 μμ: yeah, go to CCO download software router software platform RSP Type ROMMON http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=IOS%20ROMMON%20Softwaremdfid=268438002treeName=RoutersmdfLevel=Modelurl=nullmodelName=Cisco+7609+RouterisPlatform=NtreeMdfId=268437899modifmdfid=281939433imname=Cisco+7600+Series+Route+Switch+Processor+720+with+10+Gigabit+Ethernet+Uplinkshybrid=Yimst=Y http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=IOS%20ROMMON%20Softwaremdfid=268438002treeName=RoutersmdfLevel=Modelurl=nullmodelName=Cisco+7609+RouterisPlatform=NtreeMdfId=268437899modifmdfid=281939433imname=Cisco+7600+Series+Route+Switch+Processor+720+with+10+Gigabit+Ethernet+Uplinkshybrid=Yimst=Y On Tue, Jul 22, 2008 at 3:05 AM, Tassos Chatzithomaoglou [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Does anyone know where i can download the latest rommon images shown below? http://www.cisco.com/en/US/docs/routers/7600/rommon/rsp720_rommon.html#wp157863 I'm mostly interested in the following two: rsp720_rp-rm2.srec.122-33r.SRD2 rsp720_sp-rm2.srec.122-33r.SRD2 I found only SRB3 rommons on CCO, but i'm already using SRB4. -- Tassos ___ cisco-nsp mailing list cisco-nsp@puck.nether.net mailto: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 Hold Time Expired, but why?
When you do show ip bgp nei detail while the sessions are flapping, Do you see anything wrong in the TCP parameters? I remember a bug in 12.0S where TCP window size becomes 0 for BGP causing it to flap. Or if it is an MTU problem you might see that the BGP Keepalives are being throttled. --- On Tue, 22/7/08, Christian Koch [EMAIL PROTECTED] wrote: From: Christian Koch [EMAIL PROTECTED] Subject: Re: [c-nsp] BGP Hold Time Expired, but why? To: Ozgur Guler [EMAIL PROTECTED] Cc: Oliver Boehmer (oboehmer) [EMAIL PROTECTED], cisco-nsp cisco-nsp@puck.nether.net Date: Tuesday, 22 July, 2008, 12:54 PM they are all 7609-S On Tue, Jul 22, 2008 at 5:25 AM, Ozgur Guler [EMAIL PROTECTED] wrote: Is this a GSR? --- On Tue, 22/7/08, Christian Koch [EMAIL PROTECTED] wrote: From: Christian Koch [EMAIL PROTECTED] Subject: Re: [c-nsp] BGP Hold Time Expired, but why? To: Oliver Boehmer (oboehmer) [EMAIL PROTECTED] Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Tuesday, 22 July, 2008, 1:58 AM same issue, no differences...got me On Sun, Jul 20, 2008 at 2:53 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: I don't know, but I would try it.. Looks weird.. oli -- *From:* Christian Koch [mailto:[EMAIL PROTECTED] *Sent:* Saturday, July 19, 2008 7:07 PM *To:* Oliver Boehmer (oboehmer) *Cc:* cisco-nsp *Subject:* Re: [c-nsp] BGP Hold Time Expired, but why? config look ok as far as i can see, i actually dont have bgp router-id set in the bgp config... you think if i add that with the loopback ip, it would make a difference? config router bgp 65000 no synchronization bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart bgp dampening neighbor Backbone peer-group neighbor Backbone remote-as 65000 neighbor Backbone update-source Loopback1 neighbor Backbone version 4 neighbor Backbone send-community neighbor 10.10.10.2 peer-group Backbone neighbor 10.10.10.3 peer-group Backbone no auto-summary On Sat, Jul 19, 2008 at 12:29 PM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: Hmm, %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol initialization looks unexpected, not sure what's happening.. just a hunch, but can you double-check your config regarding loopback addresses, bgp router-id and things? Possibly add some bgp debug (deb bgp all events, deb bgp all, deb bgp all keep) and see if something weird pops up? What does the neighbor's (10.10.10.3) log say? oli From: Christian Koch [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 3:08 PM To: Oliver Boehmer (oboehmer) Cc: cisco-nsp Subject: Re: [c-nsp] BGP Hold Time Expired, but why? hmm, i didnt check cef/mpls on the new path, i should try that.. there is connectivity between the loopbacks the session comes back up right after the timer expires.thats what puzzles me actually 3-4 is about how long i kept it down for.. Jul 16 14:29:22 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:22 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:22 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on TenGigabitEthernet2/2 from FULL to DOWN, Neighbor Down: Interface down or detached Jul 16 14:29:22 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is DOWN (Interface not operational) Jul 16 14:29:22 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:23 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:33 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is UP Jul 16 14:30:19 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on TenGigabitEthernet2/2 from LOADING to FULL, Loading Done Jul 16 14:30:37 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is DOWN (Discovery Hello Hold Timer expired) Jul 16 14:31:39 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is UP Jul 16 14:32:38 EDT: %BGP-3-NOTIFICATION: received from neighbor 10.10.10.3 4/0 (hold time expired) 0 bytes Jul 16 14:32:38 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol initialization Jul 16 14:32:45 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Up On Sat, Jul 19, 2008 at 3:24 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: No clue what's happening.. I've seen issues in the past with TCP PMTUD when the path converges over a link with a different MTU (which is happening in your case), but
Re: [c-nsp] BGP Hold Time Expired, but why?
nothing out of the norm, i will try in a few minutes to take the link down and snap a view though thanks On Tue, Jul 22, 2008 at 8:06 AM, Ozgur Guler [EMAIL PROTECTED] wrote: When you do show ip bgp nei detail while the sessions are flapping, Do you see anything wrong in the TCP parameters? I remember a bug in 12.0S where TCP window size becomes 0 for BGP causing it to flap. Or if it is an MTU problem you might see that the BGP Keepalives are being throttled. --- On *Tue, 22/7/08, Christian Koch [EMAIL PROTECTED]* wrote: From: Christian Koch [EMAIL PROTECTED] Subject: Re: [c-nsp] BGP Hold Time Expired, but why? To: Ozgur Guler [EMAIL PROTECTED] Cc: Oliver Boehmer (oboehmer) [EMAIL PROTECTED], cisco-nsp cisco-nsp@puck.nether.net Date: Tuesday, 22 July, 2008, 12:54 PM they are all 7609-S On Tue, Jul 22, 2008 at 5:25 AM, Ozgur Guler [EMAIL PROTECTED] wrote: Is this a GSR? --- On *Tue, 22/7/08, Christian Koch [EMAIL PROTECTED]* wrote: From: Christian Koch [EMAIL PROTECTED] Subject: Re: [c-nsp] BGP Hold Time Expired, but why? To: Oliver Boehmer (oboehmer) [EMAIL PROTECTED] Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Tuesday, 22 July, 2008, 1:58 AM same issue, no differences...got me On Sun, Jul 20, 2008 at 2:53 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: I don't know, but I would try it.. Looks weird.. oli -- *From:* Christian Koch [mailto:[EMAIL PROTECTED] *Sent:* Saturday, July 19, 2008 7:07 PM *To:* Oliver Boehmer (oboehmer) *Cc:* cisco-nsp *Subject:* Re: [c-nsp] BGP Hold Time Expired, but why? config look ok as far as i can see, i actually dont have bgp router-id set in the bgp config... you think if i add that with the loopback ip, it would make a difference? config router bgp 65000 no synchronization bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart bgp dampening neighbor Backbone peer-group neighbor Backbone remote-as 65000 neighbor Backbone update-source Loopback1 neighbor Backbone version 4 neighbor Backbone send-community neighbor 10.10.10.2 peer-group Backbone neighbor 10.10.10.3 peer-group Backbone no auto-summary On Sat, Jul 19, 2008 at 12:29 PM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: Hmm, %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol initialization looks unexpected, not sure what's happening.. just a hunch, but can you double-check your config regarding loopback addresses, bgp router-id and things? Possibly add some bgp debug (deb bgp all events, deb bgp all, deb bgp all keep) and see if something weird pops up? What does the neighbor's (10.10.10.3) log say? oli From: Christian Koch [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 3:08 PM To: Oliver Boehmer (oboehmer) Cc: cisco-nsp Subject: Re: [c-nsp] BGP Hold Time Expired, but why? hmm, i didnt check cef/mpls on the new path, i should try that.. there is connectivity between the loopbacks the session comes back up right after the timer expires.thats what puzzles me actually 3-4 is about how long i kept it down for.. Jul 16 14:29:22 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:22 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:22 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on TenGigabitEthernet2/2 from FULL to DOWN, Neighbor Down: Interface down or detached Jul 16 14:29:22 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is DOWN (Interface not operational) Jul 16 14:29:22 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to down Jul 16 14:29:23 EDT: %LINK-SP-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:23 EDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/2, changed state to up Jul 16 14:29:33 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (11) is UP Jul 16 14:30:19 EDT: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.2 on TenGigabitEthernet2/2 from LOADING to FULL, Loading Done Jul 16 14:30:37 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is DOWN (Discovery Hello Hold Timer expired) Jul 16 14:31:39 EDT: %LDP-5-NBRCHG: LDP Neighbor 10.10.10.2:0 (4) is UP Jul 16 14:32:38 EDT: %BGP-3-NOTIFICATION: received from neighbor 10.10.10.3 4/0 (hold time expired) 0 bytes Jul 16 14:32:38 EDT: %BGP-5-ADJCHANGE: neighbor 10.10.10.3 Down BGP protocol initialization Jul 16 14:32:45 EDT:
[c-nsp] VPN Question - IOS
Hi there... We have a remote access VPN configuration deployed on a 2800 router everything works great except I'd like to force VPN users to send all their traffic via the VPN when connected. I'm missing something obvious I believe... Example would be once a VPN user is connected and opens an SSH session to a router, I want that SSH session to come via the VPN router's IP address - not their home IP address. 192.192.61.0/24 is our internal LAN network - yeah yeah, I know... this was setup by a networking expert long before my time...:( Config looks like this: crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 ! crypto isakmp client configuration group RemoteAccess key dns xxx wins x domain xxx pool VPNPool1 acl 100 save-password include-local-lan netmask 255.255.255.0 crypto isakmp profile VPN-Profile match identity group RemoteAccess client authentication list vpn_xauth1 isakmp authorization list vpn_group1 client configuration address respond virtual-template 2 ! ! crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! crypto ipsec profile VPN-Profile set transform-set ESP-3DES-SHA set isakmp-profile VPN-Profile interface Virtual-Template2 type tunnel ip unnumbered Loopback1 tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN-Profile ip local pool VPNPool1 192.168.250.2 192.168.250.254 access-list 100 permit ip 192.192.61.0 0.0.0.255 any access-list 100 permit ip 192.168.250.0 0.0.0.255 any This has something to do with split tunneling and the ACL 100 but so far I haven't got this working Thanks very much, 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/
Re: [c-nsp] VPN Question - IOS
Hello, try removing the following lines: acl 100 include-local-lan netmask 255.255.255.0 The IP address that will be used is the one assigned by the pool VPNPool1, unless you configure some kind of NAT translation BR, John On Tue, 22 Jul 2008, Paul Stewart wrote: Hi there... We have a remote access VPN configuration deployed on a 2800 router everything works great except I'd like to force VPN users to send all their traffic via the VPN when connected. I'm missing something obvious I believe... Example would be once a VPN user is connected and opens an SSH session to a router, I want that SSH session to come via the VPN router's IP address - not their home IP address. 192.192.61.0/24 is our internal LAN network - yeah yeah, I know... this was setup by a networking expert long before my time...:( Config looks like this: crypto isakmp client configuration group RemoteAccess key dns xxx wins x domain xxx pool VPNPool1 acl 100 save-password include-local-lan netmask 255.255.255.0 crypto isakmp profile VPN-Profile match identity group RemoteAccess client authentication list vpn_xauth1 isakmp authorization list vpn_group1 client configuration address respond virtual-template 2 ! This has something to do with split tunneling and the ACL 100 but so far I haven't got this working Thanks very much, 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] VPN Question - IOS
On Tue, 22 Jul 2008, Paul Stewart wrote: We have a remote access VPN configuration deployed on a 2800 router everything works great except I'd like to force VPN users to send all their traffic via the VPN when connected. I'm missing something obvious I believe... Example would be once a VPN user is connected and opens an SSH session to a router, I want that SSH session to come via the VPN router's IP address - not their home IP address. 192.192.61.0/24 is our internal LAN network - yeah yeah, I know... this was setup by a networking expert long before my time...:( Sounds like you want to disable split tunneling. With split tunneling, only traffic you define as interesting is sent over the VPN, and everything else follows the normal default route from the user's PC, presumably over their regular Internet connection. jms Config looks like this: crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 ! crypto isakmp client configuration group RemoteAccess key dns xxx wins x domain xxx pool VPNPool1 acl 100 save-password include-local-lan netmask 255.255.255.0 crypto isakmp profile VPN-Profile match identity group RemoteAccess client authentication list vpn_xauth1 isakmp authorization list vpn_group1 client configuration address respond virtual-template 2 ! ! crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! crypto ipsec profile VPN-Profile set transform-set ESP-3DES-SHA set isakmp-profile VPN-Profile interface Virtual-Template2 type tunnel ip unnumbered Loopback1 tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN-Profile ip local pool VPNPool1 192.168.250.2 192.168.250.254 access-list 100 permit ip 192.192.61.0 0.0.0.255 any access-list 100 permit ip 192.168.250.0 0.0.0.255 any This has something to do with split tunneling and the ACL 100 but so far I haven't got this working Thanks very much, 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] ME6524 alternative
Rubens Kuhl Jr. wrote: Cost issues and the relationship wit the local subsidiary; we have very little problems with the ME6500, one being the BFD with SVIs issue that you don't like either if I recall correctly. Cost is high but it can cut both ways. That leads to a long discussion for another day and I'm sure you're already familiar with all the talking points. The BFD on SVIs is definitely something that bit me on all my SX/SR platforms. I still don't have a working solution for that problem. Are you sure ME3750s are doing good for your network ? We had tons of issues with 3750-Metro, a product that I strongly recommend for my competitors... we haven't tested ME3400 which sound very nice (but doesn't have MPLS) or 4500 with Sup-VI (no MPLS on the software yet). We haven't had any problems with them. I just returned from the MetroE training course in SJC and the ME3750 played an important role in the course. It worked fine in the class. I think it's important that people understand what the ME devices were designed for and deploy them with that in mind. This is something that I failed at initially. The ME3750 wasn't designed to be a generic DC-powered L3 switch. It was purpose-built for L2VPN termination and some aggregation. When people like myself think that it's an all-encompassing MPLS box then they get sorely disappointed. I was. But it works well for what it was designed to do. 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] ME6524 alternative
Cost issues and the relationship wit the local subsidiary; we have very little problems with the ME6500, one being the BFD with SVIs issue that you don't like either if I recall correctly. Cost is high but it can cut both ways. That leads to a long discussion for another day and I'm sure you're already familiar with all the talking points. Yeap, but we've got a 3x price hike on the ME6500 from our initial purchase to current quotes, which left us no choice but to evaluate alternatives. The BFD on SVIs is definitely something that bit me on all my SX/SR platforms. I still don't have a working solution for that problem. I would really love to just hear what Cisco says about why BFD on SVIs are a bad thing. They might have a good point. Are you sure ME3750s are doing good for your network ? We had tons of issues with 3750-Metro, a product that I strongly recommend for my competitors... we haven't tested ME3400 which sound very nice (but doesn't have MPLS) or 4500 with Sup-VI (no MPLS on the software yet). We haven't had any problems with them. I just returned from the MetroE training course in SJC and the ME3750 played an important role in the course. It worked fine in the class. I think it's important that people understand what the ME devices were designed for and deploy them with that in mind. This is something that I failed at initially. The ME3750 wasn't designed to be a generic DC-powered L3 switch. It was purpose-built for L2VPN termination and some aggregation. When people like myself think that it's an all-encompassing MPLS box then they get sorely disappointed. I was. But it works well for what it was designed to do. It's good to know that Cisco changed the speech regarding this product. I think that if one uses only as PE (no other P or PEs relying on it for LDP of a critical backbone), and it uses only 2 uplinks (no ring or mesh, two uplinks to a P backbone), no L3VPN, it might work. In the mean time, I'm glad that all the 3750-Metro we've got were operational leases: we will return them all, so I won't have to write [EMAIL PROTECTED]@ on the customer satisfaction surveys anymore. Rubens ___ 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] L2 switch needs: 2960G vs 3560G
I'm looking for a 24-port GigE 1RU layer 2 switch, and comparing the 3560G-24TS to a C2960G-24TC-L. They seem to have similar backplane, and similar pps forwarding. I just need L2. They seem pretty similar on paper, except the 3560 is a almost double the price of the 2960. Any reason to get the 3560? -- 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/
Re: [c-nsp] L2 switch needs: 2960G vs 3560G
Deny IP Any Any wrote: I'm looking for a 24-port GigE 1RU layer 2 switch, and comparing the 3560G-24TS to a C2960G-24TC-L. They seem to have similar backplane, and similar pps forwarding. I just need L2. They seem pretty similar on paper, except the 3560 is a almost double the price of the 2960. Any reason to get the 3560? I don't think so. The main selling point on the 3xxx series versus the 2xxx series is Layer 3 switching. Peace... Sridhar ___ 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] L2 switch needs: 2960G vs 3560G
The 3560 includes Dynamic Arp Inspection and IP Source Guard, but the 2960 does not. Kyle Deny IP Any Any wrote: I'm looking for a 24-port GigE 1RU layer 2 switch, and comparing the 3560G-24TS to a C2960G-24TC-L. They seem to have similar backplane, and similar pps forwarding. I just need L2. They seem pretty similar on paper, except the 3560 is a almost double the price of the 2960. Any reason to get the 3560? ___ 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] ME6524 alternative
Rubens Kuhl Jr. wrote: Yeap, but we've got a 3x price hike on the ME6500 from our initial purchase to current quotes, which left us no choice but to evaluate alternatives. Ouch. Are you dealing with a partner or Cisco Direct? There isn't any excuse for the price to go up, period. If you like I could hook you up with our Cisco Direct guys. If you got your order in this week you might be a decent discount simply because their fiscal year ends this month and the sales folks are hungry. The BFD on SVIs is definitely something that bit me on all my SX/SR platforms. I still don't have a working solution for that problem. I would really love to just hear what Cisco says about why BFD on SVIs are a bad thing. They might have a good point. What I was told was that it was an unintended feature. Basically that means that while it worked it wasn't ever part of the intended design and wasn't ever tested. It could have adverse affects on other things; then again it also might not affect anything. They simply wouldn't know unless they incorporated that into the QA procedures and there has to be demand for that to happen. So tell your account team every chance you get. In fact I would recommend having your account team hook you up on a call with the product manager responsible for BFD support on your hardware and ask for it yourself (because often times I think requests like that tend to get overlooked). It's good to know that Cisco changed the speech regarding this product. I think that if one uses only as PE (no other P or PEs relying on it for LDP of a critical backbone), and it uses only 2 uplinks (no ring or mesh, two uplinks to a P backbone), no L3VPN, it might work. In the mean time, I'm glad that all the 3750-Metro we've got were operational leases: we will return them all, so I won't have to write [EMAIL PROTECTED]@ on the customer satisfaction surveys anymore. Yeah, it's good to know what they're meant for. I was thinking like a dumbass when I bought a pair of ME6524s for the core in a very small pop. I didn't know much about the underlying platform and didn't even think about the TCAM on that box. I was just thinking that they'd be a decent device for the price and throughput in that small POP and that they didn't need to be too fancy. I ran out of TCAM back in January when the global route table exceeded the Sup2's limited reach. I'll be replacing them in the future and pushing them closer to the edge where they belong. The ME3750 was really meant primarily as a PE device but also as a P in a MetroE access ring. In our training lab the ME3750 was used mainly as the access edge. Most of the labs used it as a L2 edge switch essentially but a few labs had us extended the IGP to it, enable MPLS and push VCs all the way to it. It worked fine, except for when I skipped an important step in the instructions... They intended for it to be deployed in GigE rings too. As they put it in the class, fiber is expensive. You can't home-run every PE to an aggregation router. It's just not cost-effective or reasonable. But it is cost-effective to have half a dozen of them ringed together and home-run the edges back to the aggregation layer (ME6524s or larger hardware. In fact much of the class dealt with building the access ring, tuning STP/RSTP/MST, etc. It's a good class if you're interested. 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/
[c-nsp] Cisco 6500 Chassis PDU
I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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] Native and management VLAN confusion
Hi everyone, We have a scenario regarding VLANs in which I'm confused as to how to access the remote switches: COE 2924 XL native vlan 1 | | trunk | vlans 500, 501, 502 | | intermediary network 5500 / |\ /| \ trunk trunktrunk /| \ CPECPE2 CPE3 2924 XL2924XL 2924XL vlan 500 vlan 501 vlan 502 Untagged traffic does not pass from CPE to COE through the intermediary. I'm confused as to how I need to configure things VLAN-wise in order to be able to remotely manage the CPE switches from the CO, through the independent intermediary. The native and management VLAN is 1 on the CPE side. Could someone point me in the direction on the most appropriate way to make the CPE gear reachable? Thanks, 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/
Re: [c-nsp] Native and management VLAN confusion
Hi Steve... Traditionally (if possible) you would have separate management VLAN's to each site for management purposes. The intermediary is most likely not permitting VLAN1 and/or untagged traffic (quite common). Hope this helps... Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bertrand Sent: Tuesday, July 22, 2008 4:42 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Native and management VLAN confusion Hi everyone, We have a scenario regarding VLANs in which I'm confused as to how to access the remote switches: COE 2924 XL native vlan 1 | | trunk | vlans 500, 501, 502 | | intermediary network 5500 / |\ /| \ trunk trunktrunk /| \ CPECPE2 CPE3 2924 XL2924XL 2924XL vlan 500 vlan 501 vlan 502 Untagged traffic does not pass from CPE to COE through the intermediary. I'm confused as to how I need to configure things VLAN-wise in order to be able to remotely manage the CPE switches from the CO, through the independent intermediary. The native and management VLAN is 1 on the CPE side. Could someone point me in the direction on the most appropriate way to make the CPE gear reachable? Thanks, 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] ME6524 alternative
Ouch. Are you dealing with a partner or Cisco Direct? There isn't any excuse for the price to go up, period. If you like I could hook you up with our Cisco Direct guys. If you got your order in this week you might be a decent discount simply because their fiscal year ends this month and the sales folks are hungry. Thru partner. Cisco insists to tell us that there is no Cisco Direct in our country, although I know there is and know some customers that use such channel. The partner is trying very hard to sell us this month, but they can only work on their margins. The BFD on SVIs is definitely something that bit me on all my SX/SR platforms. I still don't have a working solution for that problem. I would really love to just hear what Cisco says about why BFD on SVIs are a bad thing. They might have a good point. What I was told was that it was an unintended feature. Basically that means that while it worked it wasn't ever part of the intended design and wasn't ever tested. It could have adverse affects on other things; then again it also might not affect anything. They simply wouldn't know unless they incorporated that into the QA procedures and there has to be demand for that to happen. So tell your account team every chance you get. In fact I would recommend having your account team hook you up on a call with the product manager responsible for BFD support on your hardware and ask for it yourself (because often times I think requests like that tend to get overlooked). They seem to be listening about this, but the only real measure is the latency till it's implemented. It's good to know that Cisco changed the speech regarding this product. I think that if one uses only as PE (no other P or PEs relying on it for LDP of a critical backbone), and it uses only 2 uplinks (no ring or mesh, two uplinks to a P backbone), no L3VPN, it might work. In the mean time, I'm glad that all the 3750-Metro we've got were operational leases: we will return them all, so I won't have to write [EMAIL PROTECTED]@ on the customer satisfaction surveys anymore. Yeah, it's good to know what they're meant for. I was thinking like a dumbass when I bought a pair of ME6524s for the core in a very small pop. I didn't know much about the underlying platform and didn't even think about the TCAM on that box. I was just thinking that they'd be a decent device for the price and throughput in that small POP and that they didn't need to be too fancy. I ran out of TCAM back in January when the global route table exceeded the Sup2's limited reach. I'll be replacing them in the future and pushing them closer to the edge where they belong. That's the only place in the network we have 7600s with PFC XL... but you could try filtering some routes down to the non-XL TCAM capacity and pointing a default route to the these prefixes. The ME3750 was really meant primarily as a PE device but also as a P in a MetroE access ring. In our training lab the ME3750 was used mainly as the After the MPLS bugs we've seen here, you wouldn't even try using it as P even for the ring only. May be the 3750 IP Services, with no MPLS, combined with 2 ME6524 on the ring would be a good fit. That's the option we're exploring for some cities where we can do ring-only: using L2 (Extreme Summit X150 is the most likely candidate, but Cisco ME3400 with METROACCESS would do the job if one prefers to stick to Cisco); some cities are too complex to cover with ring-only, so in those we need full L3/MPLS. access edge. Most of the labs used it as a L2 edge switch essentially but a few labs had us extended the IGP to it, enable MPLS and push VCs all the way Humm, 3750s do L2 like a charm... to it. It worked fine, except for when I skipped an important step in the instructions... They intended for it to be deployed in GigE rings too. As they put it in the class, fiber is expensive. You can't home-run every PE to an aggregation router. It's just not cost-effective or reasonable. But But then you need a PE you can trust for being a P, even for a limited number of PEs. it is cost-effective to have half a dozen of them ringed together and home-run the edges back to the aggregation layer (ME6524s or larger hardware. In fact much of the class dealt with building the access ring, tuning STP/RSTP/MST, etc. It's a good class if you're interested. I think such rings would be better served by using REP (Cisco) or EAPS(Extreme); ME6524 doesn't support REP today, but that's probably just one version away. Rubens ___ 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] Cisco 6500 Chassis PDU
On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. Note that most of my stuff is not in areas with raised floors, so power and data usually need to feed in from the top of the cabinet/relay rack. Right now, I'm just pulling two pairs of 208V/20A circuits in L6-20 receptacles above the cabinet where the 6509 will be located. One pair comes off of a generator-backed/line-conditioned emergency power panel and the other pair comes off of a UPS output panel. I do use PDUs smaller gear that will live in the same cabinet and I normally feed these from 120V/30A circuit, presented as an L5-30 receptacle above the cabinet. I'll pull one of these from an emergency power panel and one from a UPS panel and drop a PDU from each into each cabinet, so single-powered boxes can be run from either and dual-powered boxes can be run from both normal/emergency and UPS power. 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] Cisco 6500 Chassis PDU
On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. If you do want your 6509s to be fed from PDUs, there are several vendors out there that make them, with varying levels of bells and whistles, i.e. everything from 'dumb' rackmountable power strips to intelligent PDUs with dual inputs, built-in automatic transfer switches, and remote management/ monitoring options. The following vendors (not an all-inclusive list, and there options may differ if you need AC or DC power) have stuff that you may want to look at: Tripp Lite APC ADC (mostly DC kit) Eaton Liebert 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] Cisco 6500 Chassis PDU
On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. On a similar note, I'm about to turn up a few 6500s using DC power. Since we run our own DC plant, we have the option of running the power through local (to the racks where the 6500s are) DC fuse panels or directly from the DC breakers which are off in another part of the facility. I'm used to (in other colo environments) always getting DC power through a local fuse panel. I like the idea that if the wiring needs to be disconnected for any reason, it's easy to pull the appropriate fuse (and know that it's remained pulled) while working on the wiring. Others are saying it's just fine to go direct from the remote breakers into the gear. Relying on a breaker in another room, that someone else might flip without your knowledge, seems like a recipe for getting hurt. Does anyone actually do this? -- 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] Cisco 6500 Chassis PDU
While I'm no expert on power, we always have a panel near the equipment even when we own most facilities we are located in. Also a nice safety factor if you think the breaker is pulled you don't have to worry about someone accidently putting it back online ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Lewis Sent: Tuesday, July 22, 2008 6:40 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. On a similar note, I'm about to turn up a few 6500s using DC power. Since we run our own DC plant, we have the option of running the power through local (to the racks where the 6500s are) DC fuse panels or directly from the DC breakers which are off in another part of the facility. I'm used to (in other colo environments) always getting DC power through a local fuse panel. I like the idea that if the wiring needs to be disconnected for any reason, it's easy to pull the appropriate fuse (and know that it's remained pulled) while working on the wiring. Others are saying it's just fine to go direct from the remote breakers into the gear. Relying on a breaker in another room, that someone else might flip without your knowledge, seems like a recipe for getting hurt. Does anyone actually do this? -- 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM ___ 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] 7600 vs MX experience?
But, what can folks tell me about shared support in general? I always thought it was Smartnet or nothing hence why I'm asking... is this 3rd party Cisco support that I've seen advertised a few times? Shared Support is a service that Cisco sels to a tier 1 partner, and that partner then sells some service to the customer (that service must not be branded 'Cisco shared support'). The partner in all practical sense functions as the TAC and RMA department for the customer. (The customer, for example, cannot open a TAC case with Cisco directly). Cisco Shared Support is obviously much cheaper for the partner to buy from Cisco than SMARTnet (since they have to do much of the work themselves), but whether the customer is getting cheaper (and/or better!) service, varies with the partner. -A (Who works for a small tier 1 Cisco partner in Denmark) ___ 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] Cisco 6500 Chassis PDU
For what it's worth... We use a lot of APC for our AC powered equipment - really like it much better than Tripplite in particular Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin M. Streiner Sent: Tuesday, July 22, 2008 5:47 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. If you do want your 6509s to be fed from PDUs, there are several vendors out there that make them, with varying levels of bells and whistles, i.e. everything from 'dumb' rackmountable power strips to intelligent PDUs with dual inputs, built-in automatic transfer switches, and remote management/ monitoring options. The following vendors (not an all-inclusive list, and there options may differ if you need AC or DC power) have stuff that you may want to look at: Tripp Lite APC ADC (mostly DC kit) Eaton Liebert 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM ___ 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] Cisco 6500 Chassis PDU
I believe I have determined how big of a circuit I will need, as long as my calculations are correct. So it looks like I will need 2 30amp pdu's to support 2 6509-E chassis. Did I miss anything? Current Utilization 6509E Module Amps (250vdc) Amps (208vdc) Max Watts Comments VS-S720-10G-3C 1.69052 2.031875 422.63 Sup WS-X6748-GE-TX 1.47 1.766826923 367.50 Switch WS-SVC-FWM-1-K9 0.85892 1.032355769 214.73 Firewall ACE10-6500-K9 1.09832 1.320096154 274.58 NLB WS-C6509-E-FAN 0.84 1.009615385 210.00 Fan Totals 5.95776 7.160769231 1,489.44 Projected Utilization 6509E Module Amps (250vdc) Amps (208vdc) Max Watts Comments VS-S720-10G-3C 1.69052 2.031875 422.63 Sup WS-X6748-GE-TX 1.47 1.766826923 367.50 Switch WS-X6748-GE-TX 1.47 1.766826923 367.50 Switch WS-SVC-FWM-1-K9 0.85892 1.032355769 214.73 Firewall ACE10-6500-K9 1.09832 1.320096154 274.58 NLB WS-SVC-WISM-1-K9 1.02 1.225961538 255.00 Wireless WS-C6509-E-FAN 0.84 1.009615385 210.00 Fan Totals 8.44776 10.15355769 2,111.94 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, July 22, 2008 4:11 PM To: 'Justin M. Streiner'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU For what it's worth... We use a lot of APC for our AC powered equipment - really like it much better than Tripplite in particular Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin M. Streiner Sent: Tuesday, July 22, 2008 5:47 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. If you do want your 6509s to be fed from PDUs, there are several vendors out there that make them, with varying levels of bells and whistles, i.e. everything from 'dumb' rackmountable power strips to intelligent PDUs with dual inputs, built-in automatic transfer switches, and remote management/ monitoring options. The following vendors (not an all-inclusive list, and there options may differ if you need AC or DC power) have stuff that you may want to look at: Tripp Lite APC ADC (mostly DC kit) Eaton Liebert 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM ___ 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/ # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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] Cisco 6500 Chassis PDU
I believe I have determined how big of a circuit I will need, as long as my calculations are correct. So it looks like I will need 2 30amp pdu's to support 2 6509-E chassis. Did I miss anything? Current Utilization 6509E ModuleAmps (250vdc) Amps (208vdc) Max Watts Comments VS-S720-10G-3C 1.69052 2.031875422.63 Sup WS-X6748-GE-TX 1.471.766826923 367.50 Switch WS-SVC-FWM-1-K9 0.85892 1.032355769 214.73 Firewall ACE10-6500-K9 1.09832 1.320096154 274.58 NLB WS-C6509-E-FAN 0.841.009615385 210.00 Fan Totals 5.95 amps 7.16 amps 1,489.44 watts Projected Utilization 6509E ModuleAmps (250vdc) Amps (208vdc) Max Watts Comments VS-S720-10G-3C 1.69052 2.031875422.63 Sup WS-X6748-GE-TX 1.471.766826923 367.50 Switch WS-X6748-GE-TX 1.471.766826923 367.50 Switch WS-SVC-FWM-1-K9 0.85892 1.032355769 214.73 Firewall ACE10-6500-K9 1.09832 1.320096154 274.58 NLB WS-SVC-WISM-1-K91.021.225961538 255.00 Wireless WS-C6509-E-FAN 0.841.009615385 210.00 Fan Totals 8.44 amps 10.15 amps 2,111.94 watts -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, July 22, 2008 4:11 PM To: 'Justin M. Streiner'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU For what it's worth... We use a lot of APC for our AC powered equipment - really like it much better than Tripplite in particular Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin M. Streiner Sent: Tuesday, July 22, 2008 5:47 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. If you do want your 6509s to be fed from PDUs, there are several vendors out there that make them, with varying levels of bells and whistles, i.e. everything from 'dumb' rackmountable power strips to intelligent PDUs with dual inputs, built-in automatic transfer switches, and remote management/ monitoring options. The following vendors (not an all-inclusive list, and there options may differ if you need AC or DC power) have stuff that you may want to look at: Tripp Lite APC ADC (mostly DC kit) Eaton Liebert 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM ___ 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/ # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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] Cisco 6500 Chassis PDU
Another data point: We power each of our 6509's using two 2500W power supplies. We've got 2-pole 20A 208V breakers for each of those supplies. Left-side is UPS/emergency, and right-side is normal power, each into the outlet. Now, in our remote sites, we opted to use remote-switchable PDU's (APC) to take care of cold booting, again with the same-size circuits. On Tue, 22 Jul 2008, Teller, Robert wrote: I believe I have determined how big of a circuit I will need, as long as my calculations are correct. So it looks like I will need 2 30amp pdu's to support 2 6509-E chassis. Did I miss anything? Current Utilization 6509E Module Amps (250vdc) Amps (208vdc) Max Watts Comments VS-S720-10G-3C 1.69052 2.031875 422.63 Sup WS-X6748-GE-TX 1.47 1.766826923 367.50 Switch WS-SVC-FWM-1-K9 0.85892 1.032355769 214.73 Firewall ACE10-6500-K9 1.09832 1.320096154 274.58 NLB WS-C6509-E-FAN 0.84 1.009615385 210.00 Fan Totals 5.95776 7.160769231 1,489.44 Projected Utilization 6509E Module Amps (250vdc) Amps (208vdc) Max Watts Comments VS-S720-10G-3C 1.69052 2.031875 422.63 Sup WS-X6748-GE-TX 1.47 1.766826923 367.50 Switch WS-X6748-GE-TX 1.47 1.766826923 367.50 Switch WS-SVC-FWM-1-K9 0.85892 1.032355769 214.73 Firewall ACE10-6500-K9 1.09832 1.320096154 274.58 NLB WS-SVC-WISM-1-K9 1.02 1.225961538 255.00 Wireless WS-C6509-E-FAN 0.84 1.009615385 210.00 Fan Totals 8.44776 10.15355769 2,111.94 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Tuesday, July 22, 2008 4:11 PM To: 'Justin M. Streiner'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU For what it's worth... We use a lot of APC for our AC powered equipment - really like it much better than Tripplite in particular Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin M. Streiner Sent: Tuesday, July 22, 2008 5:47 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500 Chassis PDU On Tue, 22 Jul 2008, Teller, Robert wrote: I am in the process of installing two Cisco 6500 chassis and was curious what types of PDU's people are using. If you do want your 6509s to be fed from PDUs, there are several vendors out there that make them, with varying levels of bells and whistles, i.e. everything from 'dumb' rackmountable power strips to intelligent PDUs with dual inputs, built-in automatic transfer switches, and remote management/ monitoring options. The following vendors (not an all-inclusive list, and there options may differ if you need AC or DC power) have stuff that you may want to look at: Tripp Lite APC ADC (mostly DC kit) Eaton Liebert 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.3/1565 - Release Date: 7/21/2008 6:36 PM ___ 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/ # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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/ wfms ___ 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] ME6524 alternative
On Wednesday 23 July 2008 03:26:26 Justin Shore wrote: What I was told was that it was an unintended feature. Basically that means that while it worked it wasn't ever part of the intended design and wasn't ever tested. It could have adverse affects on other things; then again it also might not affect anything. They simply wouldn't know unless they incorporated that into the QA procedures and there has to be demand for that to happen. So tell your account team every chance you get. In fact I would recommend having your account team hook you up on a call with the product manager responsible for BFD support on your hardware and ask for it yourself (because often times I think requests like that tend to get overlooked). It's been a couple of weeks since I bugged our account team for it. Perhaps I should send another reminder :-)... Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] Need advise on Cisco Switch/Fibre Connectivity
Hi guys, Need some advise. I am looking to acquire some 24 port ethernet LAN switches that also have fibre connectors. The fibre connections are going to be long distance (apprx 5km ++) and single mode . I was looking at the cisco website, and think the Catalyst 3750 series might fit the need. The product data sheet says it supports the following connectors: 1000BASE-SX, -LX/LH, -ZX, and CWDM SFP-based ports: LC fiber connectors (single- mode, or multimode fiber) I believe we would need to order the switch toghether with these additional connectors? Am i right in this? Would this switch fit my basic needs for fibre connectivity? Thanks! Nimal ___ 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] Need advise on Cisco Switch/Fibre Connectivity
Any special requirements for the switch? 3750 seems like a bit of overkill in my opinion but it depends on what you want the switch to do? If you're just looking for 24 ports 10/100 and a fiber uplink then a 2960 would work just as well for basic switch requirements... the SFP determines that kind of fiber connectors, and mode.. in this case single mode LX (1000BASE-LX) sounds like all you need for 5km especially http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/product_da ta_sheet0900aecd80322c0c.html Hope this helps... Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nimal David Sirimanne Sent: Tuesday, July 22, 2008 10:54 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Need advise on Cisco Switch/Fibre Connectivity Hi guys, Need some advise. I am looking to acquire some 24 port ethernet LAN switches that also have fibre connectors. The fibre connections are going to be long distance (apprx 5km ++) and single mode . I was looking at the cisco website, and think the Catalyst 3750 series might fit the need. The product data sheet says it supports the following connectors: 1000BASE-SX, -LX/LH, -ZX, and CWDM SFP-based ports: LC fiber connectors (single- mode, or multimode fiber) I believe we would need to order the switch toghether with these additional connectors? Am i right in this? Would this switch fit my basic needs for fibre connectivity? Thanks! Nimal ___ 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] 3750's, 7200 NPE-G1 and GEC advice
Hi, Just after some best practice advice on the following: We have two 3750's(3750E-24TD-S) stacked, and a 7200 w/NPE -G1 - We are wanting to connect two of the GigE ports of the NPE to both 3750's(In case one switch fails) - We currently have it setup as port-channels, which is working fine, but wanted to confirm if this was the correct method to achieve redundancy, and also additional bandwidth between the 3750's + 7200. During minimal testing, we lose ~2 packets if a cable is disconnected(If the session(ping) is running over that cable) - Is there anyway to reduce this? Any suggestions are greatly appreciated. Current conf.. 7200: ! interface Port-channel1 description GEC_to_3750s no ip address duplex full hold-queue 150 in ! interface GigabitEthernet0/1 description TO_3750_1_0_24 no ip address duplex full speed auto media-type rj45 negotiation auto channel-group 1 ! interface GigabitEthernet0/2 description TO_3750_2_0_24 no ip address duplex full speed auto media-type rj45 negotiation auto channel-group 1 ! 3750s: interface Port-channel1 description GEC_to_7200 switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet1/0/24 description TO_7200_GE_0_1 switchport trunk encapsulation dot1q duplex full channel-group 1 mode on spanning-tree portfast ! interface GigabitEthernet2/0/24 description TO_7200_GE_0_2 switchport trunk encapsulation dot1q duplex full channel-group 1 mode on spanning-tree portfast - This e-mail was sent via Data FX Online WebMail http://www.datafx.com.au/ ___ 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] combining multiple dsl lines
I have a customer that is wanting to combine 4 adsl connection through one router. In the past I have setup systems where I have taken groups of ip's from the internal network and have route-map'd them to different adsl connections. Is there a way to combine the dsl connections or is using route-map's still the better way to go? 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/
Re: [c-nsp] combining multiple dsl lines
Depends a lot on the adsl connections, are they ppp ? does the remote end support multilink? if so then multilink ppp is a good option providing all 4 lines are the same characteristics. Otherwise other options are cef load balancing, what type will depend on whether you are using NAT or not as you want to make sure the packet flow takes the right path, load balancing using the source/dest port algorithm works quite well though, probably wouldn't reccomend per packet over adsl. The route-map way is ok but wouldn't utilise the links as well as cef load balancing or ppp multlink could. Another option worth throwing in is the use of ip sla on your routes so as to remove them from the equation should one link go down, can also be done with the route-map using verify-availability on the next- hop option. Ben On 23/07/2008, at 1:39 PM, Dan Letkeman wrote: I have a customer that is wanting to combine 4 adsl connection through one router. In the past I have setup systems where I have taken groups of ip's from the internal network and have route-map'd them to different adsl connections. Is there a way to combine the dsl connections or is using route-map's still the better way to go? 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/
Re: [c-nsp] 3750's, 7200 NPE-G1 and GEC advice
Hi, I'll do the same thing as what you've done to achieve that. Anyway 2 packets loss mean 2 second (normal windows ping ?) or 2000 ms.. rgs a. rahman isnaini r.sutan [EMAIL PROTECTED] wrote: Hi, Just after some best practice advice on the following: We have two 3750's(3750E-24TD-S) stacked, and a 7200 w/NPE -G1 - We are wanting to connect two of the GigE ports of the NPE to both 3750's(In case one switch fails) - We currently have it setup as port-channels, which is working fine, but wanted to confirm if this was the correct method to achieve redundancy, and also additional bandwidth between the 3750's + 7200. During minimal testing, we lose ~2 packets if a cable is disconnected(If the session(ping) is running over that cable) - Is there anyway to reduce this? Any suggestions are greatly appreciated. Current conf.. 7200: ! interface Port-channel1 description GEC_to_3750s no ip address duplex full hold-queue 150 in ! interface GigabitEthernet0/1 description TO_3750_1_0_24 no ip address duplex full speed auto media-type rj45 negotiation auto channel-group 1 ! interface GigabitEthernet0/2 description TO_3750_2_0_24 no ip address duplex full speed auto media-type rj45 negotiation auto channel-group 1 ! 3750s: interface Port-channel1 description GEC_to_7200 switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet1/0/24 description TO_7200_GE_0_1 switchport trunk encapsulation dot1q duplex full channel-group 1 mode on spanning-tree portfast ! interface GigabitEthernet2/0/24 description TO_7200_GE_0_2 switchport trunk encapsulation dot1q duplex full channel-group 1 mode on spanning-tree portfast - This e-mail was sent via Data FX Online WebMail http://www.datafx.com.au/ ___ 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/
