Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- About Richard_Velox
Richard_Velox
Conversationalist
Member since Jun 11, 2020
03-26-2021
Community Record
4
Posts
1
Kudos
0
Solutions
03-10-2021
07:44 AM
As a followup to 32 bit network prefix via DHCP? it seems that there are two networking stacks running on Meraki routers; One that can correctly use the information provided from DHCP and communicate with hosts on the Internet and one that checks for connectivity back to Meraki Cloud that sends ARP requests out the WAN interface for the host it's trying to communicate with. This is unusual as devices normally exhibit one of these behaviors and are classified respectively as works with 32-bit prefixes and doesn't work. Which leads me to believe that Meraki routers use at least two networking stacks. Network traffic looks normal for long enough to think the device might even be working: 15:37:30.816279 2c:3f:0b:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 346: (tos 0x0, ttl 250, id 39387, offset 0, flags [none], proto UDP (17), length 332) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 2c:3f:0b:xx:xx:xx, length 304, xid 0x13423f53, Flags [none] (0x0000) Client-Ethernet-Address 2c:3f:0b:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 2c:3f:0b:xx:xx:xx Hostname Option 12, length 25: "ft-gw-aylmer-2c3f0bxxxxxx" Vendor-Class Option 60, length 6: "MERAKI" Vendor-Option Option 43, length 3: 1.0.255 Parameter-Request Option 55, length 7: Subnet-Mask, Domain-Name, Default-Gateway, BR Hostname, Domain-Name-Server, MTU 15:37:30.837378 44:d9:e7:xx:xx:xx > 2c:3f:0b:xx:xx:xx, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 100.64.18.254.67 > 192.0.2.44.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x13423f53, Flags [none] (0x0000) Your-IP 192.0.2.44 Client-Ethernet-Address 2c:3f:0b:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 100.64.18.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.255 Default-Gateway Option 3, length 4: 100.64.18.254 Domain-Name-Server Option 6, length 8: 100.127.255.249,100.127.255.248 15:37:30.837771 2c:3f:0b:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 356: (tos 0x0, ttl 250, id 48399, offset 0, flags [none], proto UDP (17), length 342) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 2c:3f:0b:xx:xx:xx, length 314, xid 0x13423f53, Flags [none] (0x0000) Client-Ethernet-Address 2c:3f:0b:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Server-ID Option 54, length 4: 100.64.18.254 Requested-IP Option 50, length 4: 192.0.2.44 Client-ID Option 61, length 7: ether 2c:3f:0b:xx:xx:xx Hostname Option 12, length 25: "ft-gw-aylmer-2c3f0bxxxxxx" Vendor-Class Option 60, length 6: "MERAKI" Vendor-Option Option 43, length 3: 1.0.255 Parameter-Request Option 55, length 7: Subnet-Mask, Domain-Name, Default-Gateway, BR Hostname, Domain-Name-Server, MTU 15:37:30.892254 44:d9:e7:xx:xx:xx > 2c:3f:0b:xx:xx:xx, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 100.64.18.254.67 > 192.0.2.44.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x13423f53, Flags [none] (0x0000) Your-IP 192.0.2.44 Client-Ethernet-Address 2c:3f:0b:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 100.64.18.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.255 Default-Gateway Option 3, length 4: 100.64.18.254 Domain-Name-Server Option 6, length 8: 100.127.255.249,100.127.255.248 15:37:31.207067 2c:3f:0b:xx:xx:xx > 44:d9:e7:xx:xx:xx, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 200, id 812, offset 0, flags [none], proto ICMP (1), length 84) 192.0.2.44 > 8.8.8.8: ICMP echo request, id 42246, seq 812, length 64 15:37:31.225343 2c:3f:0b:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.0.2.44 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0, length 46 15:37:31.232138 44:d9:e7:xx:xx:xx > 2c:3f:0b:xx:xx:xx, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84) 8.8.8.8 > 192.0.2.44: ICMP echo reply, id 42246, seq 812, length 64 Until this ARP request you might think the router was working normally. 15:37:32.269932 2c:3f:0b:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 143.204.0.73 tell 192.0.2.44, length 46 And communication through the other stack keeps on working. pastebin for more tcpdump output At any rate it's enough for the router to mark the connection as inactive.
... View more
06-12-2020
07:25 AM
1 Kudo
@Nash ARIN is, however seeing as we already have IPv4 & IPv6 netblocks from them I don't expect that request to be well received although we could always try. We fairly recently graduated from using our provider's addresses to using our own, thanks in part to the addresses recovered by ARIN from fraudulent allocations. That address space works well except for the odd client who's expecting to have a publicly routeable address. Do you mean a VPN in to access their private address? We don't have remote VPN access into our network for clients. Outbound VPNs should work without issue and I've seen an established session on two. Inbound VPNs to servers behind NAT are a different story depending on the client; iPhone, Android and others work without issue however Windows needs a registry key set to allow connections to a server that's behind NAT(https://support.microsoft.com/en-us/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t-device-in-windows) I guess that's just another GPO setting for AD. @PhilipDAth We haven't really considered PPPoE mostly because I thought of it being something that would be setup centrally and less amenable to failover in case of a loss of connectivity to the central site; considerations for MTU overhead and the failures associated with firewalls indiscriminately blocking ICMP and disrupting PMTU discovery included. Having different VLANs for DHCP and PPPoE with different MTUs would help. The settings on the radio would need to be statically set. I don't know how well client implementations would handle interface MTUs > 1500 to offset the associated overhead. Redistributing routes into OSPF was less clear though I have to admit I didn't test the setup. Our customers are either behind NAT or have a routeable public IP. This is a legacy of the circumstances of our development. We began using our provider's IPs with all but a few customers behind NAT and even then we were reluctant to assign customers more that one IP and having to change all of our customers public IPs when we needed more addresses due to the policy of our provider to only assign a single prefix wasn't particularly encouraging. Having to bridge our upstream connection through our routers to customers wasn't particularly appealing for a number of reasons; partly due to limitations with their offloading capabilities and layer 2 security. With a router on each tower consuming ~84 addresses for network, router, and broadcast as well as being inflexible in regards to prefix allocation; customers aren't necessarily prepared to deal with having their static IP reassigned. The 32-bit prefix solution looked preferable.
... View more
06-11-2020
02:23 PM
We're a small WISP that's been allocated a small sliver of IPv4 addresses and we're a little stingy about needlessly allocating them; Also the scheme is incredibly flexible. Most vendor's routers work with this allocation scheme like Sonicwall, Unifi, Cisco-Linksys, AirCube, some Edgerouter, Watchguard, some? Asus, Fortigate) and others need 1:1 NAT like PFSENSE, Meraki, Luxul. Routing between towers is accomplished using OSPF. An event triggered script can add the route or it can be added to the configuration. Gateways have IPs in the 100.64.0.0/10 range.
... View more
06-11-2020
01:47 PM
Has Meraki been able to support this configuration in their gateway devices? We have several customers who we've taken to setting up as 1:1 NAT from a private address to their public address as their Meraki routers were unable to correctly route traffic through the gateway provided.
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 2490 |
