This topic is to discuss the following lesson:
Very nice article, Really good work .
Could we use dynamic neighbors in case of EBGP? Hub AS (65001) and spokes (65002) , also I will not use default route and will use allow in to accept routes.
sorry I know it is multiple questions 
Yes, you can absolutely use dynamic neighbors on BGP for this. In fact, this would be the preferred method, especially if you have a lot of spokes. By using the BGP option of “listen range” you can specify entire network ranges where you will allow a BGP neighborship to form. By using the listen range option, you can create DMVPN templates for the spokes and hub(s), so it is very easy to deploy new devices.
I don’t quite understanding what you are asking in the second part of your question. What DMVPN phase are you in? If you are in Phase 1, there is no reason you shouldn’t be using a default route, or at least a summary route, on each spoke that goes to the Hub. The reason is that with DMVPN Phase 1, all data plane traffic must flow through the Hub anyway, so your spokes learning about more specific routes isn’t doing them any good.
1 Like
Thanks Andrew P for your fast reply , please check below image .
I appreciate your feedback.am i right for not using default route ? especially that i will use (Local preference for out traffic , AS path prepending for in traffic)
Depending on your traffic complexity, one suggestion might be to have R1 and R2 learn their routes via BGP (or a default route), and simply use a floating static default route with a high administrative distance (obviously higher than 20) on R1 and R2 towards the Hub. This way, if your BGP relationships should fail with the preferred local loop connection, the floating route will be inserted and traffic will route via the DMVPN.
I don’t know all the details about your network, so this simplistic approach might not work in your situation, but from what I seeing, it will allow R1 and R2 the ability to fall back on a secondary path should you need it.
Many thanks Andrew P for your support
I don’t hear the voice on the video.
Hi Hyun,
I just checked but it’s working here. Anything on your end that might cause the sound not to play? Does it make any difference if you use another browser?
Rene
“You can use this for both eBGP and iBGP but there is one catch…the remote routers have to be in the same AS.”
If the clause says remote routers have to be in same AS, doesn’t it mean it is iBGP ?? How does dynamic peering then supported in eBGP scenario ?
I may be wrong, just to clarify
Hi Siva,
If you use dynamic peers then all your spokes have to be in the same AS. If the hub is in the same AS then you would have iBGP everywhere. If the hub is using another AS number then you are using eBGP.
Rene
Hi Ren,
Could you help me clarify the difference between 0.0.0.0/0 and 0.0.0.0/32. According to my understanding, 0.0.0.0/0 means any network. However, in this lab, when we use 0.0.0.0/0 in the Prefix-list, why was only default route permitted but not any prefixes?
Thanks.
Hi @viphuongquang,
In routing, 0.0.0.0/0 means that we have network 0.0.0.0 with a subnet mask of 0.0.0.0, in other words….all networks.
0.0.0.0/32 isn’t really used. A subnet mask of /32 (255.255.255.255) refers to a single IP address, in other words, 0.0.0.0/32 is a host address. It’s a special address though, RFC 5735 talks about it.
Don’t confuse this with an access-list btw If you configure 0.0.0.0/32 in an access-list, you are not specifying a subnet mask but a wildcard. In other words, 0.0.0.0/32 in an access-list is the same as 0.0.0.0/0 which will permit all networks.
Prefix-lists work a bit different than access-lists. With the prefix-list, we have an exact match. I have a permit for 0.0.0.0/0 so routes will have to match that exact entry. The only route that matches 0.0.0.0/0 is the default route.
Hope that helps!
Thanks a lot for your explanation , Rene.
Hello,
scenario eBGP with same AS on the spokes.
You said - “It would be best to get rid of the network command on the hub, we don’t need this entry.”
Why ? Network command is still a must for default route advertisment to spokes.
Regards !
Hi Bartek,
I’m talking about the 1.1.1.1/32 entry. The default route is required but we don’t need the 1.1.1.1/32 entry on the spoke routers. It’s something you could filter.
Rene
“we’ll start with eBGP with the same AS number on all spokes”. It’s probably a typo error. Should be different AS number on each spoke ?
Hello Maodo
Yes you are correct. This is a typo. I will let @ReneMolenaar know.
Thanks for catching that!
Laz
kayoutoure’s typo comment still not fixed. and another one below also:
“The default route is installed and we can see 1.1.1.1/32. It would be best to get rid of the network command on the hub, we don’t need this entry. Let’s see if the spokes can still reach each other:”
Removing the network command (network 0.0.0.0) also removes default route from spokes. Spokes no longer can reach each other.
1 Like
Thanks Viet, I just fixed that old typo and changed the sentence about the network command so it’s about the 1.1.1.1/32 network.