>On Sun, Oct 31, 2010 at 6:18 PM, wrote:
>> "speed 1000" on a copper port capable of 10/100/1000 disables 10 and 100
>> Mb/s operation by removing those modes from the list of those advertised to
>> the link partner.
>>
>> This may be useful if you would prefer a cable failure on pins 4, 5, 7 or
"speed 1000" on a copper port capable of 10/100/1000 disables 10 and 100 Mb/s
operation by removing those modes from the list of those advertised to the link
partner.
This may be useful if you would prefer a cable failure on pins 4, 5, 7 or 8 to
drop the link and keep it down, rather than reneg
> On Sun, Oct 31, 2010 at 6:18 PM, wrote:
> > "speed 1000" on a copper port capable of 10/100/1000 disables 10 and 100
> Mb/s operation by removing those modes from the list of those advertised
> to the link partner.
> >
> > This may be useful if you would prefer a cable failure on pins 4, 5, 7 o
On Sun, Oct 31, 2010 at 6:18 PM, wrote:
> "speed 1000" on a copper port capable of 10/100/1000 disables 10 and 100 Mb/s
> operation by removing those modes from the list of those advertised to the
> link partner.
>
> This may be useful if you would prefer a cable failure on pins 4, 5, 7 or 8
>
On 10/31/10 5:08 PM, John Neiberger wrote:
>
> Anyway, can you settle this? Let's take a Cisco 4948 as an example.
> Does manually configuring 1000/Full on an interface really do much? If
> so, what exactly does it do? Does it behave in a non-standard way by
> disabling autonegotiation?
>
Disabl
I contend (with no proof whatsoever) that manually configuring
1000/Full on Cisco switches doesn't really do anything since
autonegotiation is required by the 1000Base-T standard. I don't
believe that manually configuring these settings actually disables
autonegotiation. I know others who feel diff
Thank you Łukasz!
2010/10/30 Łukasz Bromirski
> On 2010-10-31 01:31, Jason Leblanc wrote:
>
>> Are there any issues with mixed blades WC-4548& WC-4648 running on the
>> same
>> 4500E-R chassis? It looks like there is an oversubscription difference of
>> 8:1 vs. 2:1 but I assume thats local onl
NX-OS hidden command:
'service unsupported-transceiver'
Brad Hedlund
--
Sent from my mobile phone
(please excuse brevity, typos)
On Oct 31, 2010, at 12:48 PM, "chris stand" wrote:
> I should have added - on the 5K switches, not the routers ( although I do
> care about them as well )
>
>>
>>
I should have added - on the 5K switches, not the routers ( although I do
care about them as well )
>
> Message: 3
> Date: Sun, 31 Oct 2010 08:46:16 -0500
> From: chris stand
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] How to use "unsupported" gbics in Nexus gear
> Message-ID:
>
>
If you are simply trying to disable a command have you thought about doing
so in tacacs? It sounds like it would be simpler and it also has the
benefit of being centralized so you won't need to configure it on each
individual router.
On Sun, Oct 31, 2010 at 5:11 AM, Arie Vayner (avayner) wrote:
On Sun, Oct 31, 2010 at 08:46:16AM -0500, chris stand wrote:
> Hello,
>
> I know there is an IOS command to allow the use of unsupported gbics ,
> Does anyone know if this exists in NX OS ?
service unsupport-transceiver exists on nxos as well.
I have it enabled on both 4.2(4) and 5.0(2a) 7k's
Hello,
I know there is an IOS command to allow the use of unsupported gbics ,
Does anyone know if this exists in NX OS ?
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.net
On Monday, October 25, 2010 10:21:40 pm Benjamin Lovell
wrote:
> If you are doing MPLE TE then you really don't want more
> than one area as then you get into inter-area TE tunnels
> which makes TE optimal path selection harder(not
> possible in some cases).
Of course, you can fix this problem b
On Monday, October 25, 2010 04:50:08 pm Rin wrote:
> I agree with Geoff's post that separating network into
> different OSPF areas cannot reduce LSDB size. If we
> separate into different areas, LSA1,2,3 are generated
> and all routers must trigger SPF for a topology change
> inside an area. If we
On Saturday, October 23, 2010 04:31:01 am Robert Crowe
(rocrowe) wrote:
> There are many different reasons and topologies where
> MPLS can be extended to the access layer depending on
> technical and non-technical requirements. Perhaps Rin
> can elaborate on his topology and what he is trying to
Hi,
On Sun, Oct 31, 2010 at 09:36:59AM +0200, Hank Nussbacher wrote:
> I am looking for a router (not switch) recommendation (upgrade from
> 7204VXR). Have considered the ASR1004 but a bit too expensive. Need now 2
> ports of 10GigE and 4 ports of 1GE with the ability to add in the future 2
>
Tim,
It seems that some of the basic functions we need for this in EEM are not yet
on SXI... Unfortunately, it does not have the latest EEM code yet.
I guess it would be possible with TCL, but I can't give you a quick example for
this right now...
I suggest you try http://forums.cisco.com/eforu
On Sun, 31 Oct 2010, Hank Nussbacher wrote:
I am looking for a router (not switch) recommendation (upgrade from
7204VXR). Have considered the ASR1004 but a bit too expensive. Need now
2 ports of 10GigE and 4 ports of 1GE with the ability to add in the
future 2 more 10GigE ports and 4 more 1GE
I am looking for a router (not switch) recommendation (upgrade from
7204VXR). Have considered the ASR1004 but a bit too expensive. Need now 2
ports of 10GigE and 4 ports of 1GE with the ability to add in the future 2
more 10GigE ports and 4 more 1GE ports. What would you recommend?
Thanks,
19 matches
Mail list logo
