Mailing List Archive

EX4200 missing ARP entry work-around
We have decided on a better work-around for our missing ARP entry
problems on the EX4200 and friends.

As you may recall, the EX4200 will sometimes have an ARP entry in the
control-plane, but it will not be present in the data-plane. You can
investigate by checking your destination IP address with the command
`show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32`
which will produce output like this:

PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32

Route Type Paths RtIdx Rpf SipSa Row:Col:Row:Col
-------------------- ---- ----- ----- --- ----- ---------------
192.0.2.2 ECMP 0 2037 No No 439:0:0:0

Dev0 (RtIdx:2037)
-----------------
Command : Route CpuCode : 3
AppSpCpuCodeEn : 0 UcSipFiltEna : 0
TtlDecEna : 1 TtlOptChkBypass: 0
IngressMirror : 0 QoSProfileEn : 0
QoSProfileIndex : 0 QoSPrecedence : 1
ModifyUp : 2 ModifyDscp : 0
CounterSet : 2 ArpBc2Cpu : 0
SipAccessLevel : 0 DipAccessLevel : 0
IcmpRedirExpnMirr : 0 MtuProfileIdx : 2
Ipv6ScopeCheckEn : 0 Ipv6DstSiteId : 0
NhTnnl : 0 NhTnnlIdx : 0
NhVlan : 6 NhIf : VIDX4095
NhArpIdx : 138
Device: 0
ArpEntry Idx 138 : 00:2b:f0:19:87:01
Hit/Miss : N

Notice above a reference to NhArpIdx 138. In order for forwarding to
work correctly, there must be an entry # 138 in the `halp-nh
arp-table.` Since there isn't one, the NhIf shown is VIDX4095, not a
port. However, if you want to verify that there is no NhArpIdx 138 in
the hardware, you can examine the table with `show halp-nh arp-table`
and scroll down to where # 138 should be. You won't find it!

PFEM0(vty)# show halp-nh arp-table
Device: 0
... lots of scrolling ...
ArpEntry Idx 136 : 00:18:8b:f8:b6:6e
ArpEntry Idx 137 : 00:0e:b6:2d:01:a0
ArpEntry Idx 139 : 00:19:b9:f9:24:2a
ArpEntry Idx 140 : 78:2b:cb:3c:91:60

How do you get the switch to populate that entry? Well, since `clear
arp` on the EX4200 doesn't actually do what it is supposed to do, what
we have been doing in the past is deleting whole subnets, impacting
potentially many machines, and then re-adding them. This is not good
but it does work.

Our new solution is much better. We just add a bogus static arp entry
for 192.0.2.2, pointing to some made-up MAC address, and then we
commit, roll back, and commit again. Like magic, the ARP entry will
re-populate correctly. Almost as if you really did have a `clear arp`
command on the EX4200, one that worked right!

After adding and then deleting the bogus static ARP for 192.0.2.2 you
can re-examine the PFE and see the results. Also, your customer's
Internets will begin working correctly again.

I hope this helps.
--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: EX4200 missing ARP entry work-around [ In reply to ]
Have you contacted JTAC about this issue?



On Wed, Jan 11, 2012 at 2:14 PM, Jeff Wheeler <jsw@inconcepts.biz> wrote:

> We have decided on a better work-around for our missing ARP entry
> problems on the EX4200 and friends.
>
> As you may recall, the EX4200 will sometimes have an ARP entry in the
> control-plane, but it will not be present in the data-plane. You can
> investigate by checking your destination IP address with the command
> `show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32`
> which will produce output like this:
>
> PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2
> prefix-length 32
>
> Route Type Paths RtIdx Rpf SipSa Row:Col:Row:Col
> -------------------- ---- ----- ----- --- ----- ---------------
> 192.0.2.2 ECMP 0 2037 No No 439:0:0:0
>
> Dev0 (RtIdx:2037)
> -----------------
> Command : Route CpuCode : 3
> AppSpCpuCodeEn : 0 UcSipFiltEna : 0
> TtlDecEna : 1 TtlOptChkBypass: 0
> IngressMirror : 0 QoSProfileEn : 0
> QoSProfileIndex : 0 QoSPrecedence : 1
> ModifyUp : 2 ModifyDscp : 0
> CounterSet : 2 ArpBc2Cpu : 0
> SipAccessLevel : 0 DipAccessLevel : 0
> IcmpRedirExpnMirr : 0 MtuProfileIdx : 2
> Ipv6ScopeCheckEn : 0 Ipv6DstSiteId : 0
> NhTnnl : 0 NhTnnlIdx : 0
> NhVlan : 6 NhIf : VIDX4095
> NhArpIdx : 138
> Device: 0
> ArpEntry Idx 138 : 00:2b:f0:19:87:01
> Hit/Miss : N
>
> Notice above a reference to NhArpIdx 138. In order for forwarding to
> work correctly, there must be an entry # 138 in the `halp-nh
> arp-table.` Since there isn't one, the NhIf shown is VIDX4095, not a
> port. However, if you want to verify that there is no NhArpIdx 138 in
> the hardware, you can examine the table with `show halp-nh arp-table`
> and scroll down to where # 138 should be. You won't find it!
>
> PFEM0(vty)# show halp-nh arp-table
> Device: 0
> ... lots of scrolling ...
> ArpEntry Idx 136 : 00:18:8b:f8:b6:6e
> ArpEntry Idx 137 : 00:0e:b6:2d:01:a0
> ArpEntry Idx 139 : 00:19:b9:f9:24:2a
> ArpEntry Idx 140 : 78:2b:cb:3c:91:60
>
> How do you get the switch to populate that entry? Well, since `clear
> arp` on the EX4200 doesn't actually do what it is supposed to do, what
> we have been doing in the past is deleting whole subnets, impacting
> potentially many machines, and then re-adding them. This is not good
> but it does work.
>
> Our new solution is much better. We just add a bogus static arp entry
> for 192.0.2.2, pointing to some made-up MAC address, and then we
> commit, roll back, and commit again. Like magic, the ARP entry will
> re-populate correctly. Almost as if you really did have a `clear arp`
> command on the EX4200, one that worked right!
>
> After adding and then deleting the bogus static ARP for 192.0.2.2 you
> can re-examine the PFE and see the results. Also, your customer's
> Internets will begin working correctly again.
>
> I hope this helps.
> --
> Jeff S Wheeler <jsw@inconcepts.biz>
> Sr Network Operator / Innovative Network Concepts
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp