EIGRP downstream devices need to also adverise same subnets?

[jmaxwellUSAF]

Hello.

The DMVPN router already advertises all necessary downstream subnets via EIGRP. This router will be peered with downstream routers. 

QUESTION:

1. Do the downstream routers also need to advertise all connected subnets

(#network 172.16.1.0, #network172.16.2.0)

or can they simply run EIGRP 1 on the peer-connected interface with no configured

#network

statements, and that's it?

Thank you.

[Peter Paluch]

Hello again : )

I am not sure if the term

downstream router

refers to a DMVPN hub or a DMVPN spoke, or to another router that is not a part of the DMVPN infrastructure (doesn't have a multipoint GRE tunnel). Can you clarify?

Aside from this, though, EIGRP for IPv4 cannot be enabled on an interface without a

network

command. It is exactly the

network

command that specifies which interfaces should EIGRP run on - and whose attached networks it needs to advertise.

Maybe the answer - in a little indirect way - comes in explaining what the

network

command really does in EIGRP: It, first and foremost, specifies a range of IP addresses. Yup, a range - or an interval - of IPs. All interfaces whose own IP addresses fall into the ranges carved out by the

network

commands will be enabled in EIGRP, which means that EIGRP will send and receive EIGRP messages over those interfaces (allowing adjacencies to come up), and will advertise the true networks and netmasks of those interfaces. An interface whose own IP does not fall into any of the ranges carved out by

network

commands is completely ignored by EIGRP - it does not advertise its attached network, and it does not communicate over it. This is why it is possible to add all existing and future interfaces using the

network 0.0.0.0 255.255.255.255

command, or why the

network 192.168.1.1 0.0.0.0

command perfectly applies to the interface configured with

ip address 192.168.1.1 255.255.255.0

command. A little mind twister here - but perhaps it helps!

Please feel welcome to ask further!

Best regards,
Peter

[jmaxwellUSAF]

Peter, thank you for your inspired reply.

To clarify-- the DMVPN spoke is already advertising all the (downstream) branch subnets to the hub. Now I want to ensure this spoke device will successfully communicate with all subnets in the branch. For this success I intend to configure all branch routers to run EIGRP. 

So then, in this situation what networks should these branch routers advertise? Can I simply advertise the network on the directly connected interface, or must I advertise more networks than this?

[Peter Paluch]

Hello,

Thank you.

So let me restate: We are talking about a single branch, and that single branch has multiple routers there - at least one of them being the DMVPN spoke router at the edge of the branch, and other routers being purely internal inside the branch. Is this correct?

Further on, you wrote: "the DMVPN spoke is already advertising all the (downstream) branch subnets to the hub". But this means that the spoke router already knows about all the downstream subnets. How does it know about them? Through EIGRP, or through static configuration, or is it perhaps advertising a summarized network to the hub...?

Pardon me for not coming back with a clear answer still - I am trying to understand your setup first. Some information to me feels a little contradicting but that is most likely because I don't fully understand yet.

Best regards,
Peter

[jmaxwellUSAF]

"We are talking about a single branch, and that single branch has multiple routers there - at least one of them being the DMVPN spoke router at the edge of the branch, and other routers being purely internal inside the branch. Is this correct?"-- CORRECT.

""the DMVPN spoke is already advertising all the (downstream) branch subnets to the hub". But this means that the spoke router already knows about all the downstream subnets. How does it know about them?" Honestly, the DMVPN router is not yet installed. (I try to keep details simple on these posts.) My strategy is to advertise all spoke branch subnets with a static config listing these networks. Is that not correct? What is the best way to configure this EIGRP architecture?

[Peter Paluch]

Hello,

Ah, I see.

Static configuration would defeat the purpose of the dynamic routing protocol. If a branch has multiple routers, and especially if they are redundantly connected (so if one link or one router fails, there is still an alternate path), dynamic routing is the way to go.

Take it in the easiest way possible. If you had just that single branch network, and even no DMVPN connectivity, just those multiple routers, you would probably know how to start EIGRP on them so that everyone on that branch can talk to everyone else. Essentially, each router would have a

network

command for its own directly connected networks - certainly for those that

A) connect to neighboring routers (so that you can establish adjacencies with other routers and exchange routes with them)

B) connect to networks with end hosts (so that you can advertise the networks where the clients and servers are)

Would this make sense?

Adding DMVPN to the whole mix is easy - in fact, you just ignore that the Tunnel interface on the spoke router is something special, and include it among the

network

commands in the EIGRP configuration. This way, the DMVPN and the branch networks "merge".

No static routing.

Does this seem like a workable scenario?

Best regards,
Peter

[jmaxwellUSAF]

Thanks for your reply.

So then, my strategy is to insert below config on DMVPN, which includes all the downstream branch's networks...

(obfuscated)

DMVPNrouter# Router eigrp 4
No auto-summary
Network 10.33.0.0 0.0.255.255
Network 172.16.41.0 0.0.0.255
Network 172.16.42.0 0.0.0.255
Network 192.168.43.0 0.0.0.255
Network 192.168.55.0 0.0.0.255
Network 192.168.173.0 0.0.0.255
Network 192.168.186.0 0.0.0.255 

this is tunnel 2!!

---

And then on each isolated branch router, within EIGRP 4, to only advertise the directly connected network of that interface.

Does that sound sound?

[Peter Paluch]

Hello,

> Does that sound sound?

Actually, no. That's wrong. Even the spoke router should only contain

network

commands for its own directly connected network, not for networks attached to other routers. The phrase "its (router's) own directly connected networks" is the key mantra here. In IGPs including EIGRP, you never, ever, refer to remote networks with your own network

statements - only to those that are directly connected to you. A

network

command that refers to a network that is not directly connected is ignored.

You probably assume that if a router learns about a network from a neighbor using EIGRP, then in order to advertise it further to its own neighbors, it must have that network listed among its

network

commands. But this is a wrong assumption. If a router learns about a network from a neighbor, it advertises it to other neighbors automatically without needing to call out that network in the local configuration - that is a fundamental principle of all IGPs including EIGRP.

So whichever router it is, the DMVPN spoke router or the internal router, your

network

commands on every single router will include only those networks that are directly attached to it, none other.

Does this seem to start making sense?

Best regards,
Peter

[jmaxwellUSAF]

OK that makes sense. 

Is it correct that the

default gateway

for the ISOLATED branch routers should be the branch ISP www gateway router?

The

default gateway

for the DMVPN router-- should it be the private IP address of the DMVPN upstream device, or the branch ISP www gateway router?

[Peter Paluch]

Hello,

Regarding the default routing, the hub should send a default route to the DMVPN spoke through EIGRP, and the spoke router will pass it on further to its own neighbors on the branch. Again, no static configuration of default routes on the branch - the default route should come from the hub through EIGRP. The default route will be propagated just as any other route and EIGRP will make sure that the next hops are properly set.

A little side note: DMVPN as a solution has few evolutionary steps (versions or generations), called phases. What is commonly deployed is Phase 3 these days. With Phase 3, the hub should send only the default route to the spokes, not even the list of networks on individual branches. The specific routes from branches are discovered in an on-demand fashion through NHRP, not through a routing protocol anymore. This is the preferred configuration because it keeps the routing tables on spokes and branch routers small and populated only with those networks from other branches that have been spoken to.

Whether you run Phase 3 - you need to check the Tunnel interface configuration on the hub router. If it contains the

ip nhrp redirect

command, you are using Phase 3. If the command is not on the hub's Tunnel interface, you are running Phase 2 that works a little differently.

The reason I'm asking is that with Phase 3, it is relatively easy to send a default route from the hub to the spokes by summarizing every EIGRP network on the hub's Tunnel interface into a default route (however, some additional configuration is necessary so that this configuration does not override the true default route on the hub router itself).

Best regards,
Peter

[jmaxwellUSAF]

Thank you for your lengthy reply. We had some issues with implementing phase 3, so we are only using phase 2, which is fine because this is a relatively small enterprise-- about 15 branches. 

I do not want branch www traffic entering the DMVPN. Should the branch routers have the ISP as the

default gateway,

and only access the DMVPN for the EIGRP advertised routes? How should I engineer this intent? 

[Peter Paluch]

Hello,

First of all, a router does not have a

default gateway

A router has a default route, and the default route's next hop must point to an immediately adjacent neighbor, not to a far-away router. Hence, the branch routers cannot use the ISP as the next hop for their default route because they are not directly connected to it. That is why I said - leave the default route and its next hop determination (which is unique for every router in the topology) to EIGRP.

However, what you request here - directing WWW traffic directly to the internet instead of DMVPN - cannot be satisfactorily solved by simple routing because you want to perform path selection not only by the destination IP address, but also by the L4 destination port (80 and 443).

For this, you will need to apply Policy Based Routing (PBR) on the spoke router; the PBR will identify all traffic destined to webservers and force the ISP as the next hop, not the Tunnel interface. Other traffic will be routed according to the routing table, not according to the PBR rules.

Do you know the PBR functionality and style of configuration?

Best regards,
Peter

[jmaxwellUSAF]

Wouldn't simply setting the

default route

as the

ISP router

be the needed configuration?

[Peter Paluch · Accepted solution]

Hello,

Let's do an example.

Let's assume that the

ISP router's address is

192.0.2.1/30

and you would go to any router on the branch that is not directly connected to the ISP router, and configure this:

ip route 0.0.0.0 0.0.0.0 192.0.2.1

But because the branch router where we configured this is not - as we stated in the assumption above - directly connected to the ISP router, it does not have any of its interfaces in the

192.0.2.0/30

network

So the route above is possibly invalid - it points to a next hop that is not directly connected. Unless the branch router somehow has the knowledge on how to reach

192.0.2.0/30

that configured default route is unusable and will not even be placed into the routing table. Do you see or understand it differently?

For the WWW requirement, though, this needs a little more clarification. I suppose your true requirement is this:

- Traffic toward web servers inside your company (as well as any servers within your company, in fact) needs to go through the tunnel
- Traffic toward web servers outside your company needs to go out to the internet directly

In that case, this can be done with the routing alone, provided that the DMVPN hub does not send a complete default route to the spokes, but rather a summary route (or a set of summary routes) that covers the entire intra-company address space. Then, simply because of longest-prefix-match lookups in the routing table, communication toward destinations inside your company would always be matched by the more specific summary networks and go through the DMVPN tunnel, while the rest of the traffic would exit the branch to the internet directly. However, even for this, the branch routers downstream of the spoke router would need to have their default routes pointing hop-by-hop to the spoke router (always toward the adjacent router one step closer to the spoke), and only the spoke would have a default route pointing to the ISP router - because I assume that the spoke is directly connected to it.

Please feel welcome to ask further!

Best regards,
Peter

[MHM Cisco World]

I do t fully understand what you meaning by

downstream routers'

But if you want to eliminate the large eigrp routes you can use

stub router

in spoke.