OSPF advertises entire route table?

Solved
Aaron_Wilson
A model citizen

OSPF advertises entire route table?

Did a quick test of taking one of my DC hubs and configuring OSPF on the inside interface (dual arm NAT) to the core DC router (Meraki is only for non-mpls remote sites).

 

Ithought the DC MX would only advertise the routes learned from spoke sites terminating to that MX, but instead it advertised *all* routes including that of other hubs. This probably wouldn't have been an issue, except it learned some static zero routes we have defined in the DC MXs (to force all Meraki traffic into core DC for egress).

 

I think it is working as designed, but certainly not what I wanted.

 

Instead of making the Meraki part of area 0, I will need to create a separate area then filter the routes learned from the Meraki for redistribution?

1 Accepted Solution
jdsilva
Kind of a big deal

I never thought this far into this since I haven't had to use it, but based on the description I guess it does make sense. The docs say AutoVPN learned routes, and having an all Hub deployment (full mesh) is a viable config so those routes would have to be advertised. 

 

Given this, I agree that I would create an area just for the MX and do whatever route filtering was required at the ABR back into area 0. 

 

Since the MX can't learn route over OSPF you could even make it a totally stubby area so you don't send the MX LSAs it's not going to use anyway. 

View solution in original post

6 Replies 6
jdsilva
Kind of a big deal

I never thought this far into this since I haven't had to use it, but based on the description I guess it does make sense. The docs say AutoVPN learned routes, and having an all Hub deployment (full mesh) is a viable config so those routes would have to be advertised. 

 

Given this, I agree that I would create an area just for the MX and do whatever route filtering was required at the ABR back into area 0. 

 

Since the MX can't learn route over OSPF you could even make it a totally stubby area so you don't send the MX LSAs it's not going to use anyway. 

Aaron_Wilson
A model citizen

Ok, thx for the reply and confirmation.
PhilipDAth
Kind of a big deal
Kind of a big deal

The OSPF support is - limited.

 

Go for the BGP option.  Much more comprehensive.  It is also 2-way rather than 1-way with the OSPF support.

https://documentation.meraki.com/MX/Networks_and_Routing/BGP 

Aaron_Wilson
A model citizen

Can't do BGP with dual arm mode.
PhilipDAth
Kind of a big deal
Kind of a big deal

You can't do eBGP.  You can do iBGP.  I have not personally tried this myself.

https://documentation.meraki.com/MX/Networks_and_Routing/BGP#NAT_Mode 

 

 

NAT Mode

  • iBGP establishes relationships over autovpn and will establish and exchange routes between:
    • A BGP peer acting as a One-Armed Concentrator in the DC and-
    • A NAT mode MX.
  • eBGP peer relationships are not available for MXs operating as NAT mode VPN concentrators and are only supported on One-Armed Concentrators.
CN
Meraki Alumni (Retired)
Meraki Alumni (Retired)

Crossposting from another thread

 

Meraki Support can disable hubs from sharing routes with each other. If you call (during a change window) and open a case with Meraki Support they can disable this on the backend. This will prevent hubs from sharing routes with each other. This will prevent the local subnets that are defined at one hub from being shared with the other hubs. 

 

For testing purposes, I would recommend getting this enabled on a test organization before implementing it in production. The "No Hub to Hub" can be applied to specific Hubs (if new hubs are added you'll need to have it disabled again) but it is recommended that it be disabled globally in the organization (new hubs will automatically have it turned off). 

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