Yuor smartnet still treats them as two discrete devices. Cheers, Matt
CCIE #22386 CCSI #31207 On 14 April 2010 22:35, Matthew Loraditch <[email protected]> wrote: > Why could you not still bill them for separate switches even if they are > stackwise? If you have a cluster of servers that answer to 1 ip address > would you still not bill for each server? > > I know it’s not totally equivalent but it’s a similar situation. > > > > Matthew Loraditch > 1965 Greenspring Drive > > Timonium, MD 21093 > [email protected] > (p) (410) 252-8830 > (F) (443) 541-1593 > > Visit us at www.heliontechnologies.com > Support Issue? Email [email protected] for fast assistance! > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Bill > Sent: Wednesday, April 14, 2010 8:18 AM > To: 'Patrice Ngassam'; [email protected] > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > > Subject: Re: [OSL | CCIE_RS] Stack Vs Standalone > > > > “Ease of management is not relevant if you bill your customer on device > count basis” > > > > If you don’t try to find the best method to bill your customer you may find > they are someone else’s customer. > > > > ________________________________ > > From: [email protected] > [mailto:[email protected]] On Behalf Of Patrice Ngassam > Sent: Tuesday, April 13, 2010 10:30 PM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [OSL | CCIE_RS] Stack Vs Standalone > > > > Thanks Matt, > Ease of management is not relevant if you bill your customer on device count > basis. I would like to know if it's better to use stack at the access layer > (Gig E uplinks to distribution layer) knowing that communication flows > vertically with very little interaction between users. in HA scenarios, with > need FHRP if we use standalone devices and also rely on spanning-tree for > load-balancing. With stack, no more need for HSRP OR VRRP, lesser risks of > L2 loops and son on. > What is the most important criteria for selecting 3750 over 3560? > > > Patrice Ngassam > Ceritified Cisco CCNP, CCDP, CCIP > > > > >> Date: Wed, 14 Apr 2010 12:20:54 +1000 >> Subject: Re: [OSL | CCIE_RS] Stack Vs Standalone >> From: [email protected] >> To: [email protected] >> CC: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected] >> >> Are these 3750 or 3750E? >> >> Either way: >> >> Performance between each switch is 32Gb or 96Gb. If you use Gig-E to >> connect them you only get 1G :) That shiny silver cable does much >> more than a Cat6 or a fibre. >> One virtual device to manage as opposed to two >> >> Short version, stacking is much easier to manage and gets better >> performance over the stackwise cable >> >> Cheers, >> Matt >> >> CCIE #22386 >> CCSI #31207 >> >> On 14 April 2010 12:08, Patrice Ngassam <[email protected]> wrote: >> > Hi Dear friends of Networking ! >> > I am facing a dilemma between stacking switches or use them as >> > standalone >> > devices. Is there any real network performance increase when switches >> > are >> > stacked together? If I have 2 3750 switches at the access layer, what >> > kind >> > of network performance gain I obtain with when they are configured as >> > stack? >> > >> > Patrice Ngassam >> > Ceritified Cisco CCNP, CCDP, CCIP >> > >> > >> > >> > >> > ________________________________ >> > Date: Sun, 28 Mar 2010 17:11:46 -0400 >> > From: [email protected] >> > To: [email protected] >> > CC: [email protected]; [email protected]; [email protected]; >> > [email protected]; [email protected]; >> > [email protected] >> > Subject: Re: [OSL | CCIE_RS] BGP design question >> > >> > Not so much a threat as just an oddity. We strive so much to have our >> > networks evolve to a self-healing method. We build in redundancy so >> > that WE >> > do not NEED to do all the work. Let your network work for you. And >> > here's >> > someone who wants to work for the network. ;) >> > >> > Patrice Ngassam wrote: >> > >> > You are very funny Scott, I was also chocked when the customer told me >> > that >> > manual switchback was his requirement. Why is it strange for you? Is it >> > a >> > threat for network design best practices? >> > >> > Patrice Ngassam >> > Ceritified Cisco CCNP, CCDP, CCIP >> > >> > >> > >> > >> > ________________________________ >> > Date: Sun, 28 Mar 2010 16:58:17 -0400 >> > From: [email protected] >> > To: [email protected] >> > CC: [email protected]; [email protected]; [email protected]; >> > [email protected]; [email protected]; >> > [email protected] >> > Subject: Re: [OSL | CCIE_RS] BGP design question >> > >> > Which this would most certainly cover his strange requirement of manual >> > switchback. >> > >> > On the other hand, could we run like IOS 10.3 or something? i seem to >> > recall that more things were less automagical back then! (smirk) >> > >> > >> > >> > Scott >> > >> > Marko Milivojevic wrote: >> > >> > Now, expanding on this we need solve additional requirement from the >> > original post. How to prevent peer from coming back up. Well, for that >> > we could probably use EEM. Let's take a look. >> > >> > event manager applet DISABLE_PEER >> > event routing network 2.2.2.2/32 type remove >> > action 10 cli command "enable" >> > action 20 cli command "configure terminal" >> > action 30 cli command "router bgp 1" >> > action 40 cli command "neighbor 2.2.2.2 shutdown" >> > action 50 cli command "end" >> > ! >> > >> > Enabling peer on R2. >> > >> > R1#sh ip bgp sum >> > BGP router identifier 1.1.1.1, local AS number 1 >> > BGP table version is 1, main routing table version 1 >> > >> > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ >> > Up/Down State/PfxRcd >> > 2.2.2.2 4 2 6 5 1 0 0 >> > 00:00:37 0 >> > >> > Killing the interface on R2 here. >> > >> > *Mar 29 01:33:59.679: %TRACKING-5-STATE: 1 ip sla 1 reachability >> > Up->Down >> > *Mar 29 01:33:59.683: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down Route to >> > peer >> > lost >> > *Mar 29 01:33:59.747: %SYS-5-CONFIG_I: Configured from console by on >> > vty0 (EEM:DISABLE_PEER) >> > >> > -- >> > Marko Milivojevic - CCIE #18427 >> > Senior Technical Instructor - IPexpert >> > >> > YES! We include 400 hours of REAL rack >> > time with our Blended Learning Solution! >> > >> > Mailto: [email protected] >> > Telephone: +1.810.326.1444 >> > Fax: +1.810.454.0130 >> > Web: http://www.ipexpert.com/ >> > >> > On Sun, Mar 28, 2010 at 17:05, Marko Milivojevic <[email protected]> >> > wrote: >> > >> > >> > On Sun, Mar 28, 2010 at 17:00, Narbik Kocharians <[email protected]> >> > wrote: >> > >> > >> > Totally understand that, but i did not see any mention of OSPF or ISIS. >> > >> > >> > Enjoy. >> > >> > R1: >> > >> > interface Loopback0 >> > B ip address 1.1.1.1 255.255.255.255 >> > ! >> > interface FastEthernet0/0 >> > B ip address 12.12.12.1 255.255.255.0 >> > ! >> > ip sla 1 >> > B icmp-echo 12.12.12.2 >> > B frequency 5 >> > ! >> > ip sla schedule 1 start-time now life forever >> > ! >> > track 1 ip sla 1 reachability >> > B default-state down >> > ! >> > ip route 2.2.2.2 255.255.255.255 12.12.12.2 track 1 >> > ! >> > route-map Neighbor-Alive >> > B match source-protocol static >> > ! >> > router bgp 1 >> > B neighbor 2.2.2.2 remote-as 2 >> > B neighbor 2.2.2.2 update-source Loopback0 >> > B neighbor 2.2.2.2 ebgp-multihop 2 >> > B neighbor 2.2.2.2 fall-over route-map Neighbor-Alive >> > ! >> > >> > R2: >> > >> > interface GigabitEthernet0/0 >> > B ip address 12.12.12.2 255.255.255.0 >> > ! >> > router bgp 2 >> > B neighbor 1.1.1.1 remote-as 1 >> > B neighbor 1.1.1.1 ebgp-multihop 2 >> > B neighbor 1.1.1.1 update-source Loopback0 >> > ! >> > >> > Notice what happens on R1 as soon as I shut down the port on R2 (there >> > is a switch between them). >> > >> > *Mar 29 00:59:19.679: %TRACKING-5-STATE: 1 ip sla 1 reachability >> > Up->Down >> > *Mar 29 00:59:19.683: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down Route to >> > peer >> > lost >> > >> > >> > -- >> > Marko Milivojevic - CCIE #18427 >> > Senior Technical Instructor - IPexpert >> > >> > YES! We include 400 hours of REAL rack >> > time with our Blended Learning Solution! >> > >> > Mailto: [email protected] >> > Telephone: +1.810.326.1444 >> > Fax: +1.810.454.0130 >> > Web: http://www.ipexpert.com/ >> > >> > >> > Blogs and organic groups at http://www.ccie.net >> > >> > _______________________________________________________________________ >> > Subscription information may be found at: >> > http://www.groupstudy.com/list/CCIELab.html >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > ________________________________ >> > Télécharger en toute sécurité sur Internet ? La solution avec Internet >> > Explorer 8 >> > >> > ________________________________ >> > Télécharger en toute sécurité sur Internet ? La solution avec Internet >> > Explorer 8 >> > _______________________________________________ >> > For more information regarding industry leading CCIE Lab training, >> > please >> > visit www.ipexpert.com >> > >> > > > ________________________________ > > Hotmail débarque sur votre téléphone ! Paramétrez Hotmail sur votre > téléphone! Gratuit ! _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
