Introduction
I am doing the lab from a blog that it was recommended by a person into LinkedIn internal Messaging communication. I do here!
Equipment and installations I used for this project::
- MacBook Pro (15-inch, 2016) with macOS Catalina version 10.15.3
- VMware Fusion PRO Version 11.5.3
- VMware ESXi 6.7
- Juniper vMX 18.1R3.3 for ESXi
The starting point that inspire me is here: https://networkingpills.wordpress.com/2017/10/31/enterprise-service-provider-style-bridging-on-juniper-mx/
Gianni Costanzi said that Chapter 2 of Juniper MX Series book was the source of ideas it include into his blog. I downloaded the book, maybe I will read it … but now I will start with what I have done.
It exist two ways of configuring bridging:
- the simpler Enterprise-style
- the more complex but more flexible Service Provider-style
This is the setup of the lab in EVE-NG. I use a single vMX and I configure logical-systems inside. It is the original setup which include some of my changed.
I get this details: “In this lab we have a Cisco router RT with interface e0/0 configured with two sub-interfaces .100 and .200 with dot1Q encapsulation with tag 1100 and 200, respectively. I’ve put e0/0.100 in VRF100 in order to be able to ping between the two sub-interfaces through the 3 vMX switches (otherwise the ping would be something local to the router).”
I have configured my RT virtual-system workout include this it.
1. The configuration for Cisco & vMX from Enterprise- & Service Provider-Style Bridging on Juniper MX I have used to configure my lab can be found here:
RT.conf vMX1.conf vMX2.conf vMX3.conf
Note: Gianni Costanzi has added some IRB interfaces also on vMX1 and vMX2 that allowed him to debug communication problems while he was experimenting with the configuration.
I do not need it so I delete all IRB interfaces.
2. My vMX (vMX1, xMx2, vMX3 and RT) Configuration
2.1. Starting point configuration:
vMX@vMX# show | no-more ## Last changed: 2020-03-27 10:00:59 UTC version 18.1R3.3; system { host-name vMX; root-authentication { encrypted-password "$6$i9xZAooQ$/R1f/hGsp93jQHYDBxtQd2EOctFSvBJNZr0g4ywIE5yJuESbDystdIPBJpDOs6RTPYvq4DNrCR7YuzsCu/usc1"; ## SECRET-DATA } login { user vMX { full-name "Silvia Murgescu"; uid 2000; class super-user; authentication { encrypted-password "$6$/ZMF.wNA$Kmxxac0LNo64IaefM4pYxGh1gayO76gJ5mD4Gc0ZYfCYGu11mK2lgkCQr8NC4rV0hsvoCDNrDjmoWiOOuOyEd1"; ## SECRET-DATA } } } services { ssh { root-login allow; protocol-version v2; } } inactive: syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } processes { dhcp-service { traceoptions { file dhcp_logfile size 10m; level all; flag all; } } } } chassis { fpc 0 { pic 0 { tunnel-services { bandwidth 10g; } interface-type ge; number-of-ports 8; } lite-mode; } network-services enhanced-ip; } interfaces { ge-0/0/0 { vlan-tagging; } ge-0/0/1 { vlan-tagging; } ge-0/0/2 { vlan-tagging; } ge-0/0/3 { vlan-tagging; } ge-0/0/4 { vlan-tagging; } ge-0/0/5 { vlan-tagging; } ge-0/0/6 { vlan-tagging; } ge-0/0/7 { vlan-tagging; } fxp0 { unit 0 { description For_SSH_Connection; family inet { address 192.168.197.15/24; } } } }
I have availability maximum number of interfaces:
[edit] vMX@vMX# run show interfaces terse | match ge- ge-0/0/0 up up ge-0/0/0.32767 up up multiservice ge-0/0/1 up up ge-0/0/1.32767 up up multiservice ge-0/0/2 up up ge-0/0/2.32767 up up multiservice ge-0/0/3 up up ge-0/0/3.32767 up up multiservice ge-0/0/4 up up ge-0/0/4.32767 up up multiservice ge-0/0/5 up up ge-0/0/5.32767 up up multiservice ge-0/0/6 up up ge-0/0/6.32767 up up multiservice ge-0/0/7 up up ge-0/0/7.32767 up up multiservice
2.2. Configuration for users and passwords for each specific Logical System:
[edit system login] vMX@vMX# top show logical-systems RT; vMX1; vMX2; vMX3; [edit system login] vMX@vMX# show | no-more class RT { logical-system RT; permissions all; } class vMX1 { logical-system vMX1; permissions all; } class vMX2 { logical-system vMX2; permissions all; } class vMX3 { logical-system vMX3; permissions all; } user RT { uid 2004; class RT; authentication { encrypted-password "..."; ## SECRET-DATA } } user vMX { full-name "Silvia Murgescu"; uid 2000; class super-user; authentication { encrypted-password "..."; ## SECRET-DATA } } user vMX1 { uid 2001; class vMX1; authentication { encrypted-password "..."; ## SECRET-DATA } } user vMX2 { uid 2002; class vMX2; authentication { encrypted-password "..."; ## SECRET-DATA } } user vMX3 { uid 2003; class vMX3; authentication { encrypted-password "..."; ## SECRET-DATA } }
3. Configuration for my vMX including vMX1, vMX2, vMX3 and RT as logical-systems
3.1. Changed configuration for vMX1:
Inside vMX interfaces:
[edit] vMX@vMX# show interfaces ge-0/0/1 { description vMX1-to-RT; vlan-tagging; mac 50:00:00:01:00:02; } ge-0/0/2 { description vMX1-to-vMX2; flexible-vlan-tagging; encapsulation extended-vlan-bridge; mac 50:00:00:01:00:03; }
Inside logical-systems vMX1 interfaces:
[edit] vMX@vMX# show logical-systems vMX1 interfaces { ge-0/0/1 { unit 0 { description vMX1-to-RT; family bridge { interface-mode trunk; vlan-id-list [ 100 200 ]; vlan-rewrite { translate 1100 100; } } } } ge-0/0/2 { unit 100 { vlan-id 100; } unit 200 { vlan-tags outer 20 inner 200; } } } bridge-domains { BD100 { vlan-id 100; interface ge-0/0/2.100; routing-interface irb.101; } BD200 { vlan-id 200; interface ge-0/0/2.200; routing-interface irb.201; } }
3.2. Changed configuration for vMX2:
Inside vMX interfaces:
ge-0/0/3 { description vMX2-to-vMX1; flexible-vlan-tagging; encapsulation extended-vlan-bridge; mac 50:00:00:02:00:03; } ge-0/0/4 { description vMX2-to-vMX3; flexible-vlan-tagging; encapsulation flexible-ethernet-services; mac 50:00:00:02:00:05; } ge-0/0/5 { description vMX2-to-vMX3; mac 50:00:00:02:00:04; }
Inside logical-systems vMX2 interfaces:
[edit] vMX@vMX# show logical-systems vMX2 interfaces { ge-0/0/3 { unit 100 { vlan-id 100; } unit 200 { vlan-tags outer 20 inner 200; } } ge-0/0/4 { unit 200 { encapsulation vlan-bridge; vlan-id 200; } } ge-0/0/5 { unit 0 { family bridge { interface-mode access; vlan-id 100; } } } } bridge-domains { BD100 { vlan-id 100; interface ge-0/0/3.100; routing-interface irb.102; } BD200 { vlan-tags outer 2200 inner 1200; interface ge-0/0/3.200; interface ge-0/0/4.200; routing-interface irb.202; } }
3.3. Changed configuration for vMX3:
Inside vMX interfaces:
ge-0/0/6 { description vMX3-to-vMX2; vlan-tagging; encapsulation flexible-ethernet-services; mac 50:00:00:03:00:05; } ge-0/0/7 { description vMX3-to-vMX2; mac 50:00:00:03:00:04; }
Inside logical-systems vMX3 interfaces:
[edit] vMX@vMX# show logical-systems vMX3 interfaces { ge-0/0/6 { unit 200 { encapsulation vlan-bridge; vlan-id 200; } } ge-0/0/7 { unit 0 { family bridge { interface-mode access; vlan-id 100; } } } } bridge-domains { BD100 { vlan-id 100; routing-interface irb.103; } BD200 { vlan-id 200; interface ge-0/0/6.200; routing-interface irb.203; } }
3.4. Changed configuration for RT:
It is difficult for me to install in Juniper something from Cisco. But I tried to install someway … Searching searching searching on internet. I found a Juniper book: DAY ONE: MIGRATING FROM CISCO TO JUNIPER NETWORKS and other blogs, but not sone 100 exact as my problem.
I din’t found a exact solution but all I read on book and internet searching fives me some ideas. I will try this configuration for RT router into JunOS.
Inside vMX interfaces:
edit] vMX@vMX# show interfaces ge-0/0/0 { description RT-to-vMX1; vlan-tagging; }
Inside logical-systems RT interfaces:
[edit] vMX@vMX# show logical-systems RT interfaces { ge-0/0/0 { unit 100 { vlan-id 1100; family inet { address 192.168.100.1/24; } } unit 200 { vlan-id 200; family inet { address 192.168.200.1/24; } } } }
3.5. I checked interfaces:
[edit] vMX@vMX# run show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/0 up up ge-0/0/0.100 up up inet 192.168.100.1/24 multiservice ge-0/0/0.200 up up inet 192.168.200.1/24 multiservice ge-0/0/0.32767 up up multiservice ———————||———————— ge-0/0/1 up up ge-0/0/1.0 up up bridge ge-0/0/1.32767 up up multiservice ge-0/0/2 up up ge-0/0/2.100 up up bridge ge-0/0/2.200 up up bridge ge-0/0/2.32767 up up multiservice ge-0/0/3 up up ge-0/0/3.100 up up bridge ge-0/0/3.200 up up bridge ge-0/0/3.32767 up up multiservice ge-0/0/4 up up ge-0/0/4.200 up up bridge ge-0/0/4.32767 up up multiservice ge-0/0/5 up up ge-0/0/5.0 up up bridge ge-0/0/6 up up ge-0/0/6.200 up up bridge ge-0/0/6.32767 up up multiservice ge-0/0/7 up up ge-0/0/7.0 up up bridge ———————||———————— fxp0 up up fxp0.0 up up inet 192.168.197.15/24 ———————||———————— irb up up irb.101 up up inet 192.168.100.101/24 multiservice irb.102 up up inet 192.168.100.102/24 multiservice irb.103 up up inet 192.168.100.254/24 multiservice irb.201 up up inet 192.168.200.101/24 multiservice irb.202 up up inet 192.168.200.102/24 multiservice irb.203 up up inet 192.168.200.254/24 multiservice ———————||————————
Packets’ flow
The flow of a packet from RT to vMX3 is the following:
- The packet exits RT ge-0/0/0.100 tagged with 1100 and arrives into ge-0/0/1 on vMX1
- vMX1 ge-0/0/1 is configured as a Trunk that allows vlan tags 100 and 200 and translates incoming tag 1100 to 100 and vice versa when it packets leave the interface. Due to tag 100, the packet goes into Bridge-Domain BD100 and then it exits via interface ge-0/0/2.100 and arrives on interface ge-0/0/3.100 of vMX2
- vMX2 ge-0/0/3.100 receives the packet which goes again in BD100 and then it exits untagged via interface ge-0/0/5.100 which is configured as an Access interface. Packets are received by ge-0/0/7.100 on vMX3.
- vMX3 ge-0/0/7.100 is again an Access interface and receives the untagged packets that are placed in BD100.
BD100 is always configured as a Bridge-Domain with single tag 100, so packets received in this Bridge-Domain have this single tag applied to them.
vMX3 has two Integrated Routing and Bridging (IRB) interfaces, one in BD100 and one in BD200, whose purpose is to route packets between the two vlans.
The flow of a packet from vMX3 to RT is the following:
- The packet starts in vMX3 BD200 where irb.200 interface is placed and exits via interface ge-0/0/6.200 tagged with vlan tag 200. It is received on vMX2 on ge-0/0/4.200.
- vMX2 ge-0/0/4.200 receives the packet and places it in BD200. This time BD200 has two tags: 2200 outside and 1200 inside. This means that the incoming packet’s tag 200 is swapped with tag 1200 and then an outer tag 2200 is pushed onto the packet. The packet is then delivered to interface ge-0/0/3.200 which is configured to send packets with outer tag 20 and inner tag 200: this means that tag 1200 is swapped with 200 and 2200 is swapped with 20. The packet is then received by ge-0/0/2.200 on vMX1.
- vMX1 ge-0/0/2.200 receives the packet with outer tag 20 and inner tag 200 and places it within BD200, which is configured with single tag 200. This means that the outer tag 20 must be popped. The packet is then sent out via interface ge-0/0/1 tagged with 200 and it is received by RT on its ge-0/0.200 sub-interface.
Enterprise-style configuration
ENT-style configuration is the simplest way of configuring access and trunk interfaces: I define an interface with family bridge and interface-mode trunk or access and I specify the allowed vlan(s) and the MX automatically places the traffic in the corresponding bridge: if an interface is an access interface with tag 100, its untagged traffic is placed in a bridge with tag 100, if an interface is a trunk with allowed vlans 100 and 200, traffic tagged with 100 is placed in a bridge with tag 100 and traffic tagged with 200 is placed in a bridge with tag 200. This configuration style is the fasted and easier but it allows for less flexibility in interface configuration than Service Provider-style.
Let’s have a look at some interfaces within the lab:
–> vMX1 ge-0/0/1 is configured with a single unit 0 (the only unit allowed with Enterprise Style configuration) and it is a simple trunk with allowed vlans 100 and 200, but it also has a vlan-rewriting configuration that is used to translate tag 1100 to 100 when received from RT:
[edit] vMX@vMX# show logical-systems vMX1 interfaces { ge-0/0/1 { unit 0 { description vMX1-to-RT; family bridge { interface-mode trunk; vlan-id-list [ 100 200 ]; vlan-rewrite { translate 1100 100; } } } } ------------------||---------------------------
–> This interface is automatically placed within BD100:
[edit] vMX@vMX# run show bridge domain BD100 extensive logical-system vMX1 Routing instance: default Bridge domain: BD100 State: Active Bridge VLAN ID: 100 Interfaces: ge-0/0/1.0 ge-0/0/2.100 Total MAC count: 0
On blog appears Total Count: 3. Is this a problem?
–> vMX3 ge-0/0/7 is configured with unit 0 configured in Access mode on vlan 100:
# show logical-systems vMX3 interfaces ge-0/0/7 { unit 0 { family bridge { interface-mode access; vlan-id 100; } } }
Service Provider-style Configuration
SP-style configuration allows for more flexibility and automatic vlan-rewriting, but it requires a bit more configuration. Interfaces supports more than the single unit 0 and interface units must be manually placed within the corresponding bridges. This manual placement of interfaces within BDs is what enables automatic vlan-rewriting, as we will see in some of the following examples.
Let’s have a look at some interfaces within the lab:
vMX1 ge-0/0/2 has two units, 100 and 200:
- unit 100 is configured with single tag 100 and it is manually placed within BD100
- unit 200 is configured with two tags, outer 20 and inner 200, and is manually placed within BD200
[edit] vMX@vMX# show logical-systems vMX1 interfaces { --------------------||----------------------- ge-0/0/2 { unit 100 { vlan-id 100; } unit 200 { vlan-tags outer 20 inner 200; } } } --------------------||----------------------- bridge-domains { BD100 { vlan-id 100; interface ge-0/0/2.100; routing-interface irb.101; } BD200 { vlan-id 200; interface ge-0/0/2.200; routing-interface irb.201; } }
Interface unit 100 and BD100 are both configured with a single tag 100, so there are no vlan-rewriting operations going on:
vMX@vMX> show interfaces ge-0/0/2.100 Logical interface ge-0/0/2.100 (Index 355) (SNMP ifIndex 551) Flags: Up SNMP-Traps 0x20004000 VLAN-Tag [ 0x8100.100 ] Encapsulation: Extended-VLAN-Bridge Input packets : 8192 Output packets: 0 Protocol bridge, MTU: 1522
Packets leaving BD200 through ge-0/0/2.200 or arriving from ge-0/0/2.200 into BD200 must go through a vlan-rewriting step, which happens automatically on the MX, I only need to specify tags for BD and interface unit and link those two elements by putting the interface within the bridge-domain, and then the MX implements the proper vlan-rewriting operations:
vMX@vMX> show interfaces ge-0/0/2.200 Logical interface ge-0/0/2.200 (Index 356) (SNMP ifIndex 555) Flags: Up SNMP-Traps 0x20004000 VLAN-Tag [ 0x8100.20 0x8100.200 ] In(pop) Out(push 0x8100.20) Encapsulation: Extended-VLAN-Bridge Input packets : 0 Output packets: 0 Protocol bridge, MTU: 1522
As you can see from the output above, interface traffic has an outer tag 20 and inner tag 200, so incoming traffic must go through a pop operation, which removes tag 20, while outgoing traffic must go through a push 20 operation, which adds tag 20.
vMX2 ge-0/0/3 has two units, 100 and 200 configured as on vMX1:
- unit 100 is configured with single tag 100 and it is manually placed within BD100
- unit 200 is configured with two tags, outer 20 and inner 200, and is manually placed within BD200. This time we have a double tagged bridge-domain:
[edit] vMX@vMX# show logical-systems vMX2 bridge-domains BD100 { vlan-id 100; interface ge-0/0/3.100; routing-interface irb.102; } BD200 { vlan-tags outer 2200 inner 1200; interface ge-0/0/3.200; interface ge-0/0/4.200; routing-interface irb.202; }
Again, MX automatically knows what to do with the tags in order to exchange traffic between BD200 and ge-0/0/3.200:
[edit] vMX@vMX# run show interfaces ge-0/0/3.200 Logical interface ge-0/0/3.200 (Index 359) (SNMP ifIndex 565) Flags: Up SNMP-Traps 0x20004000 VLAN-Tag [ 0x8100.20 0x8100.200 ] In(swap-swap .2200 .1200) Out(swap-swap .20 .200) Encapsulation: Extended-VLAN-Bridge Input packets : 0 Output packets: 0 Protocol bridge, MTU: 1522
As I can see, MX must do a double-swap of inner and outer labels to translate incoming and outgoing traffic.
Vlan-tagging and Encapsulation type
When configuring bridging interfaces I can enable the use of single or dual tags with different keywords:
- vlan-tagging: it enables the use of single tag
- stacked-vlan-tagging: it enables the use of double tags
- flexible-vlan-tagging: it enables me to mix single and double tags’ units within the same physical interface and gives me the opportunity to specify native vlans for both inner and outer tags (I should give a look to the Juniper MX Series book for further details)
Another flexibility I have is to specify the kind of encapsulation to be used:
- encapsulation extended-vlan-bridge: it applies the vlan-bridge encapsulation to all the units, so it can be used when you have single- or double-tagged units
- encapsulation flexible-ethernet-services: it allows you to specify different per-unit encapsulation. In this way I can have some units which do bridging with vlan-bridge encapsulation, some layer-3 units and some units that do VPLS bridging with vlan-vpls encapsulation.
As I can see in the full configurations attached to the post, I’ve mixed some of the encapsulation and tagging modes in the lab, just for testing purposes.
Conclusion
I perfectly understand that I did not understand too much about the undergoing details of MX bridging, but I’ve just wanted to learn some of the flexibility of this wonderful machine and maybe increase my curiosity about what I can do with it. I plan to read the chapter about Bridging on the Juniper MX Series book which goes into deep details and maybe shows some other more complex configurations.