Proxy ARP on Junos
In this post I will discuss about Proxy ARP feature on Junos, more exactly on EX4200 platform.
When a host sends an ARP Request to a switch configured with Proxy ARP, the switch send its own MAC address to resolve the ARP for the destination host and the source host starts to used the switch MAC address to encapsulate the packets for the destination host.
The are two types of modes in which Proxy ARP can function:
- unrestricted – the switch responds to all ARP requests regardless they are in the same subnet or not. This is the default mode of Proxy ARP when it’s enabled and not specified which type to be used
- restricted – the switch responds only if the hosts are in different subnets and the hosts in the same subnet will use the normal mechanism to resolve ARP
These are some best practice recommendations:
- Set proxy ARP to restricted mode.
- Use restricted mode when configuring proxy ARP on RVIs.
- If you set proxy ARP to unrestricted, disable gratuitous ARP requests on each interface enabled for proxy ARP.
Disabling gratuitous ARP is useful to avoid the situation of the switch’s response to a gratuitous ARP request appearing to the host to be an indication of an IP conflict. Later you will see that using unrestricted mode without disabling gratuitous ARP leads to duplicate IP address detection.
Let’s use this diagram to understand better Proxy ARP:
Considering that both SW-3 and SW-2 are in the same VLAN, 4000 and they have the IP addresses from the diagram, then once SW-3 starts to ping SW-2, you get this on SW-3:
{master:0}[edit] root@SWITCH-3# run show arp no-resolve MAC Address Address Interface Flags 00:26:88:79:81:4f 4.4.4.2 ge-0/0/14.0 none {master:0}[edit] root@SWITCH-3#
And SW-2:
{master:0}[edit] root@SWITCH-2# run show arp no-resolve MAC Address Address Interface Flags 00:19:e2:54:e4:51 4.4.4.3 ge-0/0/12.0 none {master:0}[edit] root@SWITCH-2#
It is as simple as this, SW-3 resolve the ARP for 4.4.4.2 with the MAC address of SW-2 ge-0/0/14 with no interference from SW-1.
Now, let’s configure Proxy ARP in unrestricted mode on SW-1 on RVI vlan.4000:
{master:0}[edit] root@SWITCH-1# show interfaces vlan unit 4000 { proxy-arp unrestricted; family inet { address 4.4.4.1/24; } } {master:0}[edit] root@SWITCH-1#
After this is configured, let’s see if SW-3 can reach SW-2:
{master:0}[edit] root@SWITCH-3# run ping 4.4.4.2 count 3 PING 4.4.4.2 (4.4.4.2): 56 data bytes 64 bytes from 4.4.4.2: icmp_seq=0 ttl=63 time=35.854 ms 64 bytes from 4.4.4.2: icmp_seq=1 ttl=63 time=1.303 ms 36 bytes from 4.4.4.1: Redirect Host(New addr: 4.4.4.2) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 f97e 0 0000 40 01 711e 4.4.4.3 4.4.4.2 64 bytes from 4.4.4.2: icmp_seq=2 ttl=63 time=1.447 ms --- 4.4.4.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.303/12.868/35.854/16.254 ms {master:0}[edit] root@SWITCH-3#
Let’s check the ARP table on SW-3:
{master:0}[edit] root@SWITCH-3# run show arp no-resolve MAC Address Address Interface Flags 00:23:9c:0b:b2:01 4.4.4.2 ge-0/0/14.0 none 5c:5e:ab:64:25:81 192.168.1.1 me0.0 none Total entries: 2 {master:0}[edit] root@SWITCH-3#
On SW-1:
{master:0}[edit] root@SWITCH-1# run show arp no-resolve MAC Address Address Interface Flags 00:26:88:79:81:4f 4.4.4.2 vlan.4000 none 00:19:e2:54:e4:51 4.4.4.3 vlan.4000 none 5c:5e:ab:64:25:81 192.168.1.1 me0.0 none Total entries: 3 {master:0}[edit] root@SWITCH-1#
And on SW-2:
{master:0}[edit] root@SWITCH-2# run show arp no-resolve MAC Address Address Interface Flags 00:23:9c:0b:b2:01 4.4.4.1 ge-0/0/12.0 none 00:23:9c:0b:b2:01 4.4.4.3 ge-0/0/12.0 none 5c:5e:ab:64:25:81 192.168.1.1 me0.0 none Total entries: 3 {master:0}[edit] root@SWITCH-2#
Before I started the ping from SW-3 towards SW-2, I started a monitor traffic interface vlan on SW-1:
{master:0}[edit] root@SWITCH-1# run monitor traffic interface vlan no-resolve verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is OFF. Listening on vlan, capture size 96 bytes 16:20:00.705925 In arp who-has 4.4.4.2 tell 4.4.4.3 16:20:00.706148 Out arp reply 4.4.4.2 is-at 00:23:9c:0b:b2:01 16:20:00.709842 Out arp who-has 4.4.4.2 tell 4.4.4.1 16:20:00.711813 In arp reply 4.4.4.2 is-at 00:26:88:79:81:4f 16:20:00.739314 In arp who-has 4.4.4.3 tell 4.4.4.2 16:20:00.739365 Out arp reply 4.4.4.3 is-at 00:23:9c:0b:b2:01 16:20:00.742730 In IP truncated-ip - 30 bytes missing! 4.4.4.2 > 4.4.4.3: ICMP echo reply, id 9722, seq 0, length 64 16:20:00.742783 Out IP truncated-ip - 2 bytes missing! 4.4.4.1 > 4.4.4.2: ICMP redirect 4.4.4.3 to host 4.4.4.3, length 36 16:20:01.706724 In IP truncated-ip - 30 bytes missing! 4.4.4.3 > 4.4.4.2: ICMP echo request, id 9722, seq 1, length 64 16:20:01.706775 Out IP truncated-ip - 2 bytes missing! 4.4.4.1 > 4.4.4.3: ICMP redirect 4.4.4.2 to host 4.4.4.2, length 36 16:20:02.707635 In IP truncated-ip - 30 bytes missing! 4.4.4.3 > 4.4.4.2: ICMP echo request, id 9722, seq 2, length 64 16:20:02.707685 Out IP truncated-ip - 2 bytes missing! 4.4.4.1 > 4.4.4.3: ICMP redirect 4.4.4.2 to host 4.4.4.2, length 36 ^C 12 packets received by filter 0 packets dropped by kernel {master:0}[edit] root@SWITCH-1#
You can see that when SW-3(4.4.4.3) tries to find who is SW-2(4.4.4.2), SW-1 responds with its own MAC(00:23:9c:0b:b2:01)
16:20:00.705925 In arp who-has 4.4.4.2 tell 4.4.4.3 16:20:00.706148 Out arp reply 4.4.4.2 is-at 00:23:9c:0b:b2:01
Then SW-3 sends the ICMP request that reach SW-1 that triggers the ARP resolution for SW-2
16:20:00.709842 Out arp who-has 4.4.4.2 tell 4.4.4.1 16:20:00.711813 In arp reply 4.4.4.2 is-at 00:26:88:79:81:4f
Then the ICMP request reach to SW-2 which cause SW-2 to trigger the ARP resolution for SW-3(4.4.4.3) to which SW-1 responds with its own MAC:
16:20:00.739314 In arp who-has 4.4.4.3 tell 4.4.4.2 16:20:00.739365 Out arp reply 4.4.4.3 is-at 00:23:9c:0b:b2:01
Here SW-2 detects that there is another MAC address replying for its IP address. This could have been avoided if gratuitous ARP was disabled:
Finally, SW-2 sends the ICMP reply back to SW-3:
16:20:00.742730 In IP truncated-ip - 30 bytes missing! 4.4.4.2 > 4.4.4.3: ICMP echo reply, id 9722, seq 0, length 64
Next you can see that some of the traffic between SW-3 and SW-2 reaches to the routing engine of SW-1 that is configured with Proxy ARP.
I attached the packet captures(proxy_arp) from SW-2, SW-3 and SW-1 taken using “monitor traffic interface” commands for ge-0/0/12, ge-0/0/14 and vlan interfaces just before SW-3 started to ping SW-2 and when the ARP tables were empty.
There is no difference on how restricted and unrestricted modes works, it’s just about to what kind of ARP Requests the switch replies.
I hope you found this interesting.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Comments
So empty here ... leave a comment!