Menu

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.

 

The following two tabs change content below.
My Facebook profileMy LinkedIn profile

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Comments

So empty here ... leave a comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

Last posts

Sidebar
%d bloggers like this: