To clarify on the last point: "commit confirmed <number>" specifies the number of miniutes that can pass without another commit before the changes will be automatically rolled back. I use this ALL the time on firewall policies (something like commit confirmed 2 to verify that I'm accomplishing what I want to). It really is a lifesaver. -----Original Message----- From: John Kristoff [mailto:jtk@depaul.edu] Sent: Friday, August 31, 2001 3:59 PM To: nanog@merit.edu Subject: Re: Cisco and Juniper Inter-Operability Issues ??? Devon True wrote:

Any gotchas we should watch out for and any tips/tricks? I read the NANOG archive and saw someone mention OSPF problems with Juniper and to run ISIS. Is that still the case?

I haven't seen any OSPF compatibility problems, including the use of authentication and changes in the default reference-bandwidth between Junipers and Cisco. Tested using JunOS 4.4 and 4.3. As far as the OC3c goes, You may want to preconfigure all the VPIs you'll ever have in advance if you can. Anytime you reconfigure them, the Juniper does a reset of the SAR to reallocate memory to the VPIs. This will cause all your ATM circuits on that interface to bounce. If you setup your peers under a BGP group statement, you will also need a 'peer-as' statement at the group level. You can give it a bogus/private one there just to satisfy the config. I don't think they have fixed this wasn't fixed as of JunOS 4.4. And finally, 'commit confirmed' is your friend. :-) John