Firefly Perimeter – OSPF over GRE over IPsec

After attending the JNCIE-SEC bootcamp last week, I saw that one topic was barely mentioned: The way of running OSPF over GRE over IPsec. Since this setup is barely used (because of various reasons) I thought, that this is post-worthy – so here you have a working config (running on FireflyΒ 12.1X47-D35.2

 

Topology:

Config for Firefly-A:

# General Setup
set system host-name Firefly-A
set interfaces ge-0/0/0 unit 0 family inet address 172.16.15.1/30

# IPsec Part
set interfaces st0 unit 0 family inet address 172.16.16.1/30
set security zones security-zone VPN interfaces st0.0
set security ike proposal ike_aes_128 dh-group group5
set security ike proposal ike_aes_128 authentication-method pre-shared-keys
set security ike proposal ike_aes_128 authentication-algorithm sha1
set security ike proposal ike_aes_128 encryption-algorithm aes-128-cbc
set security ike policy ike_p1 mode main
set security ike policy ike_p1 pre-shared-key ascii-text juniperipsec123
set security ike policy ike_p1 proposals ike_aes_128
set security ike gateway Firefly_B ike-policy ike_p1
set security ike gateway Firefly_B external-interface ge-0/0/0.0
set security ike gateway Firefly_B address 172.19.15.2
set security ipsec proposal ipsec_p2 protocol esp
set security ipsec proposal ipsec_p2 authentication-algorithm hmac-sha1-96
set security ipsec proposal ipsec_p2 encryption-algorithm aes-128-cbc
set security ipsec policy p2_ipsec proposals ipsec_p2
set security ipsec vpn VPN_To_Firefly_B ike gateway Firefly_B
set security ipsec vpn VPN_To_Firefly_B ike ipsec-policy p2_ipsec
set security ipsec vpn VPN_To_Firefly_B establish-tunnels immediately 
set security ipsec vpn VPN_To_Firefly_B bind-interface st0.0

# GRE and OSPF Part
set interfaces gr-0/0/0.0 tunnel source 172.16.16.1
set interfaces gr-0/0/0.0 tunnel destination 172.16.16.2
set interfaces gr-0/0/0.0 family inet address 172.16.16.5/30
set security zones security-zone DMZ interfaces gr-0/0/0.0 host-inbound-traffic system-services ping
set security zones security-zone DMZ host-inbound-traffic protocols ospf
set protocols ospf area 0 interface gr-0/0/0.0

 

Config for Firefly-B:

# General Setup
set system host-name Firefly-B
set interfaces ge-0/0/0 unit 0 family inet address 172.16.15.2/30

# IPsec Part
set interfaces st0 unit 0 family inet address 172.16.16.2/30
set security zones security-zone VPN interfaces st0.0
set security ike proposal ike_aes_128 dh-group group5
set security ike proposal ike_aes_128 authentication-method pre-shared-keys
set security ike proposal ike_aes_128 authentication-algorithm sha1
set security ike proposal ike_aes_128 encryption-algorithm aes-128-cbc
set security ike policy ike_p1 mode main
set security ike policy ike_p1 pre-shared-key ascii-text juniperipsec123
set security ike policy ike_p1 proposals ike_aes_128
set security ike gateway Firefly_A ike-policy ike_p1
set security ike gateway Firefly_A external-interface ge-0/0/0.0
set security ike gateway Firefly_A address 172.19.15.1
set security ipsec proposal ipsec_p2 protocol esp
set security ipsec proposal ipsec_p2 authentication-algorithm hmac-sha1-96
set security ipsec proposal ipsec_p2 encryption-algorithm aes-128-cbc
set security ipsec policy p2_ipsec proposals ipsec_p2
set security ipsec vpn VPN_To_Firefly_A ike gateway Firefly_A
set security ipsec vpn VPN_To_Firefly_A ike ipsec-policy p2_ipsec
set security ipsec vpn VPN_To_Firefly_A establish-tunnels immediately 
set security ipsec vpn VPN_To_Firefly_A bind-interface st0.0

# GRE and OSPF Part
set interfaces gr-0/0/0.0 tunnel source 172.16.16.2
set interfaces gr-0/0/0.0 tunnel destination 172.16.16.1
set interfaces gr-0/0/0.0 family inet address 172.16.16.6/30
set security zones security-zone DMZ interfaces gr-0/0/0.0 host-inbound-traffic system-services ping
set security zones security-zone DMZ host-inbound-traffic protocols ospf
set protocols ospf area 0 interface gr-0/0/0.0

Hope, that this helps you if you ever have to do this or need to learn this…
Remember – this is just a sample – please use stringer ciphers if possible πŸ˜‰

The JNCIE-Exam is getting closer and closer…

NAT64/46

      No Comments on NAT64/46

Today I experimented with NAT64 / NAT46 a bit.
The Setup to test this is relatively easy:

I took 2 Windows-Servers (2008R2), one with only IPv4 and one with only IPv6.
The 2 SRX’es are dual-stack capable and have a transfer-subnet (IPv4) between them.

Test-Scenario: Serverv4 pings Serverv6’s “v4-Address”, which is actually a “Proxy-Address” on the SRX and gets the reply – without requiring the v6-Server to have an IPv4-Address. Reverse should be the same: The v6-Server pings a v6-Address but in the Background it is the v4-only Server that replies. This worked very nice and I hope to see more of that in the Future at the customers sites – and I bet I will since IPv6 gains more and more attraction here in Germany πŸ˜‰

How to get rid of Frame 0 and oinker on cli

Have you ever experienced the message

Message from syslogd@srx3 at Jul 20 10:45:39 2017  ...
srx3 srx3 SCHED: Thread 2 (Idle) ran for 1734 ms without yielding 

Message from syslogd@srx3 at Jul 20 10:45:39 2017  ...
srx3 srx3 Scheduler Oinker 

Message from syslogd@srx3 at Jul 20 10:45:39 2017  ...
srx3 srx3 Frame 0: sp = 0x2010f280, pc = 0x200c9e40

when labbing with your vSRX / vQFX / vMX or even with hardware?

 

Calm down – this is nothing to worry about.

 

With the following code your device will “silently drop” the messages for you:

system {
    syslog 	{
        user * 	{
            any emergency;
			match "!(.*Scheduler Oinker*.|.*Frame 0*.|.*ms without yielding*.)";
        		}
			}
		}

Finally my CLI is calm again πŸ˜‰

Source:Β https://kb.juniper.net/InfoCenter/index?page=content&id=KB19723

SRX100 in DimensionData Style

As you all know, I work for DimensionData in Germany. As a matter of fact i really like to mention this wherever I go – it’s my personality to do so because I only work for COmpany’s that I’m “proud” of – else it wouldn’t make sense to work there right?

I recently thought of pimping my old SRX100B with the NeonGreen from DiData – and it turned out pretty damn well for my first time spraypainting πŸ™‚

 

What do you think?
My next Project will be a fire-red SRX240 I have inside my Lab πŸ˜‰

Juniper EMEA SE-Summit 2017 :: Madrid here I come

Finally the time has arrived to pack my stuff and travel to Madrid for the Juniper SE Summit EMEA 2017. The EMEA Summit is by far the greatest event I have been a part of regarding Juniper Networks. Mainly european colleagues and champions who are able to understand the special european procedures and guidelines that are sometimes very hard to understand for colleagues living outside europe – especially data protection and privacy.

Of course I will also participate in my 2 granted exams – would be a shame to waste the possibility to do them for free – however this year there’s a limitation of 2 exams per person per Summit – but I think this is more than enough – after all this Summit is for the Tech-Sessions and not for pure Certification πŸ˜‰ So this time I will try to nail the JNCIS-FWV and JNCIS-QF

I will update this post every evening – so stay tuned πŸ™‚
The Summit will happen from July 11th to July 13th 2017 in Madrid.

The Agenda can be found here:
http://juniper-emea.net/2017JnprUChampionsTechSummit-Agenda?elqTrackId=7920060D1A63B2AF7B70D8C0B3324D88&elq=695f01e85a8c416daaeea26fb7733e07&elqaid=14440&elqat=1&elqCampaignId=3320

 

 

Day 1 – Monday – arrival

This morning we (I took my wife with me so she could enjoy Madrid) went from Oekoven (my Home-Town, 9 houses, 19 cows but FTTH) to Madrid.

As always (plane leaves at 12:05) we had just enough time (arrived at 9.50) thanks to very fast * cough * security officials and baggage drop ladies just so to stand punctual at the gate at boarding time.
Arrived in madrid, I noticed the very nicely built hall of the airport.

Thanks to a great service from the hotel, a driver was ready for our pick-up.
By the way it’s somewhat funny to read the sign “Mr. Scholz”- I’m not used to that πŸ˜‰
Madrid, 33Β° C and many (unlike in Germany) brown plants (see for yourself)

When we arrived at the hotel, I immediately noticed the Juniper registration, which stood proudly at the opposite of the entrance.
My calendar for the next days is ready to rock. Equipped with my green DimensionData Shirt and Basecap we went out to explore a bit of our madrid area, to shop some cans of water and to eat something.

Madrid has really nice small Restaurants – very charming.
Now I’m looking forward to tomorrow when the game begins – after breakfast I scheduled 2 exams πŸ˜‰

 

 

 

 

Day 2 – Tuesday – plenary

Tuesday – first thing to do after Breakfast was heading to the registration. I was surprised to see that Juniper also choose green today πŸ˜›

I got a bag with my badge, a book from juniper (really nice one this time) and of course a shirt.

The next step on my “to do List” was the JNCIS-FWV since more and more of our Customers migrate from ScreenOS to JunOS or still have SSG’s in production. Therefore this certification was my next step. Thankfully I passed πŸ˜‰ I also met the Guys from the Certification Team. Again – it was a big pleasure and honor to meet you guys – thanks for making the Certification possible every year.

After the Certification it was time to meet old friends and Colleagues by the Pool – a little chill before the plenary sessions

Finally it was time for the plenary Sessions – Kireeti time πŸ˜‰ We were introduced into the strategy and what juniper will do next. This year it was really interesting since there were 2 Rooms (i was in a room where they streamed the other room) so there were not like 1000 people sitting on a bird-cage and getting the climate system to crash πŸ™‚ By the way – againΒ Β° C today – tomorrow it will be 37Β° C and for Thursday they told us, that we will reach the 39Β° C – I am afraid πŸ˜€

 

Another cool thing is the Juniper “Game” this year – I still am in the Lead and hopefully defend the first place πŸ˜‰
After all I’m still the No1 Fanboy, right? lol πŸ˜€

vSRX D100 (vSRX 15.1X49-D100) is out

Just tested the new vSRX D100 Version on EVE and ESX.
Compared to D90 it feels (tested on ESX and EVE) way slower but seems to run very good once booted up (tested IPsec, DHCP-Server, DHCP-Client, Policy, OSPF, BGP and Clustering).

The following Graphic shows the time in seconds that the SXR needed from (Amnesiac) Login to cli prompt:

In general the time is almost identical – however the D100 needed significantly longer for boot when compared to the D90.
While the D90 took around 2Minutes from “click on start” to “login prompt”, the D100 needed a whooping 8 Minutes and reacted very very slow afterwards. After a night “idle” it was as responsive as the D90. I’m reading myself through the CHangelog, however I could not find a valid reason for this behavior so far.

 

I will proceed to test the D100 and of course compare D90 with D100 for you to make a good choice for your Home-Labs πŸ™‚

OSPF between a vSRX-Cluster and a standalone vSRX over vQFX on EVE-NG

I promised to deliver this and here it is: OSPF over vQFX πŸ˜‰
These days I lab a lot with EVE and I love it more every day – the possibilities are endless and the Labs are very very quick configured and running. With 2 new CPU’s my EVE now runs with decent Speed so compared to VMware ESX 6.0 there is no extreme performance difference anymore. I can live with that. Since D63 on the vQFX is running very stable and smooth I thought of this small OSPF Lab – I will add more “Quick-Labs” in the Future.

WARNING:
The SRX in Clustermode runs very well on EVE – however there is an optical error. If you build a Cluster, the interface mappings on EVE are completely wrong. This is due to the SRX getting a new interface (em0) as second interface Card – so if you select ge-0/0/0 in EVE, you really select em0.

But why is that you will ask? The answer is simple:
EVE is not aware of Cluster-Naming or Cluster Interfaces – so you have to think twice, what you have to select – I needed Wireshark to see what happened…
From top down the first Interface in EVE is fxp0, the second Interface is em0, the third is ge-0/0/0 or 7/0/0, the fourth is ge-0/0/1 or 7/0/1 and so on (see the Table below from Juniper):

Once I figured that out I could successfully build the Cluster (this time fully working, not just partially) and here is the Lab:

Topology:

 

vSRX-NG5+6 (the SRX-Cluster):

set version 15.1X49-D90.7
set groups node0 system host-name vSRX-NG5
set groups node1 system host-name vSRX-NG6
set apply-groups "${node}"
set system root-authentication encrypted-password "$5$i6krJW/Y$G.KrWGkf3RPukhgAVNOJDY0pdCtCd0TTAOKT3/5/4A3"
set system syslog user * any emergency
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set chassis cluster control-link-recovery
set chassis cluster reth-count 2
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set security zones security-zone internal host-inbound-traffic system-services all
set security zones security-zone internal host-inbound-traffic protocols all
set security zones security-zone internal interfaces reth0.0
set interfaces ge-0/0/5 gigether-options redundant-parent reth0
set interfaces ge-7/0/5 gigether-options redundant-parent reth0
set interfaces fab0 fabric-options member-interfaces ge-0/0/0
set interfaces fab1 fabric-options member-interfaces ge-7/0/0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 10.10.10.2/24
set protocols ospf area 0.0.0.0 interface reth0.0
set protocols lldp interface all

 

 

vSRX-NG7 (the standalone SRX):

set version 15.1X49-D90.7
set system host-name vSRX-NG7
set system root-authentication encrypted-password "$5$6X6aODJh$tmTDU.0wKBkuF0tTDeOJQkaHGVUeVXY8RWJMY9BLpDD"
set security zones security-zone internal host-inbound-traffic system-services all
set security zones security-zone internal host-inbound-traffic protocols all
set security zones security-zone internal interfaces ge-0/0/1.0
set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.1/24
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols lldp interface ge-0/0/1

 

 

Lab-C01 (Coreswitch 01, vQFX running 15.1X53-D63.9):

set version 15.1X53-D63.9
set system host-name LAB-C01
set system root-authentication encrypted-password "$1$YBH6cP7S$QFmKOiVnTEpuot6QaEWYw."
set system services ssh root-login allow
set system services netconf ssh
set system services rest http port 8080
set system services rest enable-explorer
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system extensions providers juniper license-type juniper deployment-scope commercial
set system extensions providers chef license-type juniper deployment-scope commercial
set chassis aggregated-devices ethernet device-count 2
set interfaces xe-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/0 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/10 ether-options 802.3ad ae0
set interfaces xe-0/0/11 ether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options minimum-links 1
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members all
set interfaces em0 unit 0 family inet dhcp
set interfaces em1 unit 0 family inet address 169.254.0.2/24
set protocols lldp interface all
set protocols igmp-snooping vlan default
set vlans default vlan-id 1
set vlans vl-10 description OSPF-VLAN
set vlans vl-10 vlan-id 10

 

 

Lab-C02 (Coreswitch 02, vQFX running 15.1X53-D63.9):

set version 15.1X53-D63.9
set system host-name LAB-C02
set system root-authentication encrypted-password "$1$hy9eoMhU$T.tkfC86QC6LTdln/lYSW/"
set system services ssh root-login allow
set system services netconf ssh
set system services rest http port 8080
set system services rest enable-explorer
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system extensions providers juniper license-type juniper deployment-scope commercial
set system extensions providers chef license-type juniper deployment-scope commercial
set chassis aggregated-devices ethernet device-count 2
set interfaces xe-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/0 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/10 ether-options 802.3ad ae0
set interfaces xe-0/0/11 ether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options minimum-links 1
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members all
set interfaces em0 unit 0 family inet dhcp
set interfaces em1 unit 0 family inet address 169.254.0.2/24
set protocols lldp interface all
set protocols igmp-snooping vlan default
set vlans default vlan-id 1
set vlans vl-10 description OSPF-VLAN
set vlans vl-10 vlan-id 10

 

Download this Lab for your EVE here: (Size 16kB, zip-Archive)
EVE-OSPF-vSRX-vQFX-Lab

Running vQFX 15.1X53-D63 on EVE (KVM)

The KVM version of the latest vQFX routing engine VM (vqfx10k-re-15_X53-D63) seems to be broken. If you try to run it, it will crash with a kernel9 panic and will never boot up completely.
However you can “cheat your way around this”:

1.) Simply download the Vagrant .box file of the D63 RE.
2.) Extract the .box File with 7zip – you will extract a file with no extension.
3.) Extract this file again and “magically” a file called packer-virtualbox-ovf-1491593710-disk001.vmdk will appear.
4.) Upload this to eve, convert it to hda.qcow2, fix permissions and run it – voila: D63 on EVE.

 

PFE is the same (no D63 Version available, since the PFE is not tied to a Software Version).

It’s always a good idea to dig around the provided Files from Juniper once something breaks πŸ˜‰

Download the Files here:Β http://www.juniper.net/support/downloads/?p=vqfxeval#sw

EX2200-C and JunOS 15.1R6.7

Today I installed the 15.1R6.7 on my EX2200-C at home – this Release fixed one of the most annoying Bugs –> The Temp-Sensors are now “seen” again and the red-alert is gone.

root@OEK-EX2200C-01> show version 
fpc0:
--------------------------------------------------------------------------
Hostname: OEK-EX2200C-01
Model: ex2200-c-12p-2g
Junos: 15.1R6.7
JUNOS EX  Software Suite [15.1R6.7]
JUNOS FIPS mode utilities [15.1R6.7]
JUNOS Online Documentation [15.1R6.7]
JUNOS EX 2200 Software Suite [15.1R6.7]
JUNOS Web Management Platform Package [15.1R6.7]

{master:0}
root@OEK-EX2200C-01> show chassis environment 
Class Item                           Status     Measurement
Power FPC 0 Power Supply 0           OK        
Temp  FPC 0 GEPHY1                   OK         0 degrees C / 32 degrees F
      FPC 0 GEPHY2                   OK         50 degrees C / 122 degrees F
      FPC 0 GEPHY3                   OK         50 degrees C / 122 degrees F
      FPC 0 GEPHY4                   OK         50 degrees C / 122 degrees F

By setting GEPHY1 to 0 degrees C the Alarm has no intention to cry – and finally my Juniper-Rack is green again – thanks Juniper πŸ™‚

root@OEK-EX2200C-01> show chassis alarms 
No alarms currently active

{master:0}
root@OEK-EX2200C-01> show system alarms 
No alarms currently active

In the next days I will lab some more with this release – I expect it to be “recommended” ASAP by Juniper because 99% of our Customers didn’t move from 12 to 15 due to this nasty optical bug. Of course there are also some problems with dot1x in 15.1R5 but that’s a different story πŸ˜‰