[j-nsp] Strange ARP issue on M7i
apurva modh
modh.apurva at gmail.com
Wed Aug 15 14:30:31 EDT 2012
it represents that the default arp pollicer is dropping the arp packets.
You dont need to apply this filter on any interface. It is applied on all
interfaces by default ... Default values of the arp policer is fine-tuned
such that it does not interrupt normal arp mechanism .. the counter in the
"show policer" should not increment in ideal scenarios ... check if there
is any machine is spoofing/flooding arp or not ...
btw, Your junos is very old .. try changing to new junos ,, there are many
improvements since then ...
On Wed, Aug 15, 2012 at 11:44 PM, Markus <universe at truemetal.org> wrote:
> Hi JP and all,
>
> thanks for all the replies. "show policer" shows:
>
> admin at ffm01.rt> show policer
> Policers:
> Name Packets
> __default_arp_policer__ 1140304
> __policer_tmpl__-term 0
> __policer_tmpl__-fc0 0
> __policer_tmpl__-fc0 0
> __policer_tmpl__-fc1 0
> __policer_tmpl__-fc0 0
> __policer_tmpl__-fc1 0
> __policer_tmpl__-fc2 0
> __policer_tmpl__-fc0 0
> __policer_tmpl__-fc1 0
> __policer_tmpl__-fc2 0
> __policer_tmpl__-fc3 0
>
> What does that mean?
>
> I don't seem to have anything configured related to that:
>
> admin at ffm01.rt> show configuration | grep arp
> < empty >
>
> Thank you!
> Markus
>
>
> Am 14.08.2012 21:37, schrieb JP Senior:
>
>> Hi, Markus.
>> I have experienced issues in previous deployments that have involved
>> built-in ARP policers.
>>
>> Hit up 'show policer', and look for __default_arp_policer__.
>>
>> JP Senior
>>
>>
>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.**nether.net<juniper-nsp-bounces at puck.nether.net>[mailto:
>> juniper-nsp-bounces@**puck.nether.net<juniper-nsp-bounces at puck.nether.net>]
>> On Behalf Of Markus
>> Sent: 14 August 2012 7:13 AM
>> To: juniper-nsp at puck.nether.net
>> Subject: [j-nsp] Strange ARP issue on M7i
>>
>> Hi all,
>>
>> last night I encountered something weird (in my opinion). Not sure if
>> Juniper related but maybe someone here has seen something like this?
>>
>> I was experiencing a strange effect that several websites hosted on a
>> Linux KVM VM didn't load properly. They would load but 90% of the time hang
>> in some strange way, the browser displaying "Waiting for
>> www.sitename.com..." after all the page has loaded, or even before anything
>> of the page was displayed. A minute later it would work sometimes, but only
>> for a short period of time. After eliminating all MySQL, Apache, KVM etc.
>> as the source of the problem I logged into the M7i in front of that host
>> and saw:
>>
>> admin at ffm01.rt> show arp no-resolve |grep 195.100.100.7
>> 00:25:90:38:66:c6 195.100.100.7 ge-0/0/0.0 none
>> 00:25:90:38:66:c6 195.100.101.34 ge-0/0/0.0 none
>>
>> With 195.100.100.7 being the KVM host. So I thought: why is 101.34 up?
>> It's an IP that wasn't in use for years. And in the Juniper config a
>> whole /24 was still getting routed to it. I thought, OK, the KVM host got
>> hax0red or something and the intruder assigned 101.34, but couldnt find
>> anything. 101.34 wasn't reachable from any machine in the same LAN and the
>> MAC could not be seen either. No traffic to/from it on the Switch
>> monitoring port either. All I saw was traffic (port scans I
>> think) to the /24 which ended up on the KVM host (195.100.100.7). That
>> was an indicator that the KVM host was really also saying "I have
>> 195.100.101.34". Or the Juniper insisted that the IP is at that MAC. I
>> suspect the latter. I shutdown the KVM host physically and cleared the ARP
>> cache on the Juniper, 195.100.100.7 was gone, but 195.100.101.34 was still
>> there with the identical MAC, as before.
>> I then removed the static route entry for the /24 which was pointing to
>> 195.100.101.34 and only then the arp entry for 195.100.101.34 disappeared!
>>
>> Isn't that weird? Where did that arp entry come from and why was it saved
>> on the Juniper for so long, and only got removed after I removed the static
>> routing of that /24?
>>
>> I'm running JUNOS 8.0R2.8. :)
>>
>> This didn't eliminate the problem with the websites reachability, I think
>> it is something local with my dialup connection as I see a lot of TCP
>> retransmission errors when accessing all sites on any of the VMs hosted on
>> that KVM host. Through an alternative dialup provider everything is fine.
>> Other sites on other boxes in the same LAN work just fine though via the
>> first provider. The problem comes and goes now.
>> Really puzzled!
>>
>> Anyway, can't stop thinking about the ARP thing so I thought I would ask
>> here! Thank you very much!
>>
>> Regards
>> Markus
>>
>>
>>
>> ______________________________**_________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>> The contents of this message may contain confidential and/or privileged
>> subject matter. If this message has been received in error, please contact
>> the sender and delete all copies. Like other forms of communication,
>> e-mail communications may be vulnerable to interception by unauthorized
>> parties. If you do not wish us to communicate with you by e-mail, please
>> notify us at your earliest convenience. In the absence of such
>> notification, your consent is assumed. Should you choose to allow us to
>> communicate by e-mail, we will not take any additional security measures
>> (such as encryption) unless specifically requested.
>>
>>
>>
> ______________________________**_________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>
More information about the juniper-nsp
mailing list