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 192.168.100.10
Tracing route to 192.168.100.10 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 192.168.255.5 3 71 ms 63 ms 52 ms 192.168.255.2 4 89 ms 56 ms 51 ms 192.168.100.10
C:\Users\xxxxx>route print =========================================================================== Interface List 127...........................Thuis ===========================================================================
SW-HOME#show ip route Gateway of last resort is 192.168.255.1 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/7864320] via 192.168.255.1, 11:50:52, Vlan103 (default route to RTR) D 192.168.0.0/24 [90/1966080] via 192.168.255.1, 11:50:52, Vlan103 192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.100.0/24 is directly connected, Vlan100 L 192.168.100.1/32 is directly connected, Vlan100 192.168.101.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.101.0/24 is directly connected, Vlan101 L 192.168.101.1/32 is directly connected, Vlan101 192.168.150.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.150.0/24 is directly connected, Vlan150 L 192.168.150.1/32 is directly connected, Vlan150 192.168.200.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.200.0/24 is directly connected, Vlan200 L 192.168.200.1/32 is directly connected, Vlan200 D EX 192.168.254.0/24 [170/7864320] via 192.168.255.1, 00:31:15, Vlan103 (redistributed client vpn route) 192.168.255.0/24 is variably subnetted, 3 subnets, 2 masks C 192.168.255.0/30 is directly connected, Vlan103 (point to point subnet between SW and RTR) L 192.168.255.2/32 is directly connected, Vlan103 D 192.168.255.4/30 [90/1966080] via 192.168.255.1, 11:50:52, Vlan103 (route between RTR and MX)
Router show commands:
RTR-GITS#show bgp ipv4 unicast summary BGP router identifier 192.168.255.5, 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 192.168.255.6 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 192.168.255.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete
RTR-GITS#show ip route Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.0.1, GigabitEthernet0/0 (static default route) 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.0.0/24 is directly connected, GigabitEthernet0/0 L 192.168.0.2/32 is directly connected, GigabitEthernet0/0 D 192.168.100.0/24 [90/3072] via 192.168.255.2, 11:54:17, GigabitEthernet0/1 (downstream routes to switch) D 192.168.101.0/24 [90/3072] via 192.168.255.2, 11:54:17, GigabitEthernet0/1 D 192.168.150.0/24 [90/3072] via 192.168.255.2, 11:54:17, GigabitEthernet0/1 D 192.168.200.0/24 [90/3072] via 192.168.255.2, 11:54:17, GigabitEthernet0/1 S 192.168.254.0/24 [1/0] via 192.168.255.6, GigabitEthernet0/1.104 (static route to client VPN subnet because bgp did not receive) 192.168.255.0/24 is variably subnetted, 4 subnets, 2 masks (point to point subnets) C 192.168.255.0/30 is directly connected, GigabitEthernet0/1 L 192.168.255.1/32 is directly connected, GigabitEthernet0/1 C 192.168.255.4/30 is directly connected, GigabitEthernet0/1.104 L 192.168.255.5/32 is directly connected, GigabitEthernet0/1.104
If you've reached the end of this post, you know your stuff! 😉
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.
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.
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.
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.