Why IP Address gets removed after configuring IP VRF Forwarding
Dear All,
My queries:
Why IP Address gets removed after configuring IP VRF Forwarding on an interface?
Is it an IOS limitation?
Is Cisco doing any enhancement to stop auto removal of ip address from the interface?
Merci Beacoup,
Ashish
Comments
VRF : Virtual Routing and Forwarding means it creates a separate instance of routing table (each VRF uses it's own instance of routing table rather than using the global routing table.) By default all interface belongs to global routing (global VRF). When you enter the ip vrf forwarding command, interface moves from global to that particular VRF but couldn't transfer the IP info (rather than transfering IP info, it removes).
See here:
R1(config-if)#do show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 192.168.0.2, 00:00:17, FastEthernet1/0
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 100.100.100.0/24 is directly connected, Loopback100
L 100.100.100.100/32 is directly connected, Loopback100
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, FastEthernet1/0
L 192.168.0.1/32 is directly connected, FastEthernet1/0
Now Lo100 interface is in global routing table.
R1(config)#int lo100
R1(config-if)#ip vrf forwarding TEST
% Interface Loopback100 IPv4 disabled and address(es) removed due to disabling VRF TEST <-- Because interface is moving from global to TEST VRF
R1(config-if)#ip add 100.100.100.100 255.255.255.0
R1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 192.168.0.2, 00:00:23, FastEthernet1/0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, FastEthernet1/0
L 192.168.0.1/32 is directly connected, FastEthernet1/0
R1#sh
R1#show ip route vrf TEST
Routing Table: TEST
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is not set
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 100.100.100.0/24 is directly connected, Loopback100
L 100.100.100.100/32 is directly connected, Loopback100
[:D]
ashe,
As nnn wrote, assigning an interface to a VRF places it in a different routing table, which most often will use a different IP address range.
I don't think there is any reason for Cisco to change this behavior, because it does not make sense to assume that the same IP address will be used in a different VRF.
The proper order of operations is:
In the case where an IP address is assigned to an interface (as in initial configs for Lab Exam), and the interface needs to be placed in a VRF, use "do show running int <type/number>" before applying the "ip vrf forwarding <VRF>" statement.
From a programic point of view, i guess it could be done both ways ( with or without removing the ip address configuration). I guess it is only a cosmetic thing, so that the CEF table has more chances to be properly populated with the repsective prefix in the correct VRF.
Good luck with your studies!
i am agree with nnn well this behevour does happens when your interface is the part of global routing table and then you convert this interface to vrf routing table in that case you have to re-assign ip add on this interface for making it to the part of vrf.
but you can make any interface as the part of vrf routing table without reassigning ip address on the interface :-
such as:-
just use interface and provide ip vrf forwording vrf_name after making this interface to the part of vrf then can assign ip addresson this interface. in this process, there would not be any reassigning process
router(config)#interface fast ethernet 0/0
router(config-if)#ip vrf for VRF_NAME
router(config-if)#ip address x.x.x.x x.x.x.x
in this process no reassigning process would be happened
this is really old post
but I would like to mention that before when I place ip vrf for instance under interface I am getting at least which IP address was remove - did not say subnet mask but at least you see ip address removed from the interface
Now as practice on the ver 15.4 - I just see the message from the console that ip address was removed - see bellow
R5(config-subif)#ip vrf for VPN_A
% Interface GigabitEthernet0/1.58 IPv4 disabled and address(es) removed due to disabling VRF
VPN_A
% Interface GigabitEthernet0/1.58 IPv4 disabled and address(es) removed due to disabling VRF
VPN_A
INE - The Industry Leader in CCIE Preparation
http://www.INE.com
Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx