One of My MX HUB is not sending syslogs via its WAN (private) interface

Zinkt
Conversationalist

One of My MX HUB is not sending syslogs via its WAN (private) interface

Hi

I'm new to Cisco Meraki.

I have two HUBs and two spokes using S2S VPN in my same organization name as below.

HUB:A - Spoke:BranchA (Site-A)

- using passthrough mode (HUB:A)

- direct P2P connect with router (via Meraki WAN1 :IP 192.168.10.1/30)

- using routed mode (Spoke:A)

- advertising 192.168.0.0/16 in vpn setting as local network

 

 

HUB:B - Spoke:BranchB (Site-B)

- using passthrough mode (HUB:B)

- direct P2P connect with router (via Meraki WAN1 :IP 192.168.100.1/30)

- using routed mode (Spoke:B)

- advertising only its upstream network (192.168.100.0/30) in vpn setting as local network

Our syslog server IP is 192.168.200.254 located at Site-C.

HUB:A is sending logs well to syslog server via its WAN IP: 192.168.10.1 , but HUB:B is not sending logs to syslog server via its WAN IP: 192.168.100.1.

I found it's sending logs to syslogs sever via Meraki dashboard IP: 6.xxx.xxx.xxx. and all the syslog traffic of HUB:B is going to HUB:A which is adverstising 192.168.0.0/16 network.

please help and let me know if my info is not complete.

Note:

- Site-A, Site-B and Site-C are connected via MPLS.

- IP are example.

- Sorry for my draft diagram

Draft-Meraki-Drawing1.jpg

13 Replies 13
alemabrahao
Kind of a big deal
Kind of a big deal

Have you tried to preform a packet capture?

 

Have  you tried to  perform a trace route from site B to syllog server?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Zinkt
Conversationalist

Hi @alemabrahao 

Thank your for your reply.

When I perform packet captures via Internet interface, no traffic found to syslog server.

But with S2S vpn interface, traffic found to syslog server and SrcIP is 6.xxx.xxx.xxx.

Traceroute to syslog server from SiteB hub is working well via 192.168.100.2(RT).

alemabrahao
Kind of a big deal
Kind of a big deal

I think that some think can be overleping o your configuration, the configuration looks a little strange.   Is it possible show is lan connection and wan connection in your topology?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

This information is not enough to understand your topology.

 

alemabrahao_0-1666890685199.png

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Zinkt
Conversationalist

SiteA LAN Network is 192.168.0.0/24.

SiteC netwok is Data center 192.168.0.0/16.

If SiteA hub  advertise only 192.168.0.0/24, SiteB MX can send syslog to syslog server well via its WAN interface SiteB to SiteA to SiteC MPLS( not via hub to hub peer auto vpn)

But i think I better to advertise 192.168.0.0/16 on SiteA hub.

alemabrahao
Kind of a big deal
Kind of a big deal

Yes, your configuration is wrong, 192.168.0.0/16 overlaps 192.168.0.0/24.

 

Route Priority

Each type of route configured on the MX has a specific priority in comparison with other types of routes. The priority is as follows:

  1. Directly Connected
  2. Client VPN
  3. Static Routes
  4. AutoVPN Routes
  5. Non-Meraki VPN Peers
  6. BGP learned Routes
  7. NAT*

NOTE: For BGP route selection please refer to: https://documentation.meraki.com/MX/Networks_and_Routing/BGP

*If no routes are defined, then the traffic is NATed and sent out an active Internet interface. This only occurs while the MX is configured in Routed mode.

 

When routing decisions are made, traffic destined for an address for which multiple routes exist will be routed in the order of priority above. For example, if a route for 10.0.0.0/8 is defined as both a static route and as an AutoVPN route, traffic destined for that subnet is routed using the static route, as static routes take precedence over AutoVPN routes.

Note that Non-Meraki VPN routes are considered "always active" and will not automatically fail over when the peer connection is down. For instance, a Non-Meraki VPN peer route for 0.0.0.0/0 will always take priority over the NAT default route, regardless of the Non-Meraki VPN tunnel connection state.

Overlapping Routes

Route priority dictates how traffic is routed when multiple routes exist to the same subnet. However, overlapping routes that are not identical are also present in many deployments. In this case, the most specific route will be used.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Zinkt
Conversationalist

Thank you for your info @alemabrahao 

Sorry for my diagram to make you confused. Will upload revised one.

RT are WAN routers that connect to each sites via MPLS.

RT to Office icon is just internal network.

 

Regarding routing,if I advertise only 192.168.0.0/24, BranchA site will not be able to reach to Site C w/o default route.

alemabrahao
Kind of a big deal
Kind of a big deal

No problem but I need to tell you the truth, I think you need to review your network design, probably It's just a route issue, so review your route on the routers and try not to overlap the subnets, to make your troubleshooting easier.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Zinkt
Conversationalist

Thank you.

SiteA-BranchA topology is same as this one.

Anyway, will chk routing again.

Thanks @alemabrahao 

Screen Shot 2016-09-15 at 5.29.46 PM.png

alemabrahao
Kind of a big deal
Kind of a big deal

Here we go:

 

alemabrahao_1-1666894367671.png

 

 

I understand that for  IP  192.168.100.1  to reach IP 192.168.200.254 first It will go to Route A, then Router B sends it to Router C and finally Router C sends it to Server.

 

Have you checked routes on all routers?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Zinkt
Conversationalist

Hi @alemabrahao 

 

this is new topology (only Site:A and Site:B)

Site:A Meraki HUB is sending logs to Syslogs server via 192.168.1.1.

Site:B Meraki HUB is not sending logs to syslogs server via 192.168.100.1.

 

Possible Cause

Site:A Meraki HUB is advertising Site:A local work 192.168.0.0/16.

Site:B Meraki HUB is going traffic via Site:A Meraki HUB (Hub to Hub, not via MPLS)

Site:B Meraki HUB traffic logs sending to syslog server with Site:A MerakiHUB source IP.

 

Temporary Solution

After Site:A Meraki Hub advertise only 192.168.0.0/24 (exclude 10.15.200.0/24 network), Site:B Meraki HUB can send logs to syslog server.

But Site:A Meraki Hub need to advertise all 192.168.0.0/16 network for its branch office.

MX-Syslog-issue.jpg

alemabrahao
Kind of a big deal
Kind of a big deal

Much clearer, as I suspect the 192.168.0.0/16 network is overlapping the Syslog network, the MX will use SD-WAN to communicate with Syslog instead of the WAN interface.
I can think of a possible solution (but honestly I don't know if it will work):

Ask support to enable Site-to-site VPN Translation on Site A's Network.

 

https://documentation.meraki.com/MX/Site-to-site_VPN/Using_Site-to-site_VPN_Translation

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Zinkt
Conversationalist

Thanks alot for your time and suggestions.

I will study vpn translation.

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