Stretched VLAN over MPLS/GRE/IPSEC on SRX

Its been a long time since I last posted but I felt this was worth the effort, as there was so many incorrect posts around on this subject. That is not to critisize other bloggers and engineers, but there was something somewhat lacking in the other posts I found. Not enough explanation was given, and posts were vague on zones, policies and firewall rules.

Other posts were helpful, and led me to the right solution, and Ill mention some as I go along, and try to cover the points that I felt benefitted my solution.

So, lets start with a brief diagram of what I am trying to achieve. Very similar to the diagram shown in this post; however, with this diagram I felt that the arrows were not showing that the GRE over IPSEC tunnel was actually terminating on the SRX’s and the cisco routers played no part in the design.

So, without further ado… lets look at the high level topology I wanted to achieve.

So, there we have it… a simple GRE over IPSEC tunnel between 2 SRX endpoints, with 1 routed layer 3 VLAN and 1 flat Layer 2 circuit running between them. What I needed was a combination of the previous layer 2 circuit example, Chris Jones’s example here; and David Gee’s example here. I needed a 3rd routed mgmt segment, but that could just be simple routing.

Ok, so why do I need all this? Well, I have 3 requirements to satisfy.

  1. I need a flat shared Layer2 segment for HA Keepalives
  2. I need a shared routed segment for a shared VIP, which must be available to other servers. The VIP requirements are Active/Passive.
  3. I need a router OOB management subnet, that is local to each location.

So, having reviewed all the posts, and having done extensive Googling (as one does 🙂 ), I started to build it. But before I go on, Ill say a few words on Junipers own pages on this subject. They make various assumptions, which ultimately make it impossible to achieve the solution with the devices I am using.

  1. IDP licenses – These cost money, they are a rip off, and giving 1 single penny to Juniper, after spending years dealing with their bug filled code, just isnt going to ever happen.
  2. They asume that you are connecting multiple sites to a headend router in a large multipoint environment, using expensive high end SRX models. Nothing wrong with this, but just not suitable for my own needs.
  3. Flow and Packet based routing instances – this is not required, as shown by the previous posts, and adds unrequired complexity…as if its not complex enough.. 🙂

So onward to the first of the configuration stanzas….first we will start with the Internet facing VPN termination interface. Note here that Ive used a physical unpatched interface, defined as a loopback, so it is always up. What also should be pointed out is that this is not my ‘Internet’ interface, its a loopback. My ‘Internet’ interface just happens to be a VDSL PIM running PPP and PPPOE.

set interfaces fe-0/0/2 description "VPN Terinating interface"
set interfaces fe-0/0/2 fastether-options loopback
set interfaces fe-0/0/2 unit 0 family inet filter input re-protect
set interfaces fe-0/0/2 unit 0 family inet address 100.100.100.100/32

Notice that I have applied a filter to this interface, perhaps not required as such, but no harm is done in applying it.

The other end, the NFX end, is terminating the VPN on their ‘Internet’ facing interface so here is the first difference in setup. I would like to omit a lot of the NFX configurations so unless shown, the reader can assume that both ends are identical. (note that this is not stated in ANY of the other blog posts I read, and the closest to showing both ends was the post by David Gee. I still dont know why in his post he shows that he is participating in a single OSPF area with his upstream SRX100’s, but its not required, and should be only seen as a way to propogate the external VPN terminating subnets.)

The next step, once the public IP’s and interfaces are known, is to set up the IPSEC and IKE portions of the configuration. This should allow the IPSEC tunnel to come up, through which we can start to add the next layers.

The ‘st0.0‘ Interface (I used /30’s where I could)

set interfaces st0 unit 0 family inet address 10.1.0.2/30

And we cant forget about having a loopback interface. We will use this later for BGP and LDP.

The Looback Interface

set interfaces lo0 unit 0 family inet filter input re-protect
set interfaces lo0 unit 0 family inet address 10.1.0.10/32 primary
set interfaces lo0 unit 0 family inet address 127.0.0.1/32
set interfaces lo0 unit 0 family mpls

The IPSEC Configuration

set security ipsec vpn-monitor-options interval 10
set security ipsec vpn-monitor-options threshold 10
set security ipsec policy ipsec-policy-cfgr perfect-forward-secrecy keys group1
set security ipsec policy ipsec-policy-cfgr proposal-set standard
set security ipsec vpn ipsec-vpn-cfgr bind-interface st0.0
set security ipsec vpn ipsec-vpn-cfgr vpn-monitor optimized
set security ipsec vpn ipsec-vpn-cfgr ike gateway ike-gate-cfgr
set security ipsec vpn ipsec-vpn-cfgr ike ipsec-policy ipsec-policy-cfgr
set security ipsec vpn ipsec-vpn-cfgr establish-tunnels immediately

The IKE Configuration.

set security ike policy ike-policy-cfgr mode aggressive
set security ike policy ike-policy-cfgr proposal-set standard
set security ike policy ike-policy-cfgr pre-shared-key ascii-text "$9$12345/qwerty"
set security ike gateway ike-gate-cfgr ike-policy ike-policy-cfgr
set security ike gateway ike-gate-cfgr address 50.50.50.50
set security ike gateway ike-gate-cfgr dead-peer-detection optimized
set security ike gateway ike-gate-cfgr dead-peer-detection interval 10
set security ike gateway ike-gate-cfgr dead-peer-detection threshold 5
set security ike gateway ike-gate-cfgr external-interface fe-0/0/2.0
set security ike gateway ike-gate-cfgr version v2-only

Testing the IPSEC tunnel is up required some adjustments to my re-protect loopback filter to allow the IPSEC traffic. I was also running a dynamic VPN on the SRX and didnt want to conflict with that, but as it turns out, both together, even on the same interface, work perfectly together. Below we can see this in reality.

IPSEC

andy@srx210> show security ipsec security-associations
Total active tunnels: 2
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<268173314 ESP:des/ md5 2ce17b7b 3546/ 500000 - root 60528 25.25.25.25 >268173314 ESP:des/ md5 1d288501 3546/ 500000 - root 60528 25.25.25.25
<131073 ESP:3des/sha1 d646408d 2902/ unlim U root 500 50.50.50.50 >131073 ESP:3des/sha1 4e463962 2902/ unlim U root 500 50.50.50.50

IKE

andy@srx210> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
6181239 UP 85c9d31e7df0b8ae e06e80937eb086f6 Aggressive 25.25.25.25
6181238 UP 9eb04d3348162cb8 bc6f982e43e34ebf IKEv2 50.50.50.50

Although not relevant, below is my Dynamic VPN configuration, which sits alongside the IPSEC tunnel.

Dynamic VPN for use with Pulse Secure Client

set security ipsec proposal ipsec-prop2 protocol esp
set security ipsec proposal ipsec-prop2 authentication-algorithm hmac-md5-96
set security ipsec proposal ipsec-prop2 encryption-algorithm des-cbc
set security ipsec proposal ipsec-prop2 lifetime-seconds 3600
set security ipsec policy ipsec-policy perfect-forward-secrecy keys group2
set security ipsec policy ipsec-policy proposals ipsec-prop2
set security ipsec vpn dyn-vpn ike gateway dyn-vpn-local-gw
set security ipsec vpn dyn-vpn ike ipsec-policy ipsec-policy
set security ike proposal ike-prop1 authentication-method pre-shared-keys
set security ike proposal ike-prop1 dh-group group2
set security ike proposal ike-prop1 authentication-algorithm md5
set security ike proposal ike-prop1 encryption-algorithm des-cbc
set security ike proposal ike-prop1 lifetime-seconds 86400set security ike policy ike-dyn-vpn-policy mode aggressive
set security ike policy ike-dyn-vpn-policy proposals ike-prop1
set security ike policy ike-dyn-vpn-policy pre-shared-key ascii-text "$9$98765/ytrewq"
set security ike gateway dyn-vpn-local-gw ike-policy ike-dyn-vpn-policy
set security ike gateway dyn-vpn-local-gw dynamic hostname dynvpn
set security ike gateway dyn-vpn-local-gw dynamic connections-limit 10
set security ike gateway dyn-vpn-local-gw dynamic ike-user-type group-ike-id
set security ike gateway dyn-vpn-local-gw external-interface fe-0/0/2.0
set security ike gateway dyn-vpn-local-gw xauth access-profile dyn-vpn-access-profile
set security dynamic-vpn access-profile dyn-vpn-access-profile
set security dynamic-vpn clients all remote-protected-resources 192.168.1.0/24
set security dynamic-vpn clients all remote-exceptions 0.0.0.0/0
set security dynamic-vpn clients all ipsec-vpn dyn-vpn
set security dynamic-vpn clients all user andy

So, with all our IPSEC tunnels established, we can move onto the next bit of the puzzle, which is ensuring that we can build our GRE tunnel through the IPSEC tunnel. (I really dislike the term ‘over IPSEC’. Its not over, its through, there… I said it 🙂 )

The next part requires building up the GRE tunnel ‘through’ the IPSEC tunnel. First, we will configure the GRE interface for this. Again, we reference the ‘st0.0’ interface, and use /30 subnets where we can.

The GRE Interface

set interfaces gr-0/0/0 description "GRE tunnel to NFX250"
set interfaces gr-0/0/0 unit 0 clear-dont-fragment-bit
set interfaces gr-0/0/0 unit 0 tunnel source 10.1.0.2
set interfaces gr-0/0/0 unit 0 tunnel destination 10.1.0.1
set interfaces gr-0/0/0 unit 0 tunnel allow-fragmentation
set interfaces gr-0/0/0 unit 0 family inet mtu 1300
set interfaces gr-0/0/0 unit 0 family inet filter input inet-packet-mode
set interfaces gr-0/0/0 unit 0 family inet address 10.1.0.6/30
set interfaces gr-0/0/0 unit 0 family mpls mtu 1200
set interfaces gr-0/0/0 unit 0 family mpls filter input mpls-packet-mode

Now, there is some things to note here. Firstly, MTU. I dont want to discuss it, if you are attemting to build this, then I expect you to understand MTU values.
Secondly, the source and destination of the tunnel are defined to be the IPSEC endpoints. We also give the tunnel itself a /30 so that it has an inner side.
Lastly, we configure the interface with family MPLS and 2 firewall filters.

The filters are to force traffic to be packet based, and not flow based. These are simple filters, but they caused me a lot of trouble when trying to get LDP established, and this is where I feel ALL the other posts were lacking. Lets take a look at the filter and see how it looks:

The Firewall Filter Section

set firewall family inet filter inet-packet-mode term control-traffic from protocol tcp
set firewall family inet filter inet-packet-mode term control-traffic from port 22
set firewall family inet filter inet-packet-mode term control-traffic from port 80
set firewall family inet filter inet-packet-mode term control-traffic from port 8080
set firewall family inet filter inet-packet-mode term control-traffic from port 646
set firewall family inet filter inet-packet-mode term control-traffic from port 179
set firewall family inet filter inet-packet-mode term control-traffic then accept
set firewall family inet filter inet-packet-mode term packet-mode then packet-mode
set firewall family inet filter inet-packet-mode term packet-mode then accept

So, control traffic…. specifically BGP (179) and LDP (646) will be dropped without this filter.
All other filters Ive seen omit this, yet what happens is that UDP hellos for LDP get through (packet based anyway) but the TCP session gets mangled.
So, we have to allow ALL control traffic through in flow mode. This is critical. Your LDP session will get stuck in an ‘opening’ state without it.
If we look at the Juniper example, this falls into the trap, and I can assure you, after working through this with Juniper PS, its noted. 🙂

The final parts to the required filters are the mpls and l2circuit filters. These are shown below:

set firewall family mpls filter mpls-packet-mode term ALL-TRAFFIC then packet-mode
set firewall family mpls filter mpls-packet-mode term ALL-TRAFFIC then accept
set firewall family ccc filter l2circuit-packet-mode term ALL-TRAFFIC then packet-mode
set firewall family ccc filter l2circuit-packet-mode term ALL-TRAFFIC then accept

So, now we need some routing. Ive picked OSPF, nice and simple, single area (although I am running other areas, they arent required for this example).
With OSPF, the aim to to form an adjancency over the GRE interface and propogate loopback routes for the purposes of LDP. Standard layering of IGP/MPLS type stuff, if you dont know it, then you should read up on it.

OSPF Routing

set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface gr-0/0/0.0
set protocols ospf area 0.0.0.0 interface vlan.25 passive

Thats it really, I propogate the MGMT subnet (vlan.25) into ospf so the devices that will partake in this setup can be managed from both ends.

So, now that we have configured the GRE interface, and the appropriate firewall filters, along with an IGP routing protocol, its time to get some of that fancy MPLS stuff going.
For simplicities sake, Ive used LDP, RSVP would be overkill in this case, even if we used dyanmic tunnels, which we havent so I wont waffle on.

LDP, nice and simple, so here it is:

The LDP and MPLS section

set protocols ldp traceoptions file ldp_shoot
set protocols ldp traceoptions file size 10m
set protocols ldp traceoptions flag all
set protocols ldp transport-address router-id
set protocols ldp interface gr-0/0/0.0
set protocols ldp interface all disable
set protocols ldp interface lo0.0
set protocols ldp session 10.1.0.9 authentication-key "$9$54321/qwerty"
set protocols mpls interface gr-0/0/0.0
set protocols mpls interface lo0.0

Best to leave traceoptions out unless you need to debug, always handy to have it there though.

So, now lets see if we can see what all this looks like put together.

Is OSPF Working?

andy@srx210> show ospf neighbor
Address Interface State ID Pri Dead
10.1.0.5 gr-0/0/0.0 Full 10.1.0.9 128 35

So far, it looks like an adjacency has correctly formed over the GRE interface.

andy@srx210> show route 10.1.0.9 protocol ospf terse

inet.0: 45 destinations, 50 routes (44 active, 1 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 10.1.0.9/32 O 10 1 >gr-0/0/0.0

Great, we are learning the other end’s loopback in OSPF so now lets check and see if LDP is up.

Is LDP Working?

andy@srx210> show ldp neighbor
Address Interface Label space ID Hold time
10.1.0.9 lo0.0 10.1.0.9:0 34
10.1.0.5 gr-0/0/0.0 10.1.0.9:0 11

andy@gateway-lo0> show ldp session
Address State Connection Hold time
10.1.0.9 Operational Open 21

As expected (although see previous notes regarding firewalls, this bit took me a day to get working), LDP is up, and the session is working.
Unlike other bloggers, I did NOT need to use rib groups, statics, or anything else to get this session up. Nor should you have to. If you do, Id like to understand why, so please let me know, im really interested.

Here is some more output.

andy@srx210> show route protocol ldp terse

inet.0: 45 destinations, 50 routes (44 active, 1 holddown, 1 hidden)

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 10.1.0.9/32 L 9 1 >gr-0/0/0.0

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 299888 L 9 1 >gr-0/0/0.0
* 299888(S=0) L 9 1 >gr-0/0/0.0

So, next, but not quite last, we want the l2circuit up for our HA keepalives. For this we need a local interface at each side. My SRX happens to hang off a switch, so I added a cable, and dropped an access port onto the switch from the SRX for the l2circuit access.

The L2Circuit Portion

set interfaces fe-0/0/6 description "Layer2 CCC Shared VAULT VLAN"
set interfaces fe-0/0/6 encapsulation ethernet-ccc
set interfaces fe-0/0/6 unit 0 family ccc filter input l2circuit-packet-mode

Note the use of the l2circuit filter here, packetmode for all traffic on this layer2 circuit.
Now, we can see if the l2circuit has come up.

andy@srx210> show l2circuit connections
Layer-2 Circuit Connections:
...
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 10.1.0.9
Interface Type St Time last up # Up trans
fe-0/0/6.0(vc 1) rmt Up Jun 23 09:48:12 2017 1
Remote PE: 10.1.0.9, Negotiated control-word: Yes (Null)
Incoming label: 299792, Outgoing label: 299808
Negotiated PW status TLV: No
Local interface: fe-0/0/6.0, Status: Up, Encapsulation: ETHERNET

So, all looks good so far. Next Ill discuss the various security zones. I used 4 zones for the entire solution.
1. Internet – connects to the Internet
2. VAULT-VPN – Zone for tunnel termination
3. VAULT-INT – Zone for the VPLS traffic
4. VAULT – Zone for the L2Circuit and MGMT traffic

What I found missing from a log of blogs was any details around zoning. So, lets see what interfaces went where….

Zone Interfaces

set security zones security-zone Internet interfaces fe-0/0/2.0
set security zones security-zone VAULT-VPN host-inbound-traffic system-services all
set security zones security-zone VAULT-VPN host-inbound-traffic protocols all
set security zones security-zone VAULT-VPN interfaces st0.0
set security zones security-zone VAULT-VPN interfaces gr-0/0/0.0
set security zones security-zone VAULT-VPN interfaces lo0.0
set security zones security-zone VAULT-VPN interfaces lt-0/0/0.1
set security zones security-zone VAULT-INT host-inbound-traffic system-services all
set security zones security-zone VAULT-INT host-inbound-traffic protocols all
set security zones security-zone VAULT-INT interfaces fe-0/0/5.0
set security zones security-zone VAULT-INT interfaces lt-0/0/0.0
set security zones security-zone VAULT host-inbound-traffic system-services all
set security zones security-zone VAULT host-inbound-traffic protocols all
set security zones security-zone VAULT interfaces vlan.25
set security zones security-zone VAULT interfaces fe-0/0/6.0

The full zones are not shown, but I added policies that were very open. I advise you to lock these down after you have it all working correctly.

Zone Policies

set security policies from-zone VAULT-VPN to-zone VAULT policy VAULT-VPN-to-VAULT match source-address any
set security policies from-zone VAULT-VPN to-zone VAULT policy VAULT-VPN-to-VAULT match destination-address any
set security policies from-zone VAULT-VPN to-zone VAULT policy VAULT-VPN-to-VAULT match application any
set security policies from-zone VAULT-VPN to-zone VAULT policy VAULT-VPN-to-VAULT then permit

So, what havent we covered so far…. the VPLS sections 🙂

First we need some BGP to carry our VPLS routing info, and of course a nice little routing instance to put our lt-0/0/0.0 interface in. I hope you spotted that interface coming into play within the zones section.

The BGP Section

set protocols bgp group VPLS type internal
set protocols bgp group VPLS traceoptions file bgplog
set protocols bgp group VPLS traceoptions file size 10m
set protocols bgp group VPLS traceoptions flag all
set protocols bgp group VPLS local-address 10.1.0.10
set protocols bgp group VPLS mtu-discovery
set protocols bgp group VPLS family l2vpn signaling
set protocols bgp group VPLS neighbor 10.1.0.9

BGP should come up, dont forget your router ID and ASN, but yu know what youre doing right, so I neednt remind you. After all, you got this far….

The LT Interface

set interfaces lt-0/0/0 unit 0 encapsulation ethernet-vpls
set interfaces lt-0/0/0 unit 0 peer-unit 1
set interfaces lt-0/0/0 unit 1 encapsulation ethernet
set interfaces lt-0/0/0 unit 1 peer-unit 0
set interfaces lt-0/0/0 unit 1 family inet address 10.1.4.3/24 vrrp-group 10 virtual-address 10.1.4.1
set interfaces lt-0/0/0 unit 1 family inet address 10.1.4.3/24 vrrp-group 10 priority 100
set interfaces lt-0/0/0 unit 1 family inet address 10.1.4.3/24 vrrp-group 10 accept-data

Here we need 1 units, these basically form a bridge between each other, and this allows traffic to get into the routing instance.
We also need an interface to carry the VPLS traffic, as we did with the Layer2 Cicruit.

set interfaces fe-0/0/5 encapsulation ethernet-vpls
set interfaces fe-0/0/5 unit 0

Checking BGP

andy@srx210> show bgp summary
Groups: 3 Peers: 4 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 1 1 0 0 0 0
bgp.l2vpn.0 1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.1.0.9 43178 6527 6466 0 2 10:52:14 Establ
VPLS.l2vpn.0: 1/1/1/0
bgp.l2vpn.0: 1/1/1/0

So, we can see that BGP is up, we have a VPLS table, and there is a route in there.

andy@srx210> show route table VPLS.l2vpn.0

VPLS.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.0.9:600:2:1/96
*[BGP/170] 10:53:53, localpref 100, from 10.1.0.9
AS path: I
> via gr-0/0/0.0
10.1.0.10:600:1:1/96
*[L2VPN/170/-101] 2d 00:46:53, metric2 1
Indirect

Nice, we have loopbacks, and RD’s and RT’s. Again, read up if you dont know what Im refering to.

So, thats it. Final checks… is VRRP up?

VRRP Check

andy@srx210> show vrrp
Interface State Group VR state VR Mode Timer Type Address
lt-0/0/0.1 up 10 backup Active D 3.112 lcl 10.1.4.3
vip 10.1.4.1
mas 10.1.4.2

And finally…. do we have MAC’s in the forearding table for the VRRP neighbours?

andy@srx210> show route forwarding-table table VPLS
Routing table: VPLS.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 1453 1
lt-0/0/0.0 user 0 comp 1459 3
lsi.1048834 user 0 comp 1465 2
fe-0/0/5.0 user 0 comp 1459 3
00:00:5e:00:01:0a/48 dynm 0 indr 262142 6
Push 262145 1449 2 gr-0/0/0.0
00:11:32:73:8d:4c/48 dynm 0 indr 262142 6
Push 262145 1449 2 gr-0/0/0.0
00:11:32:73:a7:0e/48 dynm 0 ucst 1469 5 fe-0/0/5.0
2c:21:31:5f:aa:10/48 dynm 0 indr 262142 6
Push 262145 1449 2 gr-0/0/0.0
84:18:88:75:19:80/48 perm 0 ucst 1456 1 lt-0/0/0.0
f0:1c:2d:4d:55:4e/48 dynm 0 ucst 1469 5 fe-0/0/5.0
f0:1c:2d:4d:aa:40/48 dynm 0 ucst 1469 5 fe-0/0/5.0

So, everything is working now, we just have to plug in the end hosts.

bash-4.3# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.1.3.1 0.0.0.0 UG 0 0 0 eth3
10.1.0.12 0.0.0.0 255.255.255.252 U 0 0 0 eth0
10.1.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
10.1.4.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0

bash-4.3# ping 10.1.4.1
PING 10.1.4.1 (10.1.4.1) 56(84) bytes of data.
64 bytes from 10.1.4.1: icmp_seq=1 ttl=64 time=15.4 ms
64 bytes from 10.1.4.1: icmp_seq=2 ttl=64 time=15.4 ms
^C
--- 10.1.4.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 15.445/15.446/15.448/0.124 ms
bash-4.3# ping 10.1.4.2
PING 10.1.4.2 (10.1.4.2) 56(84) bytes of data.
64 bytes from 10.1.4.2: icmp_seq=1 ttl=64 time=15.9 ms
^C
--- 10.1.4.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.941/15.941/15.941/0.000 ms
bash-4.3# ping 10.1.4.3
PING 10.1.4.3 (10.1.4.3) 56(84) bytes of data.
64 bytes from 10.1.4.3: icmp_seq=1 ttl=64 time=0.752 ms
^C
--- 10.1.4.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.752/0.752/0.752/0.000 ms

The host can reach the far end VRRP gateway, and this shows that VPLS is working.

So, thats it for this post, hope you find it helpful, I only wrote it to clear up the points missed by other posts, and to help YOU, the reader 🙂

The final low level diagram is located here:

http://www.scot1and.org/~andy/Vault-Topology.pdf

Thanks

Andy

This entry was posted in BGP, MPLS, OSPF, Routing. Bookmark the permalink.