On Wednesday, February 19, 2014 12:02:58 PM Adam Vitkovsky
wrote:
> Right that requires the HW support, the only platform out
> there that supports 0 packet loss ISSU is Cisco NCS.
Even then, I likely won't try it. There is just too many
moving parts.
Mark.
signature.asc
Description: This is
son Lixfeld
Sent: Tuesday, February 18, 2014 6:33 PM
To: Mark Tinka
Cc: Gert Doering; Cisco NSP; Jared Mauch
Subject: Re: [c-nsp] ARP on ASR9k 4.3.2
You can get that already, with the minuscule number of SMUs out there that
are hitless. /sarcarsm
For full blown, hitless ISSU/SMU/FPD stuff, not a chance
On Wednesday, February 19, 2014 06:55:08 AM Dmitry Valdov
wrote:
> No, it doesn't depend on an update itself, if you have
> "reload" type of SMU. It takes long time because it
> loads RSP(s) first, and once it completed it starts to
> load linecard(s) which have separate copy of IOS XR
> running
On Wed, 19 Feb 2014, Mark Tinka wrote:
Reload SMU or full image or power on.
It is time needed to reload a box..
Well, physically, there is less hardware to deal with in the
ASR9001, so perhaps that could be it.
Part of the reasons - or so I'm told - IOS XR (and its
SMU's) take a while to l
On Wednesday, February 19, 2014 06:01:35 AM Dmitry Valdov
wrote:
> Reload SMU or full image or power on.
> It is time needed to reload a box..
Well, physically, there is less hardware to deal with in the
ASR9001, so perhaps that could be it.
Part of the reasons - or so I'm told - IOS XR (and i
On Wed, 19 Feb 2014, Mark Tinka wrote:
Software loading on ASR9001 takes long time.
But actually upgrading takes about 20 minutes..
I don't care how long it takes to load software to a box
if it doesn't affect traffic.
Anyway 20 minutes is still too much comparing to 76xx
where it takes less th
On Tuesday, February 18, 2014 10:47:39 PM Charles Sprickman
wrote:
> We looked at Juniper as well, and honestly, their
> licensing seemed fairly opaque as well.
Juniper's licensing isn't any better, on the MX anyway.
You have to pay for licenses to support a full table, l3vpn,
e.t.c.
The ven
On Tuesday, February 18, 2014 08:06:38 PM Dmitry Valdov
wrote:
> Software loading on ASR9001 takes long time.
> But actually upgrading takes about 20 minutes..
> I don't care how long it takes to load software to a box
> if it doesn't affect traffic.
> Anyway 20 minutes is still too much comparin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 18, 2014, at 10:35 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Feb 18, 2014 at 03:07:38PM +, Nick Hilliard wrote:
>>> no, 4.x and 5.1.x still run on qnx. you're mixing them up with xr 5.0.x
>>> which runs on a linux kernel.
>>
>> seriously
Software loading on ASR9001 takes long time.
But actually upgrading takes about 20 minutes..
I don't care how long it takes to load software to a box if it doesn't
affect traffic.
Anyway 20 minutes is still too much comparing to 76xx where it takes less
then 10 minutes.
On Tue, 18 Feb 2014,
On 2014-02-18 18:29, Mark Tinka wrote:
were promised it will cut upgrade times from 2hrs to 30x minutes.
I can't grasp why a SW upgrade should take even 30 minutes. Sounds broken,
whatever Cisco says
/Anders
___
cisco-nsp mailing list cisco-nsp@p
On Tuesday, February 18, 2014 07:33:18 PM Jason Lixfeld
wrote:
> You can get that already, with the minuscule number of
> SMUs out there that are hitless. /sarcarsm
I have a glass of beer for every hitless SMU out there :-).
> For full blown, hitless ISSU/SMU/FPD stuff, not a chance
> in hell.
You can get that already, with the minuscule number of SMUs out there that are
hitless. /sarcarsm
For full blown, hitless ISSU/SMU/FPD stuff, not a chance in hell.
On Feb 18, 2014, at 12:29 PM, Mark Tinka wrote:
> On Tuesday, February 18, 2014 05:32:21 PM Gert Doering
> wrote:
>
>> Understoo
On Tuesday, February 18, 2014 05:32:21 PM Gert Doering
wrote:
> Understood. OTOH, ASR9k is fully new for us anyway, and
> there seem to be enough weird things in 4.x as well...
> so maybe I'll save myself the hassle of understanding
> 4.x and upgrade-to-5.x :-)
Features aside, I'm only interest
On 18/02/2014 15:35, Gert Doering wrote:
> I'm wondering, just for a small moment, whether there is any sanity left
> inside *any* Cisco BU.
cisco procedure for product naming / version numbering:
1. examine tea leaves / entrails / lunar signs
2. use entropy from #1 to generate random sequence of
Hi,
On Tue, Feb 18, 2014 at 03:07:38PM +, Nick Hilliard wrote:
> > no, 4.x and 5.1.x still run on qnx. you're mixing them up with xr 5.0.x
> > which runs on a linux kernel.
>
> seriously Gert, how can you make such a basic mistake here? What is so
> similar about version numbers 5.0 and 5.1
Hi,
On Tue, Feb 18, 2014 at 04:16:21PM +0100, Adam Vitkovsky wrote:
> I'd stay away from 5.x in production. It's a brand new OS architecture
> (though not sure if it's true for XR for ASRs as well).
> Anyways it's a new train => new features => new bugs.
Understood. OTOH, ASR9k is fully new fo
her.net] On Behalf Of Gert
Doering
Sent: Tuesday, February 18, 2014 3:40 PM
To: Jared Mauch
Cc: Gert Doering; Cisco NSP
Subject: Re: [c-nsp] ARP on ASR9k 4.3.2
Hi,
On Tue, Feb 18, 2014 at 09:16:38AM -0500, Jared Mauch wrote:
> Or look at 5.1.1 now that it's released.
Is this the majo
On 18/02/2014 15:00, Nick Hilliard wrote:
> On 18/02/2014 14:40, Gert Doering wrote:
>> Is this the major upgrade that was rumored, with a different OS underneath,
>> and a fully new upgrade algorithm, etc? (Our first ASR9001 is coming
>> "soon" :-) )
>
> no, 4.x and 5.1.x still run on qnx. you'
On 18/02/2014 14:40, Gert Doering wrote:
> Is this the major upgrade that was rumored, with a different OS underneath,
> and a fully new upgrade algorithm, etc? (Our first ASR9001 is coming
> "soon" :-) )
no, 4.x and 5.1.x still run on qnx. you're mixing them up with xr 5.0.x
which runs on a lin
Hi,
On Tue, Feb 18, 2014 at 09:16:38AM -0500, Jared Mauch wrote:
> Or look at 5.1.1 now that it's released.
Is this the major upgrade that was rumored, with a different OS underneath,
and a fully new upgrade algorithm, etc? (Our first ASR9001 is coming
"soon" :-) )
gert
--
USENET is *not* the
I dunno. 5.1.1 still has loads of open bugs. I personally wouldn't trust it
quite yet on critical kit especially since full ISSU is still some pipe dream.
On Feb 18, 2014, at 9:16 AM, Jared Mauch wrote:
>
> On Feb 17, 2014, at 10:20 AM, Jason Lixfeld wrote:
>
>> With the number of SMUs you
On Feb 17, 2014, at 10:20 AM, Jason Lixfeld wrote:
> With the number of SMUs you will have to install, you should probably just
> cut your losses, repartition and turboboot to 4.3.4.
Or look at 5.1.1 now that it's released.
- Jared
___
cisco-nsp
On 17/02/2014 16:47, Aaron wrote:
> Thanks Nick, So is ssh gone from 4.3.4 or is there a fix ?
no, ssh is still there, but there's a bug associated with it. Actually,
the bug appeared in 4.3.2, but is fixed in 4.3.2SP1 and internal rebuilds
of 4.3.4.
nick
Thanks Nick, So is ssh gone from 4.3.4 or is there a fix ?
Aaron
-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick
Hilliard
Sent: Monday, February 17, 2014 9:33 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ARP on ASR9k 4.3.2
On 17
On 17/02/2014 15:16, Aaron wrote:
> I want to upgrade from 4.1.2 to 4.3.4. Anything I should be aware of that
> y'all can think of off the top of your heads?
That's a lot of upgrading.
Beware of XR 4.3.4 bug ID CSCuj61034: "Can't SSH into router". In a
percentage of upgrades, you cannot ssh int
M
> To: Gert Doering
> Cc: Cisco NSP
> Subject: Re: [c-nsp] ARP on ASR9k 4.3.2
>
> Hi,
>
> On Thu, Jan 16, 2014 at 06:32:04PM +0100, Florian Lohoff wrote:
>>> We did the same while waiting for the SMU. The SMU should not be
>>> needed for 4.3.2 - the "ar
rsday, January 16, 2014 12:03 PM
To: Gert Doering
Cc: Cisco NSP
Subject: Re: [c-nsp] ARP on ASR9k 4.3.2
Hi,
On Thu, Jan 16, 2014 at 06:32:04PM +0100, Florian Lohoff wrote:
> > We did the same while waiting for the SMU. The SMU should not be
> > needed for 4.3.2 - the "arp learning lo
On Jan 17, 2014, at 3:30 AM, Mikael Abrahamsson wrote:
> On Fri, 17 Jan 2014, Mark Tinka wrote:
>
>> IOS is riddled with "no ip " to turn off stupidity. If they start
>> going down this path with IOS XR, the clean slate will have been for nothing.
>
> I agree. "Sensible defaults" has been a g
On Fri, 17 Jan 2014, Mark Tinka wrote:
IOS is riddled with "no ip " to turn off stupidity. If they start
going down this path with IOS XR, the clean slate will have been for
nothing.
I agree. "Sensible defaults" has been a good thing in XR.
Was the ARP change even documented? I would guess n
On Thursday, January 16, 2014 07:50:41 PM Gert Doering
wrote:
> (*Bugs* can happen, but insisting that stupidity is
> "expected behaviour" and then undergoing the expense to
> have an off-by-default(!) "make it less braindead"
> switch added to it is really amazing)
Agree.
IOS is riddled with "
Hi,
On Thu, Jan 16, 2014 at 06:32:04PM +0100, Florian Lohoff wrote:
> > We did the same while waiting for the SMU. The SMU should not be needed
> > for 4.3.2 - the "arp learning local" interface command should be
built-in,
> > so hopefully you are good to go.
>
> RP/0/RSP0/CPU0:cr2(config-
> subi
Hi,
On Thu, Jan 16, 2014 at 06:32:04PM +0100, Florian Lohoff wrote:
> > We thought so to. We opened a case - Cisco DDTS CSCty06696 was the
> > result. Cisco did not agree that this was faulty behavior: they insisted
> > that it was correct. The DDTS and SMU are for an option to disable the
> >
Hi,
On Thu, Jan 16, 2014 at 10:48:11AM -0600, Andrew Koch wrote:
> We ran into similar trouble when swapping out our router for an ASR9k
> running 4.2.3. Cisco scrambled a SMU for that release (sorta). From their
> information it is not entirely arbitrary. Any IP that is routed down that
> lin
On Thu, Jan 16, 2014 at 2:35 AM, Florian Lohoff wrote:
>
> Hi,
>
> we made some upgrade from 4.1.1 to 4.3.2 tonight and discovery new and
> strange ARP behaviour.
>
> The ASR9k seems to store arbitrary ARP responses in its MAC Address
> table.
>
We ran into similar trouble when swapping out our
Hi,
we made some upgrade from 4.1.1 to 4.3.2 tonight and discovery new and
strange ARP behaviour.
The ASR9k seems to store arbitrary ARP responses in its MAC Address
table.
In our setup this lead to reachability problems because it had cought
an ARP response for a loopback address of a linux se
36 matches
Mail list logo