Using autonomous-system under Router EIGRP on VRF

[mahesh18]

                   Hi everyone,

When we user VRF  on Router  we config it as below

router eigrp 33

auto-summary

!

address-family ipv4 vrf SALES

redistribute connected

redistribute static

   no auto-summary

autonomous-system 33 ***********************************??????

exit-address-family

Need to know even though we config the command router eigrp 33 then why we need to use

autonomous-system 33  command again to tell the router it is EIGRP AS  33?

Many thanks

MAhesh

[Peter Paluch · Accepted solution]

Hello Mahesh,

Every command placed in the "main" configuration of the EIGRP is relevant to the EIGRP process running over the global routing table. However, as soon as you enter the address-family ipv4 vrf SALES, you are creating a new, separate and independent process running over a separate VRF. As the processes running over the global routing table and the VRF table are totally independent, so are their autonomous system numbers. Therefore, it is necessary to define the AS number in the address-family, otherwise, the per-VRF EIGRP process would not know which AS number to use. Even if there is really no EIGRP process being run over the global routing table, like in your example, you still need to enter some AS number when configuring the EIGRP because the AS number is a required parameter in the router eigrp command. However, whether that number is identical or different to the AS number of the per-VRF EIGRP instance does not matter. Remember - the per-VRF EIGRP instance is a separate process over a separate routing table (and a set of interfaces) and has its own independent AS numbering.

Best regards,

Peter

[mahesh18]

Hi Peter,

Thanks for excellent explanation.

So we can have config like this

Router eigrp  33

address-family ipv4 vrf SALES

autonomous-system 30 *****************Different AS  Numer

It should also work without any  issues right?

Thanks

MAhesh

[Peter Paluch · Accepted solution]

Hello Mahesh,

It should also work without any  issues right?

Oh, yes, absolutely, it will work. In fact, I would personally believe that in most cases, the AS number of the global EIGRP process and the AS numbers of per-VRF EIGRP processes will be different.

Best regards,

Peter

[mahesh18]

Hi Peter,

Many thanks for so great explanation!.

Your posts are always great  to read.

Best Regards

Mahesh

[Peter Paluch]

Hello Mahesh,

Thank you very much! You are very kind.

Best regards,

Peter

[MARK BAKER]

Peter,

I agree that you would think the AS number would be different in most cases. However, I have a requirement that is getting pretty hairy in the current setup without setting up VRF. I will try to explain briefly and then ask a question of you.

I have a remote site with two ISR WAN routers. Each router connects to the same two WAN networks. WAN1 = 100Mbs and WAN2 = 50Mbs. I have been asked to place a link balancer in the picture to utilize both WANs. The problem is that the link balancer sits behind the ISR WAN routers and each router is connected to both WANs. I have been coming up with different ways to have ISR1 prefer WAN1 and ISR2 prefer WAN2 and configure the LB to use ISR1 as the 100mbs gateway and ISR2 as the 50Mbs gateway, but the config gets overly complicated trying to account for all failure scenarios while providing optimal routing.

My thought is to create a vrf on each ISR router and have the 50mbs link connect to it on the WAN side with the 100mbs link connected to the global routing table. On the LAN side I was going to have two LAN interfaces on each ISR (global and vrf) connect to the same vlan on the site's core switch on the same IP subnet all running eigrp AS 100. Logically this would look like four WAN routers, two with 100Mbs links and two with 50Mbs links all connected to the sites core switch. I could then configure the link balancer to point to ISR1 global LAN IP as my 100Mbs gateway and the ISR2 vrf LAN IP as my 50Mbs gateway. It would then balance traffic proportionately.

I would also block the vrf LAN interfaces from learning routes from the global LAN interfaces and vice-versa. This would prevent a packet sent to ISR2 vrf LAN interface by the LB from trying to route back out the vrf LAN interface to a global LAN interface (100bms min bw) which would probably be preferred. Another benifit of doing this is that the site won't act as a transit between the two WAN networks. Split-horizon on the site's core switch VLAN interface would also help satisfy this requirement without any further configuration.

Sorry it's not as brief as I had hoped. I just hope it was clear enough to understand for anyone that would like to comment or offer suggestions.

Two questions:

1. Can I use the same EIGRP AS on the global and vrf? (I think you answered this already as yes. This question led me to this post).

2. Can I have the global and vrf LAN interface on the same IP subnet?

Planned configuration:

C |----------------------.2 | Global  ISR1 global |---- 100Mbs

O |----------------------.3 | vrf                           vrf |----- 50mbs

R |10.1.1.0/24

E |.1

S |----------------------.4 | global  ISR2 global |----- 100mbs

W|----------------------.5 | vrf                           vrf |------ 50mbs

LB

100Mbs link = 10.1.1.2

50mbs link = 10.1.1.5

if ISR2 50mbs WAN link goes down ISR2 would route to ISR1 .3 and still use 50mbs link. Same with ISR1 100mbs link.

Thank you,
Mark

[Javvadijathin6]

1. Can I use the same EIGRP AS on the global and VRF?
Yes, you can use the same EIGRP AS number in both the global routing table and the VRF. However, EIGRP treats the routing processes separately unless you configure route leaking between them using route-target import/export or redistribute eigrp. Since you mentioned that you don’t want the global and VRF instances to exchange routes, this won’t be an issue. You’ll just need to ensure that each EIGRP instance only advertises the correct routes within its respective routing domain.
2. Can I have the global and VRF LAN interfaces on the same IP subnet?
No, you cannot have two interfaces (one in the global routing table and one in a VRF) on the same router assigned to the same IP subnet. The router would not be able to determine which interface to use for a packet destined to that subnet. However, you can achieve the desired effect by using an alternative approach:
Recommended Workaround
Instead of putting both interfaces in the same subnet, you can configure:
• The global routing table interfaces to use 10.1.1.0/24.
• The VRF interfaces to use a slightly different subnet, e.g., 10.1.2.0/24 (or even a secondary IP on the same VLAN with proxy ARP enabled).
This way, your link balancer can:
• Use 10.1.1.2 (ISR1 Global) for 100Mbps traffic.
• Use 10.1.2.5 (ISR2 VRF) for 50Mbps traffic.
Then, to ensure reachability between VRF and global networks, you could use static routes or controlled redistribution (if needed). However, since you want strict separation, keeping them isolated is fine.
Alternative Approach: Loopbacks for VRF Connectivity
• Assign a loopback interface in the VRF with an IP (e.g., 10.1.2.5/32 on ISR2).
• Advertise this loopback into EIGRP.
• Point the link balancer’s 50Mbps gateway to this loopback IP instead of a physical interface.
This avoids the IP subnet issue and maintains clean separation.
Handling Failover Scenarios
Your failover logic generally makes sense, but consider:
1. Tracking WAN interface state: Use an IP SLA with object tracking to ensure that the 50Mbps traffic doesn’t loop back into the 100Mbps path if an ISP failure occurs.
2. Using BFD with EIGRP: Helps detect failures faster if a WAN link goes down.
3. Blocking route advertisement between VRF and global: If VRF needs to reach the global table in failure scenarios, carefully design route redistribution.

Thank you,

Jathin