[c-nsp] implementing cisco pvst+
Hello All, Does implementing pvst+ with the IEEE multiple spanning tree code is good? the only difference between them is the CIST, By disabling CIST we can have multipe spanning tree behave like pvst+ with each spanning tree controlling one vlan. Thanks Vishnu ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IP SLA source pings on PIX/ASA ?
To anybody reading this, this is an open bug/feature request with Cisco TAC. On Thu, Apr 14, 2011 at 7:24 AM, Rama Darbha rdar...@gmail.com wrote: Eshan, This is a tricky design, as you know we can't ping to or from the far side interface of the PIX/ASA. Here is a guide that talks about how to use Smart Call Home as a workaround that issue: https://supportforums.cisco.com/docs/DOC-15571 Does this offer the solution you want? Regard, Rama On Wed, Apr 13, 2011 at 10:25 PM, Eshan esha...@gmail.com wrote: I tried asking this question elsewhere but wasn't able to get a satisfactory response, thought I should try here! We have site to site mesh ipsec tunnels that terminate on different PIXes. A requirement for clients using these tunnels is to monitor the downtime on a particular tunnel - using a trap sent to a remote syslog server, I am able to filter the SNMP trap, and send an email alert. However, is there any way to go one step further and keep a record (track) of when the tunnel goes down and keep this data? On routers we usually use IP SLA's with source IP specified and this seems to work very well. On PIX/ASA however when I do a 'source' internal ipIcmpEcho (as the tunnel far end is only accessible through a route within itself) - the track feature fails. Can there be no IP SLA by specifying a source to ping from on PIX/ASA's as is the case with routers? Thank you muchly:) Eshan. ___ 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] no bgp route from 0.0.0.0 for a interface ip address
Why bgp route from 0.0.0.0 doesn't exist, 192.168.2.50 is a interface ip address on routerB! Instead bgp route for 192.168.2.50 is from 192.168.96.1 and 192.168.2.49, it is strange. we redistribute static and connected on all four routers. the topology like below: lo0:192.168.96.2lo0:192.168.96.1 routerA ebgp - routerB --ibgp routerBB 192.168.2.49 192.168.2.50 | | | |ibgp--routerAAebgp--- routerB# show ip bgp 192.168.2.50 BGP routing table entry for 192.168.2.50/32, version 151 Paths: (2 available, best #2, table default, RIB-failure(17) - next-hop mismatch ) Advertised to update-groups: 1 65450 192.168.96.1 from 192.168.96.1 (192.168.96.1) Origin incomplete, metric 0, localpref 100, valid, internal 65450 192.168.2.49 from 192.168.2.49 (192.168.0.2) Origin incomplete, metric 0, localpref 100, valid, external, best ___ 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] Cases to lock a switch -- physical layer protection?
Hello, I have a particularly sensitive scenario where I need to allow access to other hardware within a rack but ensure that no one is able to physically modify connections to the top-of-rack switch and ASA. I would love to find an in-rack-mountable case to go around the Cisco gear, in the same way that telco's commonly protect smartjack shelves. Can anyone recommend such a case or similar protective measure? -- Trever Furnish, tgfurn...@herffjones.com Herff Jones, Inc. Solutions Architect Phone: 317.612.3519 ___ 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 VLANs for customer isolation on sup720/12.2(33)
All, We've got a pair of Cisco 6500/sup720 serving as our datacentre collapsed routing/distribution. Servers are attached to downstream Foundry/Brocade devices, and possibly other dumb/cheap devices in future. Can I use private VLANs in this case to isolate customers and avoid burning 5 IPs (network, broadcast, HSRP master, slave vip) per-customer? I do *not* want to stop customers talking to each other at layer3 - just get some degree of isolation (including the sticky arp). I think I can't, because 12.2(33)SXI seems to lack switchport mode private-vlan trunk. Is this correct? What I want to do is: vlan 600 name customer-1 private-vlan community vlan 601 name customer-2 private-vlan community vlan 60 name all-customers private-vlan primary private-vlan assoc 600,601 int Te1/1 switchport mode trunk switchport trunk allowed vlan 600,601 int Vl60 ip address ... private-vlan mapping ... 600,601 ip local-proxy-arp Cheers, Phil ___ 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] no bgp route from 0.0.0.0 for a interface ip address
At first blush it looks like 192.168.2.50 can't talk to anyone. Try changing his mask to /31 or something so that 192.168.2.49 is on the same network.. BGP routing table entry for 192.168.2.50/32 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of tao liu Sent: Tuesday, April 19, 2011 8:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] no bgp route from 0.0.0.0 for a interface ip address Why bgp route from 0.0.0.0 doesn't exist, 192.168.2.50 is a interface ip address on routerB! Instead bgp route for 192.168.2.50 is from 192.168.96.1 and 192.168.2.49, it is strange. we redistribute static and connected on all four routers. the topology like below: lo0:192.168.96.2lo0:192.168.96.1 routerA ebgp - routerB --ibgp routerBB 192.168.2.49 192.168.2.50 | | | |ibgp--routerAAebgp--- routerB# show ip bgp 192.168.2.50 BGP routing table entry for 192.168.2.50/32, version 151 Paths: (2 available, best #2, table default, RIB-failure(17) - next-hop mismatch ) Advertised to update-groups: 1 65450 192.168.96.1 from 192.168.96.1 (192.168.96.1) Origin incomplete, metric 0, localpref 100, valid, internal 65450 192.168.2.49 from 192.168.2.49 (192.168.0.2) Origin incomplete, metric 0, localpref 100, valid, external, best ___ 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 VLANs for customer isolation on sup720/12.2(33)
In order to make use of this design the downstream switches (where you connect the customer devices), would need to understand private-vlans in order to join the primary (downstream) and secondary (upstream) traffic. For that to work you would need to allow also the primary vlan on the Te1/1 trunk. You would not really need the private-vlan trunk feature, you can transport them on a normal trunk port (and join them on the access switch). The private-vlan trunk feature is useful in a scenario where one port (Te1/x) belongs to one customer and you are handing over multiple secondary vlans over that port. This seems like is not your case. BTW I believe it is supported on latest CatOS...:) -pavel skovajsa On Tue, Apr 19, 2011 at 3:38 PM, Phil Mayers p.may...@imperial.ac.ukwrote: All, We've got a pair of Cisco 6500/sup720 serving as our datacentre collapsed routing/distribution. Servers are attached to downstream Foundry/Brocade devices, and possibly other dumb/cheap devices in future. Can I use private VLANs in this case to isolate customers and avoid burning 5 IPs (network, broadcast, HSRP master, slave vip) per-customer? I do *not* want to stop customers talking to each other at layer3 - just get some degree of isolation (including the sticky arp). I think I can't, because 12.2(33)SXI seems to lack switchport mode private-vlan trunk. Is this correct? What I want to do is: vlan 600 name customer-1 private-vlan community vlan 601 name customer-2 private-vlan community vlan 60 name all-customers private-vlan primary private-vlan assoc 600,601 int Te1/1 switchport mode trunk switchport trunk allowed vlan 600,601 int Vl60 ip address ... private-vlan mapping ... 600,601 ip local-proxy-arp Cheers, Phil ___ 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 VLANs for customer isolation on sup720/12.2(33)
You can just need primary vlan on the catalyst 6500, basically 6500 is not aware of the private vlans existence. Then private vlans on the access switch. The following is one of my old post. promisc port has to be access port. So you need a loopback cable on your access switch with two vlan numbers for your primary vlan. For example vlan 140 and vlan 141, then your link to distribution will still be vlan 140, other vlans trunk, but one end of loopback cable would be access vlan 140, the other end of the loopback cable will be access vlan 141. You can then set vlan 141 to be your primary vlan, and the end with access vlan 141 to be promisc port. So you have to use a loopback cable and two ports. Foundry/Brocade is the same way too. Schilling On Tue, Apr 19, 2011 at 9:38 AM, Phil Mayers p.may...@imperial.ac.uk wrote: All, We've got a pair of Cisco 6500/sup720 serving as our datacentre collapsed routing/distribution. Servers are attached to downstream Foundry/Brocade devices, and possibly other dumb/cheap devices in future. Can I use private VLANs in this case to isolate customers and avoid burning 5 IPs (network, broadcast, HSRP master, slave vip) per-customer? I do *not* want to stop customers talking to each other at layer3 - just get some degree of isolation (including the sticky arp). I think I can't, because 12.2(33)SXI seems to lack switchport mode private-vlan trunk. Is this correct? What I want to do is: vlan 600 name customer-1 private-vlan community vlan 601 name customer-2 private-vlan community vlan 60 name all-customers private-vlan primary private-vlan assoc 600,601 int Te1/1 switchport mode trunk switchport trunk allowed vlan 600,601 int Vl60 ip address ... private-vlan mapping ... 600,601 ip local-proxy-arp Cheers, Phil ___ 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 VLANs for customer isolation on sup720/12.2(33)
On 19/04/11 15:09, Pavel Skovajsa wrote: In order to make use of this design the downstream switches (where you connect the customer devices), would need to understand private-vlans in Well, they don't understand private vlans. order to join the primary (downstream) and secondary (upstream) traffic. For that to work you would need to allow also the primary vlan on the Te1/1 trunk. You would not really need the private-vlan trunk feature, you can transport them on a normal trunk port (and join them on the access switch). The private-vlan trunk feature is useful in a scenario where one port (Te1/x) belongs to one customer and you are handing over multiple secondary vlans over that port. This seems like is not your case. BTW I believe it is supported on latest CatOS...:) Really? Because the IOS docs for Cat4500 imply that it is used when the downstream switch does not support private vlans: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/54sg/configuration/guide/pvlans.html#wp1181903 ___ 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] no bgp route from 0.0.0.0 for a interface ip address
following is the config for bgp and show ip route, thanks router bgp 65453 no synchronization bgp router-id 192.168.96.2 bgp log-neighbor-changes redistribute connected route-map NEW redistribute static route-map NEW neighbor 192.168.2.49 remote-as 65450 neighbor 192.168.2.49 send-community neighbor 192.168.96.1 remote-as 65453 neighbor 192.168.96.1 update-source Loopback0 neighbor 192.168.96.1 next-hop-self no auto-summary ip bgp-community new-format route-map NEW permit 10 set community 65453:100 routerB#show ip route 192.168.2.50 Routing entry for 192.168.2.50/32 Known via connected, distance 0, metric 0 (connected) Redistributing via bgp 65453 Routing Descriptor Blocks: * directly connected, via Multilink1 Route metric is 0, traffic share count is 1 routerB#show ip route connected : C192.168.2.48/29 is directly connected, Multilink1 C192.168.2.49/32 is directly connected, Multilink1 L192.168.2.50/32 is directly connected, Multilink1 routerB#show ip int multilink 1 Multilink1 is up, line protocol is up Internet address is 192.168.2.50/29 Broadcast address is 255.255.255.255 Address determined by non-volatile memory Peer address is 192.168.2.49 MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent On Tue, Apr 19, 2011 at 9:12 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: At first blush it looks like 192.168.2.50 can't talk to anyone. Try changing his mask to /31 or something so that 192.168.2.49 is on the same network.. BGP routing table entry for 192.168.2.50/32 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of tao liu Sent: Tuesday, April 19, 2011 8:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] no bgp route from 0.0.0.0 for a interface ip address Why bgp route from 0.0.0.0 doesn't exist, 192.168.2.50 is a interface ip address on routerB! Instead bgp route for 192.168.2.50 is from 192.168.96.1 and 192.168.2.49, it is strange. we redistribute static and connected on all four routers. the topology like below: lo0:192.168.96.2lo0:192.168.96.1 routerA ebgp - routerB --ibgp routerBB 192.168.2.49 192.168.2.50 | | | |ibgp--routerAAebgp--- routerB# show ip bgp 192.168.2.50 BGP routing table entry for 192.168.2.50/32, version 151 Paths: (2 available, best #2, table default, RIB-failure(17) - next-hop mismatch ) Advertised to update-groups: 1 65450 192.168.96.1 from 192.168.96.1 (192.168.96.1) Origin incomplete, metric 0, localpref 100, valid, internal 65450 192.168.2.49 from 192.168.2.49 (192.168.0.2) Origin incomplete, metric 0, localpref 100, valid, external, best ___ 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] no bgp route from 0.0.0.0 for a interface ip address
Are you asking about a route to 0.0.0.0 or the default or a route with a next-hop of 0.0.0.0? On Tue, Apr 19, 2011 at 10:46 AM, tao liu taosys...@gmail.com wrote: following is the config for bgp and show ip route, thanks router bgp 65453 no synchronization bgp router-id 192.168.96.2 bgp log-neighbor-changes redistribute connected route-map NEW redistribute static route-map NEW neighbor 192.168.2.49 remote-as 65450 neighbor 192.168.2.49 send-community neighbor 192.168.96.1 remote-as 65453 neighbor 192.168.96.1 update-source Loopback0 neighbor 192.168.96.1 next-hop-self no auto-summary ip bgp-community new-format route-map NEW permit 10 set community 65453:100 routerB#show ip route 192.168.2.50 Routing entry for 192.168.2.50/32 Known via connected, distance 0, metric 0 (connected) Redistributing via bgp 65453 Routing Descriptor Blocks: * directly connected, via Multilink1 Route metric is 0, traffic share count is 1 routerB#show ip route connected : C192.168.2.48/29 is directly connected, Multilink1 C192.168.2.49/32 is directly connected, Multilink1 L192.168.2.50/32 is directly connected, Multilink1 routerB#show ip int multilink 1 Multilink1 is up, line protocol is up Internet address is 192.168.2.50/29 Broadcast address is 255.255.255.255 Address determined by non-volatile memory Peer address is 192.168.2.49 MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent On Tue, Apr 19, 2011 at 9:12 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: At first blush it looks like 192.168.2.50 can't talk to anyone. Try changing his mask to /31 or something so that 192.168.2.49 is on the same network.. BGP routing table entry for 192.168.2.50/32 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of tao liu Sent: Tuesday, April 19, 2011 8:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] no bgp route from 0.0.0.0 for a interface ip address Why bgp route from 0.0.0.0 doesn't exist, 192.168.2.50 is a interface ip address on routerB! Instead bgp route for 192.168.2.50 is from 192.168.96.1 and 192.168.2.49, it is strange. we redistribute static and connected on all four routers. the topology like below: lo0:192.168.96.2lo0:192.168.96.1 routerA ebgp - routerB --ibgp routerBB 192.168.2.49 192.168.2.50 | | | |ibgp--routerAAebgp--- routerB# show ip bgp 192.168.2.50 BGP routing table entry for 192.168.2.50/32, version 151 Paths: (2 available, best #2, table default, RIB-failure(17) - next-hop mismatch ) Advertised to update-groups: 1 65450 192.168.96.1 from 192.168.96.1 (192.168.96.1) Origin incomplete, metric 0, localpref 100, valid, internal 65450 192.168.2.49 from 192.168.2.49 (192.168.0.2) Origin incomplete, metric 0, localpref 100, valid, external, best ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] no bgp route from 0.0.0.0 for a interface ip address
route to 192.168.2.50 with a nex-hop 0.0.0.0 should exists in bgp table, however it doesn't On Tue, Apr 19, 2011 at 11:06 PM, Keegan Holley keegan.hol...@sungard.comwrote: Are you asking about a route to 0.0.0.0 or the default or a route with a next-hop of 0.0.0.0? On Tue, Apr 19, 2011 at 10:46 AM, tao liu taosys...@gmail.com wrote: following is the config for bgp and show ip route, thanks router bgp 65453 no synchronization bgp router-id 192.168.96.2 bgp log-neighbor-changes redistribute connected route-map NEW redistribute static route-map NEW neighbor 192.168.2.49 remote-as 65450 neighbor 192.168.2.49 send-community neighbor 192.168.96.1 remote-as 65453 neighbor 192.168.96.1 update-source Loopback0 neighbor 192.168.96.1 next-hop-self no auto-summary ip bgp-community new-format route-map NEW permit 10 set community 65453:100 routerB#show ip route 192.168.2.50 Routing entry for 192.168.2.50/32 Known via connected, distance 0, metric 0 (connected) Redistributing via bgp 65453 Routing Descriptor Blocks: * directly connected, via Multilink1 Route metric is 0, traffic share count is 1 routerB#show ip route connected : C192.168.2.48/29 is directly connected, Multilink1 C192.168.2.49/32 is directly connected, Multilink1 L192.168.2.50/32 is directly connected, Multilink1 routerB#show ip int multilink 1 Multilink1 is up, line protocol is up Internet address is 192.168.2.50/29 Broadcast address is 255.255.255.255 Address determined by non-volatile memory Peer address is 192.168.2.49 MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent On Tue, Apr 19, 2011 at 9:12 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: At first blush it looks like 192.168.2.50 can't talk to anyone. Try changing his mask to /31 or something so that 192.168.2.49 is on the same network.. BGP routing table entry for 192.168.2.50/32 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of tao liu Sent: Tuesday, April 19, 2011 8:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] no bgp route from 0.0.0.0 for a interface ip address Why bgp route from 0.0.0.0 doesn't exist, 192.168.2.50 is a interface ip address on routerB! Instead bgp route for 192.168.2.50 is from 192.168.96.1 and 192.168.2.49, it is strange. we redistribute static and connected on all four routers. the topology like below: lo0:192.168.96.2lo0:192.168.96.1 routerA ebgp - routerB --ibgp routerBB 192.168.2.49 192.168.2.50 | | | |ibgp--routerAAebgp--- routerB# show ip bgp 192.168.2.50 BGP routing table entry for 192.168.2.50/32, version 151 Paths: (2 available, best #2, table default, RIB-failure(17) - next-hop mismatch ) Advertised to update-groups: 1 65450 192.168.96.1 from 192.168.96.1 (192.168.96.1) Origin incomplete, metric 0, localpref 100, valid, internal 65450 192.168.2.49 from 192.168.2.49 (192.168.0.2) Origin incomplete, metric 0, localpref 100, valid, external, best ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cases to lock a switch -- physical layer protection?
On Tue, Apr 19, 2011 at 09:22:58AM -0400, Furnish, Trever G wrote: I have a particularly sensitive scenario where I need to allow access to other hardware within a rack but ensure that no one is able to physically modify connections to the top-of-rack switch and ASA. I would love to find an in-rack-mountable case to go around the Cisco gear, in the same way that telco's commonly protect smartjack shelves. Can anyone recommend such a case or similar protective measure? I haven't seen anything that would work like that, but what I have seen typically done is to drop in a 1/3 or 1/2 rack, with the switch/ASA/patchpanel taking up the top 1/3rd leaving the other 2 thirds to be used for whatever else. This works better for more EOR switch setups than TOR. A big enough order to a rack vendor could probably get some custom setups going (ie. instead of split 50/50, have the top 5U and then the remaining 42U or 37U for the rest of the rack). You may be able to retro something like this VTR lockbox into a rack http://middleatlantic.com/enclosure/knock/vlbx.htm with some glides and bolting everything in place before other gear is there. But what I'd probably do given the situation would be to bolt another box ontop of the rack altogether, like http://www.middleatlantic.com/enclosure/wall/dlbx.htm ___ 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 VLANs for customer isolation on sup720/12.2(33)
On Tue, Apr 19, 2011 at 4:38 PM, Phil Mayers p.may...@imperial.ac.ukwrote: On 19/04/11 15:09, Pavel Skovajsa wrote: In order to make use of this design the downstream switches (where you connect the customer devices), would need to understand private-vlans in Well, they don't understand private vlans. order to join the primary (downstream) and secondary (upstream) traffic. For that to work you would need to allow also the primary vlan on the Te1/1 trunk. You would not really need the private-vlan trunk feature, you can transport them on a normal trunk port (and join them on the access switch). The private-vlan trunk feature is useful in a scenario where one port (Te1/x) belongs to one customer and you are handing over multiple secondary vlans over that port. This seems like is not your case. BTW I believe it is supported on latest CatOS...:) Really? Because the IOS docs for Cat4500 imply that it is used when the downstream switch does not support private vlans: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/54sg/configuration/guide/pvlans.html#wp1181903 Yes, you are right, the isolated private-vlan trunk would help in this case as well. Try to look into the latest CatOS 8, I vaguely remember seeing this feature there. Otherwise it seems like the option you are left with is either do a SVI per customer or doing the loopack cable trick (described above by shilling) on the edge devices. -pavel ___ 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 VLANs for customer isolation on sup720/12.2(33)
Done similar to this with SXF (for FTTH rollout): interface vlan xxx (might be possible to use loopback intf) ip address x.x.x.x 255.255.252.0 ip local-proxy-arp interface vlan xxx+1 desc server1 ip unnumbered vlan xxx (or ip unnumbered loopback xxx) ip local-proxy-arp interface vlan xxx+2 desc server2 ip unnumbered vlan xxx (or ip unnumbered loopback xxx) ip local-proxy-arp to avoid burning av vlan for each server(customer), consider using switchport protected on access switch (if feature exists) Configuration from my head, might contain errors. Jon H Bøvre On 19.04.2011 15:38, Phil Mayers wrote: All, We've got a pair of Cisco 6500/sup720 serving as our datacentre collapsed routing/distribution. Servers are attached to downstream Foundry/Brocade devices, and possibly other dumb/cheap devices in future. Can I use private VLANs in this case to isolate customers and avoid burning 5 IPs (network, broadcast, HSRP master, slave vip) per-customer? I do *not* want to stop customers talking to each other at layer3 - just get some degree of isolation (including the sticky arp). I think I can't, because 12.2(33)SXI seems to lack switchport mode private-vlan trunk. Is this correct? What I want to do is: vlan 600 name customer-1 private-vlan community vlan 601 name customer-2 private-vlan community vlan 60 name all-customers private-vlan primary private-vlan assoc 600,601 int Te1/1 switchport mode trunk switchport trunk allowed vlan 600,601 int Vl60 ip address ... private-vlan mapping ... 600,601 ip local-proxy-arp Cheers, Phil ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IP SLA source pings on PIX/ASA ?
Eshan, Do you have the bugID? Regards, Rama On Tue, Apr 19, 2011 at 2:43 AM, Eshan Bhide eshanbh...@gmail.com wrote: To anybody reading this, this is an open bug/feature request with Cisco TAC. On Thu, Apr 14, 2011 at 7:24 AM, Rama Darbha rdar...@gmail.com wrote: Eshan, This is a tricky design, as you know we can't ping to or from the far side interface of the PIX/ASA. Here is a guide that talks about how to use Smart Call Home as a workaround that issue: https://supportforums.cisco.com/docs/DOC-15571 Does this offer the solution you want? Regard, Rama On Wed, Apr 13, 2011 at 10:25 PM, Eshan esha...@gmail.com wrote: I tried asking this question elsewhere but wasn't able to get a satisfactory response, thought I should try here! We have site to site mesh ipsec tunnels that terminate on different PIXes. A requirement for clients using these tunnels is to monitor the downtime on a particular tunnel - using a trap sent to a remote syslog server, I am able to filter the SNMP trap, and send an email alert. However, is there any way to go one step further and keep a record (track) of when the tunnel goes down and keep this data? On routers we usually use IP SLA's with source IP specified and this seems to work very well. On PIX/ASA however when I do a 'source' internal ipIcmpEcho (as the tunnel far end is only accessible through a route within itself) - the track feature fails. Can there be no IP SLA by specifying a source to ping from on PIX/ASA's as is the case with routers? Thank you muchly:) Eshan. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
