SRX

Hi All,

 

We recently installed 4 Juniper SRX240 at 4 different sites. Of these, 2 of 4 are complaining (other 2 aren't complaining?) of an error message on some of the end devices (all Windows XP). We enabled gratuitous arp on the inside interface and it fixed for some of the devices but not all. This is not an issue (as there is no conflict and the error pop-up can just be closed) but more of an inconvenience and a curiosity for me as I am trying to figure out why. I ran the show log messages command and could not find an IP address conflict. My thought here is that I might have to turn off garp on the devices but am hoping to figure this out as it was working fine before switching. We refreshed a Cisco 2811 and the only thing that has changed is the router (now SRX240).

 

Thanks,

 

Justin

sounds like multiple dhcp servers on your lan or the dhcp scope is overlapping statically assigned hosts

 

maybe the srx you installed hasnt had dhcp disabled?

 

show system services dhcp binding

We use Infoblox for DHCP and that hasn't changed. The DHCP requests are pointed to the IP of the Infoblox server.

Anyone care to take a stab?

Hi,

 

Looks like something rogue is giving out DHCP, are you sure DHCP is turned off on the SRX?

 

You should try and run a capture on the network segment in discussion, open it with Wireshark or whaetver and filter on arp maybe and see if another MAC is claiming to be something it isnt, it should point you in the right direction.

I agree with performing a capture, however,  wouldn't a "KERN_ARP_DUPLICATE_ADDR" or "KERN_ARP_ADDR_CHANGE" show up in the log regardless of which DHCP server was handing the DHCP requests.

 

I may shut off DHCP on the router just to test if a rogue DHCP server exists. I don't believe it does but I can't prove it doesn't either.

 

I do have a capture of the site that I performed while rebooting one of the machines in question but the error did not show up after the reboot which leads me to believe that I should have waited for the ARP table to timeout.

You are right, there would usually be "KERN_ARP_DUPLICATE_ADDR" or "KERN_ARP_ADDR_CHANGE" on the SRX itself.  It is a weird problem for sure.

 

I would still go for the network capture, leave it running until the issue reappears and then have a look, at least if you see no "duplicate use of IP detected" when looking in Wireshark or whatever after the issue appears, you can probably rule out duplicate IPs actually in use on the network.

 

If this is the case, as to why the clients are presenting the error may be something else to look into.

Check if you have any proxy-arp configuration, that might be responding to garp when the PC comes online.

proxy-arp woul de be present under securty nat hierrarchy.

Also check for conflicting or overlapping dhcp config.

 

C_R

The issue comes up for some machines when rebooting but only if the machine has been off for a while. This is my local interface.

 

interfaces {
    ge-0/0/0 {
        description "Local Subnet";
        gratuitous-arp-reply;
        unit 0 {
            proxy-arp;
            family inet {
                address 10.50.183.20/24;

set interfaces ge-0/0/0 unit 0 proxy-arp

 

 I'm thinking that the abouve could be the culprit and is not needed since it is already set in the statement below . Going to site today to shut off this and test after site closes today.

 

set security nat proxy-arp interface ge-0/0/0.0 address 10.50.186.5/32

Hi,

 

That is the culprit more than likely.  The question is, why have you proxy arp set on the interface?  I assume that setting it here will proxy the ARP requests for the 10.50.183.20/24 range. 

 

 

 

I'm thinking it is because we have a static NAT:

 

 

Although I can't quite explain why proxy arp would be replying for a gratuitous arp that is initiated by the machine booting.

Have a read below, it looks like you have unrestricted proxy-arp configured on the interface. I would remove the proxy-arp configured under the interface unless it is serving some purpose.

I am not sure what you are trying to accomplish with it really.

http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/configuration-statement/proxy-arp-edit-interfaces.html

Removed proxy-arp and it fixed the situation.

 

It sounds like we have this implemented due to the static nat though there is a proxy-arp statement in the nat statement so I'm not sure why it is there on the interface as well.

 

It is now configured like this article recommends:

 

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21785

 

Thanks for your help MMcD.

Well that didn't go well.

 

Removing ARP worked for the workstations on the 10.50.183.x subnet. No ip conflict messages.

 

That did not work for the static NAT configuration. I tried adding restricted to the proxy arp configuration for the inside interface of the local subnet and the static nat would not pass traffic. I also tried this for the DMZ interface and no go as well.

 

Hi,

 

Sorry to hear that.  I have read back through the comments and I am not exactly sure what you are trying to accomplish with the overall design.  Maybe provide a basic diagram and explain what this static NAT is for, also post your configuration too and I and others can have a look as to why its not working.

The static NAT is for our MRI machine. If I disable proxy arp unrestricted the machines no longer get an IP conflict. However, removing the proxy arp statement from ge0/0/0 breaks the MRI static nat as the proxy arp no longer works, it seems.

 

 

Also here is a synapsis of the steps thus far:

 

1) I can unplug the machine and there is no conflict (no ICMP reply when testing from another device). This is happening to all devices and a capture has showed this behavior.
2) The capture shows that the router (via proxy arp unrestricted) is replying to the Dell worksation (static IP) when the workstation boots. This is normal behavior for proxy arp unrestricted however this configuration is causing an important modality to shut its NIC off upon booting (they have to unplug it from jack when booting).  When I turn it off proxy arp unrestricted the "conflict" goes away. I've tested this behavior.
3) Removing proxy arp unrestricted from the ge-0/0/0 unit 0 interface breaks the static NAT for the MRI trailer. I tried adding proxy arp restricted to the ge-0/0/0 unit 0 interface and the NAT was still broken. I believe that this could be because the ARP requests are coming from the NAT address and not the IP of the MRI interface (ge-0/0/2).
4) I tried adding proxy arp unrestricted to the ge-0/0/2 interface but it did not resolve the issue.
5) The arp table does not show an IP conflict nor does the router logs. If there was truly a conflict a "KERN_ARP_DUPLICATE_ADDR" or "KERN_ARP_ADDR_CHANGE" show up in the log.

Hi,

Had a quick look through that and something that stands out is this:

set security nat proxy-arp interface ge-0/0/0.0 address 10.50.186.5/32

Should this not be 10.50.183.5? That's what's defined if your static NAT.

I think the reason your unrestricted proxy arp fixes it is because it answers for any arp request. Remove it again and try the above.

Ugh. If thats all it is I am both happy and disappointed.  I will correct and test tomorrow.

That corrected it. How frustrating that I couldn't see the typo.

 

Proxy-arp on the ge-0/0/0 interface is what was making the static nat arp work. Removing it broke the static nat as the arp statement had a typo.

Good news! It happens a lot and this was a bit unique I guess! Good luck with it!