This topic is to discuss the following lesson:
Hi Rene,
Hopefully, you are fine…Beside study everyday I am checking your new lesson and forum as well, After taken membership i am able to see you are continually adding new lessons in CCIE Routing & Switching Written like:
* IPSec VTI Virtual Tunnel Interface April 2018
* BGP PIC (Prefix Independent Convergence) Core & Edge March 2018
* BGP Multipath load sharing iBGP and eBGP March 2018
* BGP Aggregate AS-SET March 2018
* IPv6 RA Guard March 2018
* IPv6 over MPLS 6PE/6VPE March 2018
* IPv6 DHCPv6 Prefix Delegation February 2018
* Multicast Tunnel RPF Failure February 2018
* Multicast IGMP Proxy February 2018
* Multicast PIM Sparse-Dense Mode January 2018
* Multicast PIM Snooping January 2018
Which is very helpful for us…but i have one question above topics are from CCIEV5 syllabus or u are just preparing slowly slowly of all CCIE content means still the CCIE content is not fully ready ?
Dont get me wrong Rene this is my general question you are our trainer so as student i can ask my trainer
Thanks & Regards,
Arindom
Hi Arindom,
There was a small list of CCIE R&S written topics that I still didn’t have so right now, I’m working on completing those Just a few more and then the written course is 100% according to the blueprint.
Rene
Hi Rene,
Thanks for replying…
Yes yes sure All the best Rene:+1: we believe your lesson will be best for CCIE technology learning,I will take your CCIE lession as well.but due to some financial problem its not effortable for me to take annual membership but i will continue with monthly membership.
Thanks & Regards,
Arindom
Isn’t IPSec tunnel mode not supporting multicast?
How does EIGRP establishes neighborship within these routers?
Hello Ray
It is true that IPsec alone does not support multicast. However, if you want to create an EIGRP neighbourship over IPsec, you must run a GRE tunnel in conjunction with IPsec. GRE supports multicast so this would solve the problem.
Another option is to use an EIGRP static neighbour. This automatically makes EIGRP use only unicast for communication between neighbours.
I hope this has been helpful!
Laz
Thank u Laz! however in this lesson, Rene did not use either GRE tunnel or EIGRP static neighbor?
Hi Rene/Laz,
Happy new year, let imagine that we don’t have any control on spokes routers and they belong to different organizations and they need to access to some of our internal networks, does you think a better way to achieve that it’s trough the routing or trough ACLs ?
Best regards,
Imel
Hello Thierry
From a technical standpoint, if the choice was between those two, using ACLs would be a better choice. The purpose of ACLs is to filter traffic, and you can most effectively control what traffic you allow and what traffic you disallow using them. Routing is more cumbersome to use as a filtering mechanism, and it is not nearly as powerful. Needless to say, routing has a whole different purpose, and should not be used in such a fashion, as it could cause unintentional and unpredictable changes to traffic patterns.
IPSec VTI, and VPN technologies in general, are features that are best used when you have control over both the spokes and the hub devices. If you don’t, it’s still doable, but there are more administrative issues involved. If you are an organization that wants to offer customers secure access to your internal resources, the most appropriate technology to use is MPLS L3 VPN. It would provide you with the most scalable solution, and provide you with the tools necessary to achieve both security and routing among remote sites. You can find out more about that at the following lesson:
I hope this has been helpful!
Laz
So I’ve managed to duplicate both this one as well as the original IPSEC GRE tunnel (which as pointed out earlier requires we know a lot about each side whereas this is more dynamic). One thing I’m trying to accomplish and have been unable to do with either setup (IPSEC VTI or IPSEC GRE) is to tunnel two VRFs through the public connection. The tunnel is not in a VRF (its the global routing table) so I don’t know how to do the “vrf tunnel” to get through either of the above mentioned tunnels… Suggestions? Effectively I have three different networks (2 VRFs plus global table) that I need to get from one side of a tunnel to the other…
Hello Marcos
In order to achieve what you are describing, you will have to use a feature called VRF-aware IPSec. This is a feature that allows you to route multiple VRFs over a single tunnel. You can find out more information about it at this Cisco documentation:
Some more condensed information can also be found here:
I hope this has been helpful!
Laz
Hi Rene and staff,
R1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.123.1 192.168.123.3 QM_IDLE 1004 ACTIVE
192.168.123.1 192.168.123.2 QM_IDLE 1003 ACTIVE
I would like know why in this show command the destination is R1’s address? We are in R1 so i think the destinations has to be the spokes right?
Hello Vanilson
In the output of the show crypto isakmp sa
command, the source IP address is always the address of the device that initiated the IKE negotiation. In a VTI configuration, it is the spokes that initiate the negotiation, so it makes sense that the sources will be the IP addresses of the spokes, and the destinations will be the IP address of the hub itself.
I hope this has been helpful!
Laz
Hi all,
Please could anyone with experience with Cisco ASR 1001 and Cisco 810 Wireless series routers help on the below.
I have these equipment on Hub and Spoke design and following a site decommission, I need to shutdown IPsec tunnel on these routers.
How many tunnels should i shut down and also what is the command to use to shut them down.
Kind regards
Mario
Hello Marius
It really depends upon what you want to achieve. Now I’m assuming you are using an IPSec VTI since that’s what you wrote in the title of your post. If you only want to shut down the VPN, then you simply have to disconnect the spoke router, and the virtual access interface on the hub will disappear. That’s the wonderful thing about the IPSec VTI. Now if you want to get rid of all of the configurations for each spoke, then you have to take a look and see if you are using the same preshared keys for all or different ones for each spoke. If you have a different one for each spoke, you can simply remove the one that corresponds to the spokes you want to remove. If you’re using the same, there is no need to configure anything.
Take a look at this lesson which shows details of how to configure IPSec VTI:
I hope this has been helpful!
Laz
Can VTI interfaces have some type of vpn-filter as in policy based VPNs in order to secure the resources?
Hello Luis
A VTI is actually an alternative to a policy-based VPN, and by definition, the use of a VTI will support route-based rather than policy-based VPNs. A VTI will not rely on a policy to define interesting traffic, but it will behave similarly to any other non-tunnel interface.
I hope this has been helpful!
Laz
I have tried to look everywhere for a good explanation of keyring and why we should use it. Can you explain context of when you would want to use this in contrast to using something like the below:
!
crypto isakmp policy 10
encr aes
hash sha256
authentication pre-share
group 5
crypto isakmp key DMVPN_KEY address 0.0.0.0
!
I am looking into this information because where I work they have these huge routers full of VRF, IPSEC, BGP and VTI, tunnels that use keyrings.
another question is and maybe I this is not enough information provided below is the following:
When you have the actual VTI tunnel in the VRF and the VTI tunnel has command “Tunnel protection ipsec profile NAME_OF_PROFILE” I dont understand how this command from within its VRF can access all the IPSEC info and profiles which are outside the vrf and global.
Hello Brian
Take a look at this post:
The following Cisco documentation describes how you can create VTIs that are VRF aware. It includes configuration exampls of how this is achieved.
I hope this has addressed your questions. If not, please give us some specific examples of configurations that are troubling you so we can address them directly.
I hope this has been helpful!
Laz
Thanks the link has a lot of configuration details and will be useful I am sure. I spoke with a Senior Co-worker that has worked in this environment for years.
I had also put the question to him specific to VRF and the IKE/SVTI information he summed it up as follows:
“The vrf only segments routes, (virtual route forwarding) it still has access to the global config. When we set the client or interface up in a vrf, we`re just stating that you need to use this route table instead of the global for this particular client vrf or interface. its not segmenting the entirety of the configurations for the client. Just the routing within the specific vrf.”
So to summarize basically VRF is mainly about routing and those points that pivot or make use of routing. Meaning the IKE global stuff such as policy is not routing so not segregated like the routes are and can communicate freely.
While this link you provide does not state this directly it kind of does indirectly as there is no special commands to allow communication so this means its not stopped in the first place.
I suppose to test this is just create a policy then create a single SVTI in a VRF and see if the policy maps can access the IKE/SVTI unhindered.
I am guessing that is the case or else they would have special commands to allow it and since there is no special commands that means it is just not stopped and the vrf only applies to the routing.
If that statement is to general we can specifically state more granularly that the VRF does not stop policy maps etc…
So I think I got my answer though probably should lab it up just to prove it out.