Richard, We are running into similar issues with NSR. Are you running with GRES enabled or have you removed that as well ?
Jasper On Thu, May 23, 2013 at 12:44 AM, Richard A Steenbergen <[email protected]>wrote: > On Tue, May 21, 2013 at 09:01:57PM -0400, Clarke Morledge wrote: > > I was curious to know if anyone has run into any issues with large > > routing tables on an MX causing ISSU upgrades to fail? > > > > On several occasions, I have been able to successfully do an > > In-Software-Service-Upgrade (ISSU) in a lab environment but then it > > fails to work in production. > > > > I find it difficult to replicate the issue in a lab, since in > > production I am dealing with lots of routes as compared to a small > > lab. Does anyone have any experience when the backup RE gets its new > > software, then reboots, but since it takes a long time to populate the > > routing kernel database on the newly upgraded RE that it appears to > > timeout? > > > > I have seen behavior like this with upgrades moving from 10.x to a > > newer 10.y and from 10.x to 11.y. > > We had that issue for many years. There is a hard-coded timeout in the > NSR process which is very easy to hit if you have a box with a large > number of routes. > > We had a case open on it for about 1.5 years, but Juniper refused to > actually fix it ("it works fine in the lab"), and eventually we just > gave us and declared ISSU to be dead. There are way too many other bugs > with it anyways, even turning on NSR caused nothing but problems. > > -- > Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
