Jon Lewis writes:
> L3 Forwarding Resources
> FIB TCAM usage: TotalUsed %Used
> 72 bits (IPv4, MPLS, EoM) 196608 590 1%
> 144 bits (IP mcast, IPv6) 32768 23 1%
> [no 288 bi
ssage-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Tuesday, September 06, 2011 1:27 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] sup2T software & release notes have hit
On 06/09/11 12:08, Pawlowski, Maciej wrote:
>
On 06/09/11 12:08, Pawlowski, Maciej wrote:
Guys - did you have possibility to test if CWDM SFP are really not supported ?
I need to know if they will work on WS-X6724-SFP after Sup upgrade to 2T.
What makes you think they're not supported?
We have some CWDM SFP here, but we don't have any 6
Jon Lewis
Sent: Monday, September 05, 2011 5:51 PM
To: Phil Mayers
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] sup2T software & release notes have hit
On Mon, 5 Sep 2011, Phil Mayers wrote:
>> If they haven't increased the max routes capability of the next
>> gener
On Mon, 5 Sep 2011, Phil Mayers wrote:
If they haven't increased the max routes capability of the next
generation Sup vs the 3BXL, then that's very disappointing.
This is all quite well documented here:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SY/release/notes/ol_2067
On 05/09/11 16:35, Phil Mayers wrote:
On 05/09/11 16:29, Jon Lewis wrote:
On Mon, 5 Sep 2011, Alan Buxey wrote:
VS-S2T-10G-XL
1024K (IPv4) 512K (IPv6)
Right...but my point was, that's the same specs claim they make for the
Sup720-3BXL, and it's misleading because at least with the 3BXL, it's
On 05/09/11 16:29, Jon Lewis wrote:
On Mon, 5 Sep 2011, Alan Buxey wrote:
VS-S2T-10G-XL
1024K (IPv4) 512K (IPv6)
Right...but my point was, that's the same specs claim they make for the
Sup720-3BXL, and it's misleading because at least with the 3BXL, it's 1M
IPv4 routes [and 0 IPv6] OR 512K IP
On Mon, 5 Sep 2011, Alan Buxey wrote:
VS-S2T-10G-XL
1024K (IPv4) 512K (IPv6)
Right...but my point was, that's the same specs claim they make for the
Sup720-3BXL, and it's misleading because at least with the 3BXL, it's 1M
IPv4 routes [and 0 IPv6] OR 512K IPv6 routes [and 0 IPv4], or some
co
Hi,
> > [from show platform hardware capacity]
> > L3 Forwarding Resources
> > FIB TCAM usage: Total Used %Used
> > 72 bits (IPv4, MPLS, EoM) 622592 368412 59%
> > 144 bits (IP mcast, IPv6) 212992 7041 3%
>
>FIB TCAM usage: TotalUsed %Used
> 72 bits (
On Monday, September 05, 2011 10:25:40 PM Phil Mayers wrote:
> All,
>
> To answer my own question; we just unboxed and loaded our
> first sup2T today. Boot time with no config was ~100
> seconds, which is much faster than the sup720.
That's only 10 seconds quicker than a 7201. Not bad!
Mark.
On Mon, 5 Sep 2011, Phil Mayers wrote:
FIB TCAM usage: TotalUsed %Used
72 bits (IPv4, MPLS, EoM) 262144 20 1%
144 bits (IP mcast, IPv6) 131072 8 1%
288 bits (IPv6 mcast) 65536 1
On 05/09/11 15:40, Jon Lewis wrote:
[from show platform hardware capacity]
L3 Forwarding Resources
FIB TCAM usage: Total Used %Used
72 bits (IPv4, MPLS, EoM) 622592 368412 59%
144 bits (IP mcast, IPv6) 212992 7041 3%
FIB TCAM usage: TotalUsed %Used
7
On Mon, 5 Sep 2011, Phil Mayers wrote:
To answer my own question; we just unboxed and loaded our first sup2T today.
Boot time with no config was ~100 seconds, which is much faster than the
sup720.
IIRC, the specs for the Sup2T make the same max routes claim as the
Sup720-3BXL (i.e. 100 I
On 21/07/11 00:46, Tony Varriale wrote:
How long did it take to boot? Was it faster than the glacial 300
second average for a sup720?
Honestly I didn't time it but it seemed much faster. I'll see if I can
get access and time it.
All,
To answer my own question; we just unboxed and loaded our
Mark Tinka writes:
> Unless they can do something about that RSP720 or SUP720 for
> the 7600 (well, they could just throw the SUP2T at the 7600,
> but I doubt either BU will support that, hehe), folk should
> be looking at buying the ASR9000 when thinking about new
> 7600 purchases.
Yes, that'
On Sunday, July 24, 2011 04:08:50 AM Rinse Kloek wrote:
> Is there still a position in the market for the 7600
> platform ?
Unless they can do something about that RSP720 or SUP720 for
the 7600 (well, they could just throw the SUP2T at the 7600,
but I doubt either BU will support that, hehe), f
On Sunday, July 24, 2011 02:00:43 AM Mack McBride wrote:
> I think it is very likely the Sup2T will not have the
> same feature set as the 7600. Once the ASR9000 is less
> 'bleeding edge' then the 7600 will probably go away.
>
> I have to agree the 6500 with Sup2T is currently a better
> platform
That's exactly the reason replacing the 7600-SUP720 for 6506-SUP2T.
Specailly the VPLS features makes the 6500 more interesting as router
because you don't need those overprised ES+ cards.
Also the TCAM increase from 32K to 128K makes this platform very
interesting.
Is there still a position
On Friday, July 22, 2011 12:02:01 AM Mack McBride wrote:
> I am not so certain where the 7600 leads unless they
> remerge the two Business Units. The ASR9K is much more
> scalable and the cost differential on the nicer blades
> is low. The 7600 is less 'bleeding edge' so 7600s will
> probably be
nsp] sup2T software & release notes have hit
On Friday, July 22, 2011 12:02:01 AM Mack McBride wrote:
> I am not so certain where the 7600 leads unless they remerge the two
> Business Units. The ASR9K is much more scalable and the cost
> differential on the nicer blades is low. The
cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] sup2T software & release notes have hit
On 20/07/2011 16:53, Kevin Graham wrote:
> [...] given that it's game over for the 6500.
The C6500 is just a chassis which has a back-plane with particular
electrical characteristics and which run
I have heard next gen ISR for XE as well...
On Thu, 2011-07-21 at 11:05 +0400, Nikolay Shopik wrote:
> On 21/07/11 03:56, Tony Varriale wrote:
> >>
> > No one cares as much as it is a software platform :)
>
> I'd say this give almost no benefits for such platform also. And if they
> decide to gi
On 20/07/2011 16:53, Kevin Graham wrote:
> [...] given that it's game over for the 6500.
The C6500 is just a chassis which has a back-plane with particular
electrical characteristics and which runs a particular line of software
with a certain degree of continuity and growth. There's no reason tha
On 21/07/11 03:56, Tony Varriale wrote:
No one cares as much as it is a software platform :)
I'd say this give almost no benefits for such platform also. And if they
decide to give us XE, this is probably cost money on ISR-G2. Most likely
XE not happen until ISR-G3 and this is what I call E
On 7/20/2011 10:53 AM, Kevin Graham wrote:
On Jul 19, 2011, at 1:38 PM, Nick Hilliard wrote:
Have you considered the monumental task of making NX-OS or XR work with older
linecards? Or even IOS-XE?
Absolutely -- that's my point. I'm surprised by bringing a new software model to the 2T
give
On 7/20/2011 2:09 PM, Asbjorn Hojmark - Lists wrote:
On Wed, 20 Jul 2011 17:28:46 +0100, you wrote:
Well... just because something is easy for Cisco doesn't mean they would
do it. They might believe that IOS XE on the ISRs would eat into the
market for ASR, so they don't do it.
The ISR G2s wil
On 7/20/2011 11:28 AM, Phil Mayers wrote:
On 20/07/11 16:53, Kevin Graham wrote:
On Jul 19, 2011, at 1:38 PM, Nick Hilliard wrote:
Have you considered the monumental task of making NX-OS or XR work
with older linecards? Or even IOS-XE?
Absolutely -- that's my point. I'm surprised by bringi
On 7/19/2011 1:36 AM, Phil Mayers wrote:
On 07/19/2011 02:23 AM, Tony Varriale wrote:
Well, neither of those (I'm sure of the 6708 and almost 100% on the
6716) actually have a CFC and the DFC is not a FRU. Hence, the issue.
You're correct that both the 6708 and 6716 do not come with / cannot
On 7/19/2011 1:11 AM, Phil Mayers wrote:
On 07/19/2011 02:25 AM, Tony Varriale wrote:
Well I had the pleasure of watching one boot last night and I'm not very
optimistic as to my original statement. No word back from Cisco yet to
confirm.
How long did it take to boot? Was it faster than the g
On Wed, 20 Jul 2011 17:28:46 +0100, you wrote:
> Well... just because something is easy for Cisco doesn't mean they would
> do it. They might believe that IOS XE on the ISRs would eat into the
> market for ASR, so they don't do it.
The ISR G2s will Eventually(TM) get IOS-XE too.
-A
__
On 20/07/11 16:53, Kevin Graham wrote:
On Jul 19, 2011, at 1:38 PM, Nick Hilliard wrote:
Have you considered the monumental task of making NX-OS or XR work
with older linecards? Or even IOS-XE?
Absolutely -- that's my point. I'm surprised by bringing a new
software model to the 2T given tha
On Jul 19, 2011, at 1:38 PM, Nick Hilliard wrote:
> Have you considered the monumental task of making NX-OS or XR work with older
> linecards? Or even IOS-XE?
Absolutely -- that's my point. I'm surprised by bringing a new software model
to the 2T given that it's game over for the 6500. Howeve
On Tue, 2011-07-19 at 21:38 +0100, Nick Hilliard wrote:
> This is part of the problem with the C6500. It needs to maintain backwards
> compatibility with 12-15 years worth of line cards. This is difficult and
> tedious to maintain.
Alas, the Sup2T doesn't really support a lot of old cards. More
On 19/07/2011 18:36, Kevin Graham wrote:
> Even if they refuse to make the intuituve move to NX-OS, this late in
> the product lifecycle I don't see why they wouldn't just stubbornly
> cling to monolithic.
Have you considered the monumental task of making NX-OS or XR work with
older linecards? O
On Mon, Jul 18, 2011 at 03:20:47PM -0400, Jeff Kell wrote:
> You can probably "play" Dike Nukem Forever on Modular IOS by the time
> they finish adding bells and whistles to it.
There's prior art... Doom server (or was it Quake?) on Juniper routing
engine, alongside JUNOS, approx 10 years ago. :-)
On Jul 18, 2011, at 11:17 AM, "Asbjorn Hojmark - Lists"
wrote:
> It is IOS.
>
> Sup2T will have IOS-XE Sometime Later(TM).
Because on a 6500, commonality with ASR's makes a lot more sense than with the
Nexii that share use cases and (some) forwarding hardware? At every turn where
the 6500/76
Gert Doering writes:
> Mmmh. GPU based forwarding? Build a high-end 10Gbit router using
> $1000 PC parts? Tempting... :-)
Already been done, http://shader.kaist.edu/packetshader/
The code is not publically available.
/Benny
___
cisco-nsp mailin
Hi,
On Tue, Jul 19, 2011 at 09:51:33AM +0200, Benny Amorsen wrote:
> Gert Doering writes:
>
> > Mmmh. GPU based forwarding? Build a high-end 10Gbit router using
> > $1000 PC parts? Tempting... :-)
>
> Already been done, http://shader.kaist.edu/packetshader/
Wow :-)
gert
--
USENET is *not
On Tuesday, July 19, 2011 02:36:54 PM Phil Mayers wrote:
> This matches what Cisco told me in a very specific
> response to a very explicit question; the 6716 is
> upgradeable, the 6708 is not. Note it's a DFC4-E, which
> is different to the rest of the 67xx cards, which take a
> DFC4-A. I assume
On 07/19/2011 02:23 AM, Tony Varriale wrote:
Well, neither of those (I'm sure of the 6708 and almost 100% on the
6716) actually have a CFC and the DFC is not a FRU. Hence, the issue.
You're correct that both the 6708 and 6716 do not come with / cannot use
a CFC, but they differ w.r.t. DFC4 up
On 07/19/2011 02:25 AM, Tony Varriale wrote:
Well I had the pleasure of watching one boot last night and I'm not very
optimistic as to my original statement. No word back from Cisco yet to
confirm.
How long did it take to boot? Was it faster than the glacial 300 second
average for a sup720?
On 7/17/2011 5:10 AM, Gert Doering wrote:
Hi,
On Sun, Jul 17, 2011 at 10:12:32AM +0100, Nick Hilliard wrote:
It's unlikely to be based on NX-OS. However, XE == IOS running as process
on linux and -modular == IOS running as process on QNX, so it could
relatively easily be a variety of one of th
On 7/18/2011 5:39 AM, Phil Mayers wrote:
On 12/07/11 00:25, Saku Ytti wrote:
I don't see any reason why technically you couldn't just rip out DFC
from 6708
and run it as centralized card. Maybe the DFC itself is soldered in
making this
unpractical or maybe centralized performance was deemed by
Hi,
On Mon, Jul 18, 2011 at 03:20:47PM -0400, Jeff Kell wrote:
> You can probably "play" Dike Nukem Forever on Modular IOS by the
> time they finish adding bells and whistles to it.
Now *that* would be an interesting feature - a nice nvidia graphics
engine on board of the Sup-2T, being used to
On 7/18/2011 3:12 PM, Gert Doering wrote:
> Hi,
>
> On Mon, Jul 18, 2011 at 08:17:56PM +0200, Asbjorn Hojmark - Lists wrote:
>> Sup2T will have IOS-XE Sometime Later(TM).
>
> "There will be modular IOS for 6500!!"
>
> Call me unconvinced.
>
> ... I'll go and play Duke Nukem Forever in the meantime.
Hi,
On Mon, Jul 18, 2011 at 08:17:56PM +0200, Asbjorn Hojmark - Lists wrote:
> Sup2T will have IOS-XE Sometime Later(TM).
"There will be modular IOS for 6500!!"
Call me unconvinced.
... I'll go and play Duke Nukem Forever in the meantime...
gert
--
USENET is *not* the non-clickable part of
> XE is what the rumors told me the Sup2T would be based upon, but
> IOS versions like "12.2(50)SY" very much sound like IOS-trains.
It is IOS.
Sup2T will have IOS-XE Sometime Later(TM).
-A
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https:/
On 12/07/11 00:25, Saku Ytti wrote:
I don't see any reason why technically you couldn't just rip out DFC from 6708
and run it as centralized card. Maybe the DFC itself is soldered in making this
unpractical or maybe centralized performance was deemed by BU unmarketable.
My understanding was it
hi,
i raised a few questions regarding the current release notes
and sup2T documentation and the doc is now edited to make clear
the legacy PVST and what the Sup2T supports.
alan
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.
Hi,
On Sun, Jul 17, 2011 at 11:17:40AM +0100, Nick Hilliard wrote:
> On 17/07/2011 11:10, Gert Doering wrote:
> > From all I was able to gather, -modular / ION is dead. Lack of
> > progress, lack of buy-in from other BUs, short-sighted management.
>
> Yeah, -modular left me feeling rather cold.
On 17/07/2011 11:10, Gert Doering wrote:
> From all I was able to gather, -modular / ION is dead. Lack of
> progress, lack of buy-in from other BUs, short-sighted management.
Yeah, -modular left me feeling rather cold. Can't imagine why, but the
ability to restart the line printer daemon on my 6
Hi,
On Sun, Jul 17, 2011 at 10:12:32AM +0100, Nick Hilliard wrote:
> It's unlikely to be based on NX-OS. However, XE == IOS running as process
> on linux and -modular == IOS running as process on QNX, so it could
> relatively easily be a variety of one of these, if it's not IOS running on
> bare
On 17/07/2011 08:29, Gert Doering wrote:
> Software can't be "close" and "further away" from either - it's
> completely different architectures, so either it's "IOS" or "one of the
> others".
>
> The version numbering very much suggests "IOS"...
It's unlikely to be based on NX-OS. However, XE ==
Hi,
On Sat, Jul 16, 2011 at 09:00:09PM -0500, Tony Varriale wrote:
> On 7/11/2011 1:26 PM, Gert Doering wrote:
> >mmh. Is this IOS? Or IOS XE? I thought the Sup2T was supposed to
> >ship with something modularish?
> I suspect that the new software will be further away from IOS and closer
> to
On 7/11/2011 5:21 PM, Peter Rathlev wrote:
On Tue, 2011-07-12 at 00:00 +0200, Robert Hass wrote:
The 6708 card isn't mentioned elsewhere on the page. Specifically
not in "Table 6. DFC4 Field Upgradable Linecard". Anybody know what
that means? Do we have to buy new 6908 cards instead? Or will the
On 7/11/2011 5:00 PM, Robert Hass wrote:
The 6708 card isn't mentioned elsewhere on the page. Specifically not in
"Table 6. DFC4 Field Upgradable Linecard". Anybody know what that means?
Do we have to buy new 6908 cards instead? Or will there be a field
upgrade?
As 6708 is DFC-only (same as 6716
On 7/11/2011 5:00 PM, Robert Hass wrote:
The 6708 card isn't mentioned elsewhere on the page. Specifically not in
"Table 6. DFC4 Field Upgradable Linecard". Anybody know what that means?
Do we have to buy new 6908 cards instead? Or will there be a field
upgrade?
As 6708 is DFC-only (same as 6716
On 7/11/2011 1:26 PM, Gert Doering wrote:
mmh. Is this IOS? Or IOS XE? I thought the Sup2T was supposed to
ship with something modularish?
I suspect that the new software will be further away from IOS and closer
to NX-OS and/or IOS-XE.
I mean, what would the point given all the new stuff? :
On Wednesday, July 13, 2011 11:57:10 PM Phil Mayers wrote:
> AIUI, Cisco has (or believes it has) a lot of customers
> with crappy old multimode that they can't replace, and
> is over-length for traditional 10gig transceivers. Hence
> the LX4, which gives you (marginally) better range than
> other
On 07/13/2011 04:34 PM, Mark Tinka wrote:
On Wednesday, July 13, 2011 10:59:03 PM Phil Mayers wrote:
Specifically LX4 transceivers?
No, SR.
Sorry, thought the issue was multi-mode support itself, not
the need for an LX4 transceiver.
AIUI, Cisco has (or believes it has) a lot of customers w
On Wednesday, July 13, 2011 11:17:57 PM Nick Hilliard wrote:
> the FTLX8511D3 is an SR transceiver, not an LR4. The
> electrical interface on an SR transceiver is 10G, not 4
> x 3.125G, i.e. no serdes required.
Yes, fair point. Thought the issue was just about needing
multi-mode for 10Gbps, not
On Wednesday, July 13, 2011 10:59:03 PM Phil Mayers wrote:
> Specifically LX4 transceivers?
No, SR.
Sorry, thought the issue was multi-mode support itself, not
the need for an LX4 transceiver.
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
On Wednesday, July 13, 2011 07:20:15 PM Nick Hilliard wrote:
> Maybe some cisco designers just like X2? Maybe Cisco
> have lots of experience with X2 and the architectural
> move to XFI interfaces would mean board redesigns?
> Difficult to tell really. I have to say that as a
> customer, I vi
On Wednesday, July 13, 2011 04:45:43 PM Phil Mayers wrote:
> Cisco seem to have a real blindspot for 10G transceivers.
>
> The explanation "back in the day" was that Cisco had a
> lot of customers wanting to run 10gig over old multimode
> fibre, and thus needed the LX4 transceiver which
> require
On 13/07/2011 15:56, Mark Tinka wrote:
> Part number: FTLX8511D3-CS Serial number: FNS14510S11
the FTLX8511D3 is an SR transceiver, not an LR4. The electrical interface
on an SR transceiver is 10G, not 4 x 3.125G, i.e. no serdes required.
> Juniper have this one locked down. I never have to wond
On 07/13/2011 03:46 PM, Mark Tinka wrote:
On Wednesday, July 13, 2011 04:45:43 PM Phil Mayers wrote:
Cisco seem to have a real blindspot for 10G transceivers.
The explanation "back in the day" was that Cisco had a
lot of customers wanting to run 10gig over old multimode
fibre, and thus needed
On 13/07/2011 09:45, Phil Mayers wrote:
> The explanation "back in the day" was that Cisco had a lot of customers
> wanting to run 10gig over old multimode fibre, and thus needed the LX4
> transceiver which required a physically bigger housing to fit all the bits
> into. I wonder if that's still th
On 07/12/2011 03:34 PM, Mark Tinka wrote:
On Tuesday, July 12, 2011 02:29:25 PM Alan Buxey wrote:
Use the sfp+ adapter?
I saw that too.
My point is I'm guessing the card could be cheaper (and
faster) if smaller sockets were used.
Also, XFP would give us better distance as of now, but sure,
On Tuesday, July 12, 2011 02:29:25 PM Alan Buxey wrote:
> Use the sfp+ adapter?
I saw that too.
My point is I'm guessing the card could be cheaper (and
faster) if smaller sockets were used.
Also, XFP would give us better distance as of now, but sure,
SFP+ will eventually catch up.
I just thi
On 12/07/2011 09:08, Florian Weimer wrote:
> * Simon Leinen:
>
>> Thanks for the heads-up! There's some more technical information
>> about the Supervisor 2T in the White Papers section:
>>
>> http://www.cisco.com/en/US/customer/products/hw/switches/ps708/prod_white_papers_list.html
>
>>
> Hmm,
On Tue, 2011-07-12 at 08:08 +, Florian Weimer wrote:
> > http://www.cisco.com/en/US/customer/products/hw/switches/ps708/prod_white_papers_list.html
>
> Hmm, this redirects to a login page for me. Is Cisco's technical
> documentation no longer publicly available?
Just remove the "/customer/"
* Simon Leinen:
> Thanks for the heads-up! There's some more technical information about
> the Supervisor 2T in the White Papers section:
>
> http://www.cisco.com/en/US/customer/products/hw/switches/ps708/prod_white_papers_list.html
Hmm, this redirects to a login page for me. Is Cisco's technica
Hi,
On Tue, Jul 12, 2011 at 10:54:50AM +0800, Mark Tinka wrote:
> What does that mean? Well, buying the cheaper/newer line
> cards will mean a whole new forklift:
>
> o New supervisor module.
>
> o New WS-X6908 line cards for your expansion.
>
> o New WS-X6908 line cards to b
Use the sfp+ adapter?
Alan
--
Message may be brief as it has been sent from my mobile
- Reply message -
From: "Mark Tinka"
Date: Tue, Jul 12, 2011 03:57
Subject: [c-nsp] sup2T software & release notes have hit
To: "cisco-nsp@puck.nether.net"
On Tuesday, J
Having read through the SUP2T architecture, it seems to be
shaping up to outperform a 7600 with an RSP720 + ES line
cards, assuming everything works as advertised :-).
Some of the line card compatibility madness may put a few
customers off if they want to move to this new supervisor,
but overa
On Tuesday, July 12, 2011 05:52:29 AM Peter Rathlev wrote:
> The Supervisor 2T provides backward compatibility with
> the existing WS-X6700 Series Linecards (with the
> exception of the WS-X6708-10G, which will be replaced by
> the new WS-X6908-10G, discussed later), as well as
> select WS-X6100
On (2011-07-12 00:00 +0200), Robert Hass wrote:
> As 6708 is DFC-only (same as 6716) and cannot work in CFC due to lack
> of some bus ASICs. You cannot it use with 2T due to incompability DFC4
> to DFC3. DFC4 is not supported at all at 67xx linecards. But there is
> special TMP program for 6708 l
On Tue, 2011-07-12 at 00:00 +0200, Robert Hass wrote:
> > The 6708 card isn't mentioned elsewhere on the page. Specifically
> > not in "Table 6. DFC4 Field Upgradable Linecard". Anybody know what
> > that means? Do we have to buy new 6908 cards instead? Or will there
> > be a field upgrade?
>
> As
dfc-based linecards will require dfc4 to function in sup2t chassis (if
supported by software). any 6700-series cards supported in sup2t will
need this upgrade.
6708 linecard cleverly omitted from upgrade path -- this, as stated,
will need to be replaced with 6908 line-rate card -- or used in
sup720
> The 6708 card isn't mentioned elsewhere on the page. Specifically not in
> "Table 6. DFC4 Field Upgradable Linecard". Anybody know what that means?
> Do we have to buy new 6908 cards instead? Or will there be a field
> upgrade?
As 6708 is DFC-only (same as 6716) and cannot work in CFC due to lac
On Mon, 2011-07-11 at 23:19 +0200, Simon Leinen wrote:
> Thanks for the heads-up! There's some more technical information about
> the Supervisor 2T in the White Papers section:
>
> http://www.cisco.com/en/US/customer/products/hw/switches/ps708/prod_white_papers_list.html
Yeah...:
"
The Supervi
Thanks for the heads-up! There's some more technical information about
the Supervisor 2T in the White Papers section:
http://www.cisco.com/en/US/customer/products/hw/switches/ps708/prod_white_papers_list.html
--
Simon.
___
cisco-nsp mailing list cisco-
Hi,
On Mon, Jul 11, 2011 at 07:35:25PM +0100, Phil Mayers wrote:
> On 07/11/2011 07:26 PM, Gert Doering wrote:
> >(Mmmh. Is this IOS? Or IOS XE? I thought the Sup2T was supposed to
> >ship with something modularish?)
>
> IOS. I've seen a load of roadmap presentations on this thing, and Cisco
On 07/11/2011 07:32 PM, Alan Buxey wrote:
gulp.
we use rapid-pvst - is that also not supported??
Well, precisely!
Digging further, the IOS config guide does mention rapid-PVST:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SY/configuration/guide/spanning_tree.html#wp1078
On 07/11/2011 07:26 PM, Gert Doering wrote:
(Mmmh. Is this IOS? Or IOS XE? I thought the Sup2T was supposed to
ship with something modularish?)
IOS. I've seen a load of roadmap presentations on this thing, and Cisco
have consistently said it would run IOS, and not any of the new variants.
Hi,
> ...and the first thing that stands out in the release notes:
>
> """
> These features are not supported in Release 12.2(50)SY:
>
> •Per-VLAN Spanning Tree (PVST) mode
>
> Note Release 12.2(50)SY supports these spanning tree protocols:
> —Rapid Spanning Tree Protocol (RSTP) is enabled by de
Hi,
On Mon, Jul 11, 2011 at 07:14:41PM +0100, Phil Mayers wrote:
> ...and the first thing that stands out in the release notes:
>
> """
> These features are not supported in Release 12.2(50)SY:
>
> ?Per-VLAN Spanning Tree (PVST) mode
>
> Note Release 12.2(50)SY supports these spanning tree prot
...and the first thing that stands out in the release notes:
"""
These features are not supported in Release 12.2(50)SY:
•Per-VLAN Spanning Tree (PVST) mode
Note Release 12.2(50)SY supports these spanning tree protocols:
—Rapid Spanning Tree Protocol (RSTP) is enabled by default;
—Multiple Span
88 matches
Mail list logo
