12-03-2016 12:26 PM - edited 03-05-2019 07:36 AM
I'm looking for a way to scale our IWAN design so that it might be able to accommodate an acquisition while keeping the acquired company separate from existing companies (no connectivity between a spoke in subsidiary A to subsidiary B). Both subsidiaries would access resources at hub, but I wouldn't want a spoke in subsidiary A to hairpin off the hub and connect to a spoke in subsidiary B. I'm thinking I could accomplish that piece using eigrp address families, 1 per subsidiary, and not route between them.
In the illustration provided, the hub asr would use its gig 0/0/0 interface as the source for 2 different tunnel interfaces, 1 per subsidiary. BGP would be used on that link to the next hop and service provider network to reach remote spoke tunnel endpoints. I think that's all sound, but my question relates to how/if IWAN would still work for both subsidiaries. Could I mark both tunnel interfaces as path MPLS for example? The idea being that subsidiaries using either tu10 or tu20 could use PfR.
thank you,
Bill
Solved! Go to Solution.
12-09-2016 09:04 AM
Hi Bill,
iWAN is possible for specific VRF context. A very basic sample configuration as below.
domain IWAN
vrf A
master hub
source-interface Loopback10
vrf B
master hub
source-interface Loopback20
HTH
-Amit
12-09-2016 09:04 AM
Hi Bill,
iWAN is possible for specific VRF context. A very basic sample configuration as below.
domain IWAN
vrf A
master hub
source-interface Loopback10
vrf B
master hub
source-interface Loopback20
HTH
-Amit
12-09-2016 09:35 AM
Thanks Amit. Yeah, that's exactly what I was looking for. It seems obvious now that you pointed it out. Am I correct in understanding then the single MC, and all the data center networks for that matter, will remain accessible to both VRFs via the global routing table on the LAN side of the ASR? And to expand a little on the remainder of the necessary config, I would create 2 address families under eigrp and tie my tunnel interfaces to each, e.g.
exit-af-interface
network 10.10.0.0 0.0.255.255 <- tunnel 10 subnet
exit-af-interface
network 10.20.0.0 0.0.255.255 <- tunnel 20 subnet
int tu10
10.10.1.1 255.255.0.0
tunnel vrf A
int tu20
10.20.1.1 255.255.0.0
tunnel vrf B
12-09-2016 07:25 PM
Hi William,
Yes, you will have to configure everything independently for each vrf while using iWAN excluding "domain iWAN". It includes below.
1. Independent master hub/borders for each vrf.
2. Independent tunnels for each vrf.
3. independent overlay routing mechanism (BGP or EIGRP) for each vrf.
4. PFR policies
Please rate if it helped.
HTH
-Amit
03-23-2017 12:56 AM
Hi Amit,
Thx for this clear explanation.
If you say " Independent master hub/borders for each vrf", I guess you mean a separate router per vrf?
Would this still be neccesary in iWAN 2.2? If no when will this be released?
01-22-2018 03:40 AM
Hi Amit,
It sounds like iWAN can be deployed by ISPs in multi-tenant way where each customer could have multiple branch locations all terminating on the hub in their dedicated VRF.
I heard that there is a limit of 20 VRFs on a hub border router for iwan. That is, there can be upto 20 customers per iwan deployment. Is that correct?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: