MX VPN BGP experiment

Kind of a big deal

MX VPN BGP experiment

Hi, guys

Since we are within calmer times you get some time to experiment for future cases.
I possibly have a DC and autoVPN deployment coming up so I decided to finally experiment with the one armed concentrator functionality in MX.  This topic has always fascinated me because I never tried it and had issues wrapping my head around it.

I have my CMNA set of devices I could leverage to setup this topo up together with Cisco ISR and an L3 switch.
I don't have any other MX'es laying around so I'll have to wait to fully test it when I can get my hands on a colleagues' MX to temporarily claim in my "org' 😉

So here is the topology


So basically I have an L3 switch with a few subnets behind it.  That switch announces those subnets via EIGRP to the router above it.  That router then does NAT towards the internet and has a link for the MX.  The MX now runs BGP with the router.  The MX should originate it's VPN routes into BGP and the router redistributes the three subnets from EIGRP into BGP for the MX.

Here is the configuration, dashboard log and routing table of the MX.

What I found was that the log did not specify alot about BGP, only that the session is up.
The MX did receive those routes from the router.

What I did find strange is why the client VPN subnet which is set to participate in the VPN it sure will be distributed among the future spokes through iBGP.
However this route did NOT propagate to eBGP to the router.  Any comment on this?
I had to create a static route on the router for the client VPN subnet towards the MX and then redistribute into EIGRP.

I then tested the client VPN and that worked all dandy.
So the things I'm curious about; is the clientVPN not being announced by design or bug or forgotten feature?
And if I would add another MX to the org with it's own client VPN.  Will it propagate to the hub and then to the router?

Show commands below:

On windows for the client VPN:

C:\Users\xxxxx>tracert -d

Tracing route to over a maximum of 30 hops

1 46 ms 47 ms 61 ms x.x.x.x (public ip hotspot)
2 49 ms 55 ms 63 ms
3 71 ms 63 ms 52 ms
4 89 ms 56 ms 51 ms

Trace complete.

C:\Users\xxxxx>route print
Interface List

IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric 50 51 (pub ip of MX) On-link 36 (client vpn route) 36 (client vpn adapter) On-link 291 On-link 291

Routes on the switch:

SW-HOME#show ip route
Gateway of last resort is to network

D*EX [170/7864320] via, 11:50:52, Vlan103 (default route to RTR)
D [90/1966080] via, 11:50:52, Vlan103 is variably subnetted, 2 subnets, 2 masks
C is directly connected, Vlan100
L is directly connected, Vlan100 is variably subnetted, 2 subnets, 2 masks
C is directly connected, Vlan101
L is directly connected, Vlan101 is variably subnetted, 2 subnets, 2 masks
C is directly connected, Vlan150
L is directly connected, Vlan150 is variably subnetted, 2 subnets, 2 masks
C is directly connected, Vlan200
L is directly connected, Vlan200
D EX [170/7864320] via, 00:31:15, Vlan103 (redistributed client vpn route) is variably subnetted, 3 subnets, 2 masks
C is directly connected, Vlan103 (point to point subnet between SW and RTR)
L is directly connected, Vlan103
D [90/1966080] via, 11:50:52, Vlan103 (route between RTR and MX)

Router show commands:

RTR-GITS#show bgp ipv4 unicast summary
BGP router identifier, local AS number 65516
BGP table version is 4, main routing table version 4
3 network entries using 360 bytes of memory
3 path entries using 156 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 640 total bytes of memory
BGP activity 3/0 prefixes, 3/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 4 65517 105 103 4 0 0 01:29:41 0

RTR-GITS#show bgp ipv4 unicast
BGP table version is 4, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 20 32768 ?
*> 20 32768 ?
*> 20 32768 ?


RTR-GITS#show ip route
Gateway of last resort is to network

S* [1/0] via, GigabitEthernet0/0 (static default route) is variably subnetted, 2 subnets, 2 masks
C is directly connected, GigabitEthernet0/0
L is directly connected, GigabitEthernet0/0
[90/3072] via, 11:54:17, GigabitEthernet0/1 (downstream routes to switch)
[90/3072] via, 11:54:17, GigabitEthernet0/1
[90/3072] via, 11:54:17, GigabitEthernet0/1
[90/3072] via, 11:54:17, GigabitEthernet0/1
S [1/0] via, GigabitEthernet0/1.104 (static route to client VPN subnet because bgp did not receive) is variably subnetted, 4 subnets, 2 masks (point to point subnets)
C is directly connected, GigabitEthernet0/1
L is directly connected, GigabitEthernet0/1
C is directly connected, GigabitEthernet0/1.104
L is directly connected, GigabitEthernet0/1.104

If you've reached the end of this post, you know your stuff! 😉

Kind of a big deal

>So the things I'm curious about; is the clientVPN not being announced by design or bug or forgotten feature?


I would say forgotten feature, and consequently a bug.



Another option you could consider is to apply for a VMX demo licence ("try and buy").  You should be able to get one for at least three months.

You wont even have to run it up.  Just add it as a spoke to your network.

Only AutoVPN routes are announced over the eBGP session. If you don't have any other site to site (AutoVPN) peers nothing will be announced from MX to router. You can still send routes to the MX from the router and they should show up in the routing table.

Kind of a big deal

Update :  if you enable another branch office to announce it's client VPN subnet it does get over to BGP.
I managed to score a temporary appliance at my work that still has to be configured for a client 🙂


So this is definitely not the correct behavior.  I will raise a case for this.

Next test would be: if you make a non-meraki VPN do the BGP routes count or do you manually have to add a "local network" on your hub.

To explain further: DC subnets will they automatically be available in policy based VPN peers or not?  And if not, will they conflict or take precedence over BGP learned subnets.

Kind of a big deal

Another update:


You cannot have the same subnet behind a NAT mode MX and another MX.  The dashboard won't let you configure it.
The documentation clearly states so.


You can however have a overlapping subnet with a different size subnetmask but Meraki will give you a warning that states the most specific match will be used.  Once again, makes sense.

But I've tested that you CAN advertise the exact same subnet via BGP into the AutoVPN network and it will actually get installed into the routing table.  However it normally won't be used because of the routing precedence rules.



Kind of a big deal

Yet another update:

The duplicate route coming from eBGP apparently breaks your iBGP between Hub and spokes after a while.  Probably a another bug.
Removing the duplicate route again made the peering come back up after a few minutes.

Building a reputation

As check , BGP or OSPF can only be used when deployment in VPN-CON mode
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.