SRX

Does anyone know if there are tools to ease migration from an SRX240 to a 340?

I'm finding the config files don't just flow straight over between JunOS 12.x and 15.x

Thanks,

 -Ben

p.s. I did see a link for Junipers config converter, but it only seems to do ScreenOS to JunOS.

I did find this...

So maybe this will work for me.

https://forums.juniper.net/t5/SRX-Services-Gateway/SRX240-to-SRX340-conversion/td-p/307351

Cheers,

 -Ben

Right, the tools are tough to find in the reorganization.  This is the the major change is the layer 2 configuration to ELS format so those portions of the configuration can run through this translator.

https://www.juniper.net/customers/support/configtools/elstranslator/

The main documentation describing the changes is here

https://www.juniper.net/documentation/en_US/junos12.3/information-products/topic-collections/ex9200/software-all/getting-started-els.pdf

Thanks for the additional link...

Even the online translater converts one of my lines to 

 set vlans vlan-trust l3-interface vlan.0

And that doesn't work.

The system barks back: error: l3-interface: 'vlan.0': Only IRB interface is supported, e.g. irb.10

I find it disappointing the translator can't take syntax invented by Juniper and properly create the correct new syntax -- also created by Juniper. Seriously Juniper?

Anyway - I need to see what the correct syntax is.

Yes, disappointing that the tool is not catching the old interface reference.

vlan.# interfaces become irb.# in the ELS version.  The number will need to match what is configured under the interfaces heirarchy for the desired VLAN.

That's pretty shameful.

How long as that translator been in place? Why couldn't it be fixed?

Oddly, if I tweak my config file in places that the SRX340 complains, the config loads in. (with some stuff broken)

What's odd is the unit doesn't complain about some items (like PSKs) that the online translator DOES. (and not consistently)

Gravy. 😞

Going to look at l3-interface syntax now... I'm still not able to ping my vlan interfaces (from the console or a remote interface).

  -Ben

I think I about have this set using IRB instead now.

My IRB subinterfaces show being down though...

This is a router I'm configuring on my bench and not in the destination network. Do I need to have connections into the interface ports bound to the vlan that's using the irb.X?

and - can I bind fxp0.0 to a vlan (as an access port)?

Lastly, I've just realized the unit is in L2 Transparent Mode -- do I want L3 mode? This is typically the router on the networks I use them. (going to see if I can find L3 mode information).

 -Ben

Correct, both vlan.x and irb.x virtual interfaces will show down until at least one of the physical interfaces associated with them are link up.

fxp0 cannot be used for any transit traffic as a port.  This can only accept and originate management traffic.  Typically we use this for the OOB address.  This can get tricky because this interface lives in the base or root routing instance.  So if you do have an OOB network and use the interface you may need to move your other interfaces into a virtual  router routing instance to have independent default routes and prevent asymmetrical routing with management traffic.

In transparent mode you cannot do any routing.  and all interfaces are in the same broadcast domain for layer 2.   This is typically used to insert a firewall into a line without having to change any of the current network topology.  So it sounds like you want to switch this back to layer 3 mode.  This may also be the source of some of your errors.

No problem on fxp0. I can leave this way -- was just wondering if it could be bound like that.

irb.x -- yea, I also saw a bug that was apparently in my version dealing with irb interfaces not coming up. I was on 15.1x49-D45... the the link issue was solved (and LACP was added) in 15.1x49-D50. So I upgraded and am now at 15.1x49-D100.6 HOLY COW things have changed. (not sure if that's  good thing yet.)

The message for L2 Transparent mode across the banner went away. Now I'm not sure what mode I'm in. I can only find docs for switching to L2 Transparent mode and even those point to a spot that didn't exist in either version firmware I've seen so far. (sad face)

And I had a chance to look closely through my config -- VPN policies now have the TUNNEL section ignored and when I look through the policies web page, there's no tunnel option anywhere. But they still have lock symbols.... wow - they really shuffled the setup here too.

I always have mixed feeling on changing up well established interfaces when the changes are better -- but clearly cause migration issues.

This system is essentially configured as follows:

GE-0/0/0.0 is family inet with the static IP that plugs into the ISP
GE-0/0/1-11 were/are access ports vlan that's the main network (but not the default. in the past it was VLAN.2)
GE-0/0/12-15 are a 4Gb LACP AE0 trunk group, main network was the native VLAN with 3 other tagged VLANs riding on it over to a big switch Cisco switch.

There are 3 policy based VPN tunnels linking up my office and a couple other client offices to this network.
There is dVPN configured for me to dialup remotely if I wasn't at one of the locations where the VPN tunnels were active.

According to this link though, https://kb.juniper.net/InfoCenter/index?page=content&id=KB31081 it seems I might have my L2/L3 stuff set up correctly. Should I still be able to ping any of my IRB interface IP's from the console (provided the IRB is "up"? -- I would imagine "yes")

now to go figure out the VPN tunnels. bleah.

Pretty sure you would not have been able to configure family inet without an error if you were in transparent mode.  So the interfaces now are likely good.

For the ping test, please confirm that your interface irb.x is assigned to a zone in the security section

security zones security-zones NAME-OF-ZONE

In ScreenOS you set a property of the itnerface to allow ping.  In Junos you do this here at the security zone under host inbound traffic section.  This can be allowed for all interfaces on the zone or individually controlled by interface.

I tried that after my last message and I think it was working.

I have tasks pending that delay my testing this more fully for about another week - but I'll get back to it.

I remember the ScreenOS ICMP Echo reply checkbox.

And yes, I knw about the same for the Zones requirement. I think it was that the IRB.x interfaces were down.

once I had one go back up, that one works. So I just need to fill in my test environment a bit more to make sure everything works as expected.

Now just to figure out the VPNs since that stuff got all shuffled around too. (in policy, there's no "tunnel" command anymore even though the rest of the policy is there and looks like a VPN policy...)

Thanks for your help!