cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1222
Views
5
Helpful
3
Replies

Unable to use secondary ip address within vrf

phetisoff
Level 1
Level 1

Hello guys!


Here is configuration of the ASR1001 interface:

!
interface Port-channel1.450
 description transport-outside
 encapsulation dot1Q 450
 vrf forwarding WAN-INET-1
 ip address X.X.X.10 255.255.255.240 secondary vrf WAN-INET-1
 ip address X.X.X.8 255.255.255.240
 no ip redirects
 no ip proxy-arp
 ip nat outside

end


I can ping secondary address from primary.

RouterA#ping vrf WAN-INET-1 X.X.X.10 so X.X.X.8

Packet sent with a source address of X.X.X.8
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms


RouterA#sh arp vrf WAN-INET-1
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  X.X.X.8           -   24e9.b38d.c740  ARPA   Port-channel1.450
Internet  X.X.X.10          -   24e9.b38d.c740  ARPA   Port-channel1.450
RouterA#

All seems to be good but router doesn't respond on ARP requests to secondary IP.

RouterB#ping X.X.X.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to X.X.X.8, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

RouterB#ping X.X.X.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to X.X.X.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

RouterB#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  X.X.X.8           7   24e9.b38d.c740  ARPA   Port-channel1.450
Internet  X.X.X.9           -   24e9.b38d.c840  ARPA   Port-channel1.450

Is it a bug or some kind of limitation of ASR1001 platform?


RouterA#sh ver
Cisco IOS XE Software, Version 03.16.06.S - Extended Support Release
Cisco IOS Software, ASR1000 Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S6, RELEASE SOFTWARE (fc3)

3 Replies 3

ismiller
Cisco Employee
Cisco Employee

I tried to recreate this issue in a lab environment on the same IOS XE code train (3.16) and 15.5(3)S IOS. I know that's not the exact same platform you're running but it's the closest I could get with the resources I have available to me.  Unfortunately, everything is working fine for me and I'm unable to reproduce the issue. 

 

I connected two CSR 1000vs directly to one another with a 2 member port channel with a sub-interface of 450 on both Router A and Router B just to quickly test the concept. I have the following config on the interface of RouterA: 

 

interface Port-channel1.450
encapsulation dot1Q 450
ip vrf forwarding TEST
ip address 192.168.1.10 255.255.255.240 secondary vrf TEST
ip address 192.168.1.8 255.255.255.240
no ip redirects
no ip proxy-arp
end

 

and RouterB: 

 

encapsulation dot1Q 450
ip address 192.168.1.9 255.255.255.240
end

 

ARP from RouterA:

 

Internet 192.168.1.8 - 001e.4964.84c0 ARPA Port-channel1.450
Internet 192.168.1.9 10 001e.146b.4bc0 ARPA Port-channel1.450
Internet 192.168.1.10 - 001e.4964.84c0 ARPA Port-channel1.450

 

ARP from RouterB:

 

Internet 192.168.1.8 11 001e.4964.84c0 ARPA Port-channel1.450
Internet 192.168.1.9 - 001e.146b.4bc0 ARPA Port-channel1.450
Internet 192.168.1.10 11 001e.4964.84c0 ARPA Port-channel1.450

 

I didn't set up NAT because it doesn't look like it's playing an active role here since it's the outside interface and nothing should running through NAT to test connectivity to another device on the same subnet. 

 

I really wish I could reproduce the issue so we could learn something together, but I hope this at least helps narrow down where the issue may lie a little bit. 

 

Is there anything in between these two routers of yours that could play any role in disrupting ARP? I wouldn't suspect a switch between RouterA and RouterB to cause ARP issues exclusively with a secondary IP address but maybe I'm missing something. 

 

 

 

Hi ismiller, thanks for your assistance.

 

I connected routers directly and got the same result as You. RouterA gets ARP reply of the RouterB secondary IP address and all works perfectly fine.

 

Now I'm very confused how a stack of several Cisco 3850 can filter ARP packets in such a way.

That's very interesting! Perhaps the ARP reply is being dropped by the switch for some reason. I have never seen that cause an issue in the past though.



If it's not too much trouble, seeing the configuration on the trunk interfaces on the 3850 stack running to RouterA and RouterB may be helpful.



It may be worth taking a look at ARP debugs as well if you are comfortable providing those :) I will try to lab this out tonight and see if I can reproduce the problem in a quarantined environment.


Getting Started

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: