On 5/11/2011 10:43 PM, Jeff Kell wrote:
> The issues with high CPU utilization when making configuration changes
> (hulc running con process replicating changes to other stack members) is
> reported fixed in 12.2(58)SE1.
>
> But there is a small problem...
>
> The image is available for 3560, 3560X
The issues with high CPU utilization when making configuration changes
(hulc running con process replicating changes to other stack members) is
reported fixed in 12.2(58)SE1.
But there is a small problem...
The image is available for 3560, 3560X, 3750, 3750E, 3750X. But *NOT*
the 3750G-12S.
Th
On Wed, 11 May 2011, Peter Rathlev wrote:
On Wed, 2011-05-11 at 05:58 -1000, Antonio Querubin wrote:
I did make up a random mac though I'm not sure if certain bits must be
turned on or off.
If you set the "locally administered" bit (e.g. "02xx..") you
wouldn't step on anyones toes. :-
On Wed, 11 May 2011, Bill Blackford wrote:
Have you tried:
snmpwalk -Os -c -v2c <1720_IP> ifPhysAddress
All that does is return the manually set address.
Antonio Querubin
e-mail: t...@lavanauts.org
xmpp: antonioqueru...@gmail.com
___
cisco-nsp m
On Wed, 2011-05-11 at 05:58 -1000, Antonio Querubin wrote:
> I did make up a random mac though I'm not sure if certain bits must be
> turned on or off.
If you set the "locally administered" bit (e.g. "02xx..") you
wouldn't step on anyones toes. :-)
--
Peter
___
On Wed, 11 May 2011, Christopher Pilkington wrote:
On Wed, May 11, 2011 at 11:51 AM, Antonio Querubin wrote:
Apparently, the bia address really isn't bia on that particular model :)
Wouldn't a missing hardware MAC be indicative of a corrupt NVRAM or similar?
It may have been but the nvram
I would take the mac address of some device on the other side of the
world, or another 1720 that would not be placed on the same lan and just
clone that one,
I did make up a random mac though I'm not sure if certain bits must be
turned on or off.
Heck, turn 'em all on. Improves connectivity
On Wed, May 11, 2011 at 11:51 AM, Antonio Querubin wrote:
> Apparently, the bia address really isn't bia on that particular model :)
Wouldn't a missing hardware MAC be indicative of a corrupt NVRAM or similar?
___
cisco-nsp mailing list cisco-nsp@puck.
On Wed, 11 May 2011, Jared Mauch wrote:
If you're so inclined, check the edges (and undersides) of all the PCBs
internally. If that doesn't work, just program one or manually set it
on the interface. With a few rare exceptions you can use the same mac
address on multiple physical interfaces
On Wed, 11 May 2011, Tom Storey wrote:
I would have thought it would appear somewhere really obvious like in a
"show interface". The "bia" (burned in address) I would have thought should
come from the MAC controller of the interface itself, not from a location
stored elsewhere on the router...?
Best viewed with a fixed width font... Bottom line if you intend to use the
ASR in this fashion then by all means start harassing your account team to have
"match-in-vrf" type functionality implemented on the ASR. Still the solution
below works (as far as we have tested it), its just not a
That came out all jacked up, obviously. Will attempt to fix.
--- On Wed, 5/11/11, Derick Winkworth wrote:
From: Derick Winkworth
Subject: [c-nsp] VASI NAT on ASR/IOS-XE solved... I hope.
To: cisco-nsp@puck.nether.net
Date: Wednesday, May 11, 2011, 9:49 AM
Best viewed with a fixed width fo
On May 11, 2011, at 9:47 PM, Joe Freeman wrote:
> Anyone have any thoughts on how I should troubleshoot this further, or even
> better, thoughts as to resolution?
Sounds to me as if the box is being packeted.
---
Roland Dobbin
Best viewed with a fixed width font... Bottom line if you intend to use the
ASR in this fashion then by all means start harassing your account team to have
"match-in-vrf" type functionality implemented on the ASR. Still the solution
below works (as far as we have tested it), its just not
I have a customer with an 1841 doing webvpn, running advsecurity-12.4-24.T5.
They have been randomly loosing the ability to connect to resources through
this unit.
A show tcp brief reveals that there are thousands of sockets stuck in
TIMEWAIT. In fact it took almost six minutes for the show tcp br
Have you tried:
snmpwalk -Os -c -v2c <1720_IP> ifPhysAddress
-b
On Wed, May 11, 2011 at 7:26 AM, Tom Storey wrote:
> I would have thought it would appear somewhere really obvious like in a
> "show interface". The "bia" (burned in address) I would have thought should
> come from the MAC contro
I've seen the mac printed on the bottom of the PCB of some devices when taken
apart, as it appears your issue is the embedded mac address is no longer there.
If you're so inclined, check the edges (and undersides) of all the PCBs
internally. If that doesn't work, just program one or manually se
I would have thought it would appear somewhere really obvious like in a
"show interface". The "bia" (burned in address) I would have thought should
come from the MAC controller of the interface itself, not from a location
stored elsewhere on the router...?
On 10 May 2011 18:10, Antonio Querubin
I whole heartedly second that suggestion.
On May 10, 2011, at 5:50 PM, Duleep Pillai wrote:
>
>
> Hi,
> Are you using Radius for operator authentication? Have you tried TACACS+?
>
> Try the free TACACS+ for Windows (if you are a Windows user) from
> www.tacacs.net.
>
> Regards
>
>
> Date
19 matches
Mail list logo
