Celebrate with us – 1Mio DayOne downloads!

It’s finally happening: In April, the Juniper DayOne Books will hit 1Mio downloads!
A-m-a-z-i-n-g I tell you!


For this Special Event, Juniper has a lot to offer – check out the Site
https://www.juniper.net/us/en/dm/day-one-million/ from time to time during April for special discounts and exclusive bundles.

You should also have a look at the author stories at https://www.juniper.net/assets/us/en/local/pdf/ebooks/dayone-million-stories.pdf

But hey – why is your story in German you might ask. I did this because of 3 reasons.

First, most of the Germans are a bit lazy when it comes to interacting with others in English. Don’t ask me why (I’m not a typical German in many ways) but I experienced this over and over again. Therefore I decided that it would be interesting to add a little German to the stories so more “native” Germans would be able to see, how awesome this journey was for me.
We were told that we could either write in English or in our native language – and guess what?
Looks like I was the only one doing this 😀
Maybe we should start a “Multilanguage DayOne Book” where the books are either written in different Languages per recipe or we take one book and translate it into as many Languages as we can find?
I would be in of course.

Second, diversity is great and it’s always a difference if someone has to write in his native language or in English (subtext is the buzzword here) and the more people contribute in other languages, the better. I love to learn new things – why not learn a few words of Spanish, French, Canadian, Italian or whatsoever?

There’s also a third reason for this – if you want to know it, feel free to reach out to me.
Don’t worry – I rarely bite so it’s safe 😉

In case your German is a little rusty, here’s my Interview in English (you could also use google translate but yeah… Good Luck with that…):

###

“Ich erinnere mich noch sehr gut daran, als ich die Anfrage erhielt am Ambassadors Cookbook 2019 mitzuwirken. Natürlich fühlte ich mich geehrt – hatte aber zeitgleich auch wichtige Projekte vor mir, die nicht darunter leiden durften. Irgendwie schaffte ich es dann doch zwischen all den Projekten und meinem Expert-Nachtlab die beiden Artikel fertigzustellen. Ich tauschte mich dazu mit vielen Experten aus, die bereits Bücher veröffentlicht hatten. Da sich viele Kunden mit dem Thema MC-LAG auseinandergesetzt hatten, es aber immer wieder zu Problemen kam, entschloss ich mich, dieses Thema besonders zu behandeln. Ebenso nahm ich mit das Thema ZTP erneut vor, da auch dieses Thema meiner Meinung nach den Puls der Zeit trifft – hierfür hatte ich bereits wertvolle Erfahrungen bei unseren Kunden gesammelt und die Rückmeldungen waren gigantisch. Es ist meiner Meinung nach wichtig, dass es die DayOne books gibt und diese immer wieder einen Refresh erhalten. Diese Bücher helfen IT-Experten auf der ganzen Welt innerhalb kürzester Zeit wertvolles Wissen aufzubauen. Bei diesem Vorgang unterstütze ich natürlich gerne mit meinem Fachwissen.”

###

“I still remember the day when Patrick asked me if I wanted to contribute to the Ambassadors Cookbook 2019. I felt honored, but at that time I also had very important projects that I didn’t want to suffer because of my contribution. I managed it to somehow finish both of the recipes between the projects and my nightly Expert-Labs (JNCIE-DC is only a week away). Because MC-LAG was very popular at our customer’s setups but they faced a lot of issues mainly because of wrong setups I decided to give this topic special attention. Also, ZTP was a hot topic (and it’s still a hot topic) at the time of writing the recipes. I already learned a lot while working for our customers and the feedback was astounding. In my opinion, DayOne books are very important and they also need to be refreshed and re-released from time to time to be up-to-date. In my opinion, Juniper does this job very well and the authors are amazing. DayOne books help IT-Experts all over the world to build valuable knowledge and experience. And of course, I love to help with my knowledge and experience.”

###

Hopefully, there will be more “native” content in the future for all of us 🙂
My fellow ambassadors already mentioned some Ideas on Twitter – stay tuned.

EVPN-VXLAN on (v)QFX-Series Devices

What could be more refreshig than setting up a nice little EVPN-VXLAN on your vQFX just for fun?
This blog post will show you how to do it and break down the important parts.

We will be looking at the following topology (designed on EVE-NG) and implement an EVPN-VXLAN spine and leaf config so that our virtual servers named Win and Winserver are able to communicate with each other. On top we will configure Winserver for multihoming:

EVPN-VXLAN Topology on EVE-NG

In case you already know EVPN and just want to take a look at the sample-config, you can jump at the end of this blog post, where I post the full code for the setup (excluding Windows Server NIC-Teaming with LACP). If you want to know how to use NIC-Teaming on Windows Server 2016 simply go to google – there are tons of instructions (with LACP and without) but this setup uses one with LACP.

Step1: Create the Topology itself.

Before implementing EVPN-VXLAN you should carefully think about your setup. I’ve seen a lot of setups where the spine and leaf topology is placed “unoptimal” and later on might cause trouble. Therefore I advise you to think carefully about the topology itself and also about the surrondings that you might need (like route-reflectors or VC-Fabrics). Once you got that out of the way it’s time to sit down and build the setup and prepare the connections needed – for my tests I usually use EVE-NG because with EVE-NG it’s very easy to “patch” all the cords needed on the fly (with Pro even when the devices are powered on). I advise you to always PoC a setup like this to avoid unnecessary surprises when implementing it. Usually when prepping this and doing a PoC there are many things that you might see different after the PoC – this will help you to find the optimal setup for your company.


We start with the connections from Spine-1 to all four leaf devices:

set interfaces xe-0/0/0 unit 0 description “to Leaf 1”
set interfaces xe-0/0/0 unit 0 family inet address 172.16.1.100/24
set interfaces xe-0/0/2 unit 0 description “to Leaf 2”
set interfaces xe-0/0/2 unit 0 family inet address 172.16.3.100/24
set interfaces xe-0/0/4 unit 0 description “to Leaf 3”
set interfaces xe-0/0/4 unit 0 family inet address 172.16.5.100/24
set interfaces xe-0/0/6 unit 0 description “to Leaf 4”
set interfaces xe-0/0/6 unit 0 family inet address 172.16.7.100/24


You can edit the adress-schema as you like – I personally use the 172.16/16 quite often for my labs and setups, where I need private v4 adresses.
Also you should configure lo0-adresses for management and later for identification of your local device:

set interfaces lo0 unit 0 family inet address 172.16.50.1/32

As last part of this step you can already configure your xe/ae-Interface towards your server(s) and equip it with an esi-number:

set interfaces xe-0/0/8 description “to Server”
set interfaces xe-0/0/8 ether-options 802.3ad ae0
set interfaces ae0 encapsulation ethernet-bridge
set interfaces ae0 esi 00:01:01:01:01:01:01:01:01:01
set interfaces ae0 esi all-active
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 aggregated-ether-options lacp system-id 00:00:00:01:01:01
set interfaces ae0 unit 0 family ethernet-switching vlan members vlan10


Step 2: Create the Underlay

Next, you should define some local system settings for your underlay network:

set routing-options router-id 172.16.50.1
set routing-options autonomous-system 65500


Your underlay will be vital for your Overlay – obvious right? But this part can be tricky – especially with route reflectors. In our case, we will make it simple by using plain EBGP.
Why EBGP? Because with EBGP you can scale out your EVPN to infinity and beyond 😉
You could, of course, use OSPF for your underlay network but the drawback is scaling – most customers use EVPN because VC, VCF, JunOSFusion and so on do not scale out the way EVPN does it.
And when comparing OSPF vs BGP in terms of scale – well – you already know who will win, right?
So we start with creating a group called “underlay”. I personally would advise you to use a naming that fits the purpose. It doesn’t help you to name your underlay group to G884F6S2 or similar because in one to two weeks nobody will remember what you meant with this description. That’s different if you manage a lot of devices (maybe because you are a systems integrator for your customer) and have a clean documentation:

set protocols bgp group underlay type external
set protocols bgp group underlay description “to Spines 1/2”
set protocols bgp group underlay export directs
set protocols bgp group underlay multipath multiple-as
set protocols bgp group underlay neighbor 172.16.3.100 peer-as 65500
set protocols bgp group underlay neighbor 172.16.4.100 peer-as 65600


You should also create a Policy to export your directly connected networks to the underlay so that you have full-mesh connectivity and your loopback-adresses will be redistributed into your BGP underlay:

set policy-options policy-statement directs term 1 from protocol direct
set policy-options policy-statement directs term 1 then accept


After doing this on all spines / leafes (of course with different AS-numbers and IP’s) you should have a nice BGP-Fabric.

BGP Topology

Time for the next step – the overlay

Step 3: Create the EVPN-VXLAN Overlay

Now it’s time for the funny part – the EVPN-VXLAN overlay.
Start by adding an overlay group for your MP-IBGP connection between the leaf devices. Because your iBGP will transport the EVPN-Packets, it’s often referred to as MP-BGP or MP-iBGP (multiprotocol bgp):

set protocols bgp group overlay type internal
set protocols bgp group overlay local-address 172.16.20.1
set protocols bgp group overlay family evpn signaling
set protocols bgp group overlay local-as 65700
set protocols bgp group overlay multipath
set protocols bgp group overlay neighbor 172.16.10.1
set protocols bgp group overlay neighbor 172.16.30.1
set protocols bgp group overlay neighbor 172.16.40.1


Now it’s time for your loopback-address to really shine.
Specify the loopback interface as the source address for the VTEP tunnel and also, specify a route distinguisher to uniquely identify routes sent from this device:

set switch-options vtep-source-interface lo0.0
set switch-options route-distinguisher 172.16.20.1:1

Doesn’t look scary if you break it down, right?
The key in complex setups is to break the config down to smaller parts.
This way, you can solve almost any problem.

Next, you specify the VRF-Import and Export Policy and add your EVPN-Protocol Options regarding VNI’s and the Multicast-Mode: :

set switch-options vrf-import LEAF-IN
set switch-options vrf-target target:9999:9999

set protocols evpn vni-options vni 10 vrf-target export target:1:10
set protocols evpn encapsulation vxlan
set protocols evpn multicast-mode ingress-replication
set protocols evpn extended-vni-list 10


Following up with the VRF import policy to accept EVPN routes advertised from your other leaf devices:

set policy-options policy-statement LEAF-IN term import_leaf_esi from community comm-leaf_esi
set policy-options policy-statement LEAF-IN term import_leaf_esi then accept
set policy-options policy-statement LEAF-IN term import_vni10 from community com10
set policy-options policy-statement LEAF-IN term import_vni10 then accept


We also set the community targets and configure some load balancing:

set policy-options community com10 members target:1:10
set policy-options community comm-leaf_esi members target:9999:9999

set policy-options policy-statement loadbalance then load-balance per-packet
set routing-options forwarding-table export loadbalance


Finally, we define a server facing VLAN (in our example vlan 10) and equip it with a VNI number:

set vlans vlan10 vlan-id 10
set vlans vlan10 vxlan vni 10
set vlans vlan10 vxlan ingress-node-replication

Step 4: Add your Clients and verify the Setup

Congrats – your EVPN is just a commit away. Do it – this part is about what happens “after the BANG”. At this point your EVPN should be up and running – YAY. But what now? How can we check what the EVPN does for us? Lets get to it.

show bgp summary - EVPN-VXLAN

As you can see, in the given Topology, our bgp receives routes from the underlay and also our bgp.evpn gets Infos from our overlay. So far so good. But what about our EVPN-Database?

EVPN Database

Sweet – our 2 Hosts are already inside the EVPN-Database and as you can see, one is multihomed and one is single-homed. You can immediately see that because the Active source is different. While the multihomed Server is sourced from an esi (hence the esi-number as source) so basically from multiple leaf devices, the single-homed device is sourced from the leaf device with the loopback address 172.16.40.1 (Leaf-4).

Ethernet Switching Table - EVPN

Both of them are also added to each leaf devices local ethernet-switching table. So regardless of the Leaf you connect the Devices to, they will have full Layer-2 reachability across your EVPN-VXLAN – AWESOME! You can simply test this, by pinging from one Device to another 😉

Now imagine each leaf device resides in a different DC or Building – no more do you need to worry about DC stretching – all you need is a solid underlay to build your Infrastructure on. With Contrail, managing your EVPN-VXLAN is even more convenient – but that will be written in a later blog post.

I also tried to add it to JunOS Space, because you can (thanks to EVE-NG) link your Lab to the real world and discover all the devices into your JunOS Space. I was actually impressed, that the vQFX can be added to Space (just discover them with ping only and add snmp later, else the discovery will fail because of the snmp string that is used by the vQFX).

With the “IP Connectivity” however, Space seems to be a bit drunk – but since I only wanted to see if it roughly could manage my EVPN. I would say: Not at this point 😀

Hopefully you now have less fear, when someone mentiones EVPN-VXLAN.
And for those who came here just to snag the conig to play with it, here it is 😉

MC-LAG on vQFX (EVE-NG)

Hi all,

today I’m gonna show you how to implement MC-LAG on the vQFX (QFX10k codebase) on EVE-NG. I personally found this pretty straight forward to configure but since I recieved so many Mails asking me to show this, I will do.

Here’s the very simple Topology (click to enlarge):

And here’s the Code – as you can see it’s not that hard but you have to remember some things:

When configuring MC-LAG always remember that the following settings must match on both Members of the MC-LAG:

LACP System-ID + Key
MC-AE ID + Mode
VLAN’s (ICL and Member VLAN’s)

 

The following settings must be unique for each Member of the MC-LAG:

MC-AE Chassis-ID + Status Control
ICCP IP (Local) and Peer IP (who would have guessed this…)
MC-LAG Protection 

 

I will give you more explanation on this Topic later because as you might have heard my JNCIE-DC is booked for the 14th of February (therefore not so much time to write detailed Blogposts) and time is slowly running away… Okay just kidding – time just took a SPRINT towards my deadline… However, my beard looks fine so far…

Update 15.02.2019:
It can happen, that your vQFX-Devices all have the same MAC! Therefore (as a workaround) you can set the irb-mac static on one of the MC-LAG “Core” Devices:

set interfaces irb unit 500 mac 00:00:00:00:00:05

This way your MC-LAG will come up as expected 😉

The final Countdown for the JNCIE-DC

Just 38days of labbing until the JNCIE-DC Exam-Day has arrived.
Exam is already booked and I am so excited to do this (way more than with the first JNCIE because I already know what awaits me in terms of the trip to Amsterdam, the Exam-Room etc.) – and I feel way more confident about the Topics (EVPN really kicks ass) 😉

I would love to share some EVE-NG Topos – however, I only work with the official inetZero Superlabs this time and therefore can’t legally share anything.

After the Exam I will try to develop some Training to share for the SEC and DC-Exams to prep you for the final day – in the meantime –> stay tuned 😉

Certification recap: 2018 was Epic

With 2018 slowly fading away, I did a recap of this Year (Certification wise).

2018 was probably my toughest Year yet – but also my most exciting so far.
At the beginning of 2018 I switched to Telonic in the middle of my JNCIE-SEC preparation. Regardless of the new Job, I somehow managed to maintain my pace towards this Goal and on the 3rd of July in my 4th Attempt I became JNCIE-SEC #374

When I checked my CertManager I simply could not believe what I managed to do this Year – see for yourself:

New Certifications:
JNCIE-SEC
JNCIP-DC
JNCDS-SP
JNCIA-Cloud + JNCIS-Cloud
JNCIA-DevOps + JNCIS-DevOps

Recertified:
JNCDS-DC

Getting a new Certification and maintaining in in daily Business can be challenging – everybody knows that. This Year I managed to get 7 – yes, 7!!!!!! new Certifications and recertified one – HOLY COW… Even if you consider JNCIA-DevOps and JNCIA-Cloud not as “achieved” because they were granted due to the JNCIS-DevOps and JNCIS-Cloud – this was insane…
My Goal was to get my first Expert – I got way more than I expected.

Nice to know, that in 2019 I “only” have to defend my JNCIP-ENT and JNCDS-SEC – and my Personal Goal as you know is getting my JNCIE-DC #NoPressure

This pace will be hard to maintain and I’m sure that I won’t be able to do this forever (and luckily I don’t need to) – but the good news is, that I’m still just 29 Years old, always eager to learn new Stuff and if I keep this pace have all 4 Experts before… Nah – I keep this one my personal Secret 😉

Enjoy the time with your family and friends. Looking forward to see all of you in 2019 🙂

JNCIE-SEC Beta Exam is out

Recently Juniper announced the new and shiny JNCIE-SEC Beta exam (JPR-933).
That must hurt all my fellow haters who constantly insisted, that Junipers SEC-Track is dead – well – beat it, guys! 😉

 

https://www.juniper.net/uk/en/training/certification/news/2018/20181022-new-jncie-sec-jpr-933-beta-exam/

Beta exams for the new JNCIE-SEC Lab Exam (JPR-933) will be available soon!
Testing will be offered during certain JNCP Lab Exam events in December and January.

 

This does however also mean, that if you have already studied with the old inetzero books and materials, you need to be aware of the changes. The biggest change, in my opinion, is the addition of JunOS Space Security Director and SDSN / SkyATP. Not sure, what will be exactly in this exam, however, this sounds like a lot of new sub-topics that you need to be aware of. My guess is, that the Bootcamp and the inetzero workbooks will be updated soon.

Software Release:

  • vSRX Services Gateway: 18.2 –> NIIIIICE 😀
  • vQFX Ethernet Switch: 17.4
  • Junos Space Security Director: 18.2

I’m very very happy that the new SEC-E will use the full virtual possibilities of vSRX and vQFX – my guess is, that this will be a fully virtual Lab – no Hardware needed. This is also very interesting for me because I already did the last one fully virtual during my preparation – after all my Nickname is Mr. vSRX 😉

Juniper NXTWORK EMEA 2018 – just couple of days away

Of course, you already noticed, that the NXTWORK EMEA is just a few days away and I haven’t blogged very much lately. Mostly because of a very very big Project for us at Telonic – but there’s light at the End of the Tunnel 😉

Fair Warning: I will blog the shit out of NXTWORK and Twitter will need a couple of extra Servers just for my Tweets – it will be like you are there with me 😛

Stay tuned.