Re: [j-nsp] understand "request system software rollback" in Junos

2015-10-16 Thread Martin T
Markus,

I have jbundle packages present in /var/sw/pkg/ directory:

root> file list detail /var/sw/pkg/*jbundle*
-r-xr-xr-x  1 root  wheel  640238884 Oct 1  08:20
/var/sw/pkg/jbundle-13.2R8.2.tgz*
-rw-r--r--  1 root  wheel  735837145 Oct 1  16:12
/var/sw/pkg/jbundle-13.3R6.5.tgz
total files: 2

root>

Looks like those are installed during the system
installation/upgrade(both in case of installation media or jinstall
package).



Oliver,

if I check the release notes for versions 12.3, 13.2, 13.3 or 14.1
then they all say that one can not issue the "request system software
rollback" command to return to previously installed software.
According to Junos command reference, the behavior of "request system
software rollback" command changed in version 12.1. Since Junos 12.1
the "request system software rollback" restores the system to known
good state. What does this known good state mean?

In addition, I have one older router which had Junos 7.4R1.7
installed. I executed "request system snapshot" and then upgraded to
Junos 8.5R4.3 using a jinstall package. Once the router booted up with
the Junos 8.5R4.3 I executed "request system software rollback"
command, but this still does not seem to do anything:

root> show version brief
Model: m20
JUNOS Base OS boot [8.5R4.3]
JUNOS Base OS Software Suite [8.5R4.3]
JUNOS Kernel Software Suite [8.5R4.3]
JUNOS Crypto Software Suite [8.5R4.3]
JUNOS Packet Forwarding Engine Support (M/T Common) [8.5R4.3]
JUNOS Packet Forwarding Engine Support (M20/M40) [8.5R4.3]
JUNOS Online Documentation [8.5R4.3]
JUNOS Routing Software Suite [8.5R4.3]

root> file list detail /var/sw/pkg/

/var/sw/pkg/:
total 750828
-r-xr-xr-x  1 root  wheel   68303371 Oct 16 14:11 jbundle-7.4R1.7.tgz*
-rw-r--r--  1 root  wheel  155872954 Oct 16 14:38 jbundle-8.5R4.3.tgz
-rwxr-xr-x  1 root  wheel  160039672 Oct 16 14:28
jinstall-8.5R4.3-domestic-signed.tgz*
-rw-r--r--  1 root  wheel122 Oct 16 14:38 rollback

root> request system software rollback

root>


Any comments?


thanks,
Martin

On 10/2/15, Olivier Benghozi  wrote:
> http://www.juniper.net/techpubs/en_US/junos13.3/information-products/topic-collections/release-notes/13.3/topic-83364.html#rn-downgrade
> 
>
> "To downgrade from Release 13.3 to another supported release, follow the
> procedure for upgrading, but replace the 13.3 jinstall package with one that
> corresponds to the appropriate release."
>
> and
>
> "Note: After you install a Junos OS Release 13.3 jinstall package, you
> cannot issue the request system software rollback command to return to the
> previously installed software. Instead you must issue the request system
> software add validate command and specify the jinstallpackage that
> corresponds to the previously installed software."
>
>
>> Le 1 oct. 2015 à 22:57, Markus  a écrit :
>>
>> Am 01.10.2015 um 18:25 schrieb Martin T:
>>> When can one use "request system software rollback"?
>>
>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/command-summary/request-system-software-rollback.html
>>
>> "A software rollback fails if any required package (or a jbundle package
>> containing the required package) cannot be found in /var/sw/pkg."
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ifa generation mismatch

2015-10-16 Thread Brad Fleming
Responding to my own post in case others stumble across this post in the 
future. After working with TAC we finally found our root problem.

We had accidentally misconfigured the DSC interface with two IPs. Like so…
unit 0 {
family inet {
filter {
output v4-out-discard;
}
address 192.168.192.189/32
address 192.168.192.190/32 {
destination 192.168.192.189;
}
}
}

The presence of that top address also being the destination for the address 
below caused a mess. The moment we removed the top address all errant logs 
stopped and everything on the system went back to normal.

So if you happen to get hit with log entries like those below check very 
closely your interface address address configurations.

> On Oct 5, 2015, at 10:13 AM, Brad Fleming  wrote:
> 
> Has anyone seen anything like this before?
> 
> Oct  5 09:49:50   rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: Starting 
> interface state recovery
> Oct  5 09:49:50   rpd[3200]: %DAEMON-5-RPD_KRT_IFA_GENERATION: ifa 
> generation mismatch -- ifl dsc.0 rpd 130 kernel 132
> <<>>
> Oct  5 09:49:50   rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: 
> Interface state recovery completed.
> 
> Our log file is filling up every 10mins or so with junk messages from RPD 
> similar to this:
> 
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6: EVENT  lt-11/2/0 index 
> 249  address #0 28.8a.1c.c7.c3.69
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6: EVENT  lt-11/3/0 index 
> 250  address #0 28.8a.1c.c7.c3.92
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 
> 2001:db8:1:386::2 on ifl xe-0/3/0.0. Flag:0.
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 
> fe80::2a8a:1cff:fec7:bc7b on ifl xe-0/3/0.0. Flag:0.
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6: L2circuit IFF Change: IFL 
> xe-11/2/0.1170 flags 0x0, nbr-id 0.0.0.0 vc-id 0
> 
> I see an old post to this list from RAS from 2004 but that’s about all I can 
> find. We’ve been working with JTAC for about a month trying to figure out 
> what’s going on an it just doesn’t seem there’s going to be a simple answer.
> 
> So far we’ve:
> + Disabled and re-enabled all GRES+NSR/NSB
> + Rebooted both REs ("request system reboot both-routing-engines”)
> + Upgraded software from 13.3R6.5 to 14.2R4.9
> + Removed all interfaces getting logged (roughly 30 IFLs) from the device 
> configuration
> 
> None of these steps have stopped the log messages from piling up. Just kinda 
> hoping some others have seen something similar and might be willing to share 
> what you did to resolve the issue. Thanks in advance for any insights!

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp