MX VPN BGP experiment

GIdenJoe
Kind of a big deal
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

Home-test-bgp.png

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.
Home-test-bgp-meraki.png

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

Trace complete.

C:\Users\xxxxx>route print
===========================================================================
Interface List
127...........................Thuis
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.20.10.1 172.20.10.2 50
xxx.xxx.xx.xx 255.255.255.255 172.20.10.1 172.20.10.2 51 (pub ip of MX)
192.168.0.0 255.255.0.0 On-link 192.168.254.50 36 (client vpn route)
192.168.254.0 255.255.255.0 192.0.2.1 192.168.254.50 36 (client vpn adapter)
192.168.254.50 255.255.255.255 On-link 192.168.254.50 291
192.168.255.255 255.255.255.255 On-link 192.168.254.50 291

Routes on the switch:

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

Network Next Hop Metric LocPrf Weight Path
*> 192.168.100.0 192.168.255.2 20 32768 ?
*> 192.168.101.0 192.168.255.2 20 32768 ?
*> 192.168.150.0 192.168.255.2 20 32768 ?

 

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! 😉

6 REPLIES 6
PhilipDAth
Kind of a big deal
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.

GIdenJoe
Kind of a big deal
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 🙂

GIdenJoe_0-1586187767992.png


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.

GIdenJoe
Kind of a big deal
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.

GIdenJoe_0-1586287287073.png

 

GIdenJoe
Kind of a big deal
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.

SopheakMang
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.
Labels