Forum Discussion

portoalegre's avatar
portoalegre
Icon for Nimbostratus rankNimbostratus
Oct 10, 2011

ICMP replies

I have configured a VS for my real server/pool network so users/servers can connect to my pool server network directly:

 

 

virtual Inbound-server-vlan137 {

 

ip forward

 

destination 10.210.137.0:0any

 

mask 255.255.255.0

 

vlans external enable

 

}

 

 

self 10.210.137.10

 

netmask 255.255.255.0

 

vlan vlan137

 

allow all

 

 

The problem I have is that we have about 10 hosts behind this network and they all respond to ping, however looks like the whole subnet replies to ping. The F5 is sending the ICMP reply, but the host doesn't exist on this subnet, I would like to stop this. This isn't ideal, I want the server not the F5 to reply for obvious reasons.

 

 

Thanks,

 

 

 

 

 

 

config
design

8 Replies

Sort By
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Oct 10, 2011
    it seems not possible.

     

     

    http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/39/aft/1173012/showtab/groupforums/Default.aspx

     

    http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/39/aft/34621/showtab/groupforums/Default.aspx
  • portoalegre's avatar
    portoalegre
    Icon for Nimbostratus rankNimbostratus
    Oct 10, 2011
    I can understand a filter would be useful to secure your network on a DMZ, however with F5's providing load balancing on your internal network I don't seem this as a major requirement especially when servers behind the F5 connect to databases, monitoring servers etc on other internal networks....administration overhead.

     

     

    Currently have a problem - we need to build new Unix servers on a pool network behind the F5 the boot build server which sits on a seperate network not behind the F5 sends out a ping to see if anyone has the new address allocated, if the ICMP reply is received (in my case the F5 sends back ICMP reply) you cannot build the server, because the the specific boot server thinks the IP is already taken.

     

     

  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Oct 10, 2011
    Currently have a problem - we need to build new Unix servers on a pool network behind the F5 the boot build server which sits on a seperate network not behind the F5 sends out a ping to see if anyone has the new address allocated, if the ICMP reply is received (in my case the F5 sends back ICMP reply) you cannot build the server, because the the specific boot server thinks the IP is already taken. just wondering if dropping icmp reply using packet filter is helpful (i know it is not a fix actually).
  • portoalegre's avatar
    portoalegre
    Icon for Nimbostratus rankNimbostratus
    Oct 11, 2011
    That would be helpful, a part from the fact that some of our monitoring applications use ICMP heartbeats to monitor servers behind the F5. So this would need to be implemented after hours which isn't ideal.

     

     

    This is a real problem and should be looked at by F5 Developers, ICMP is a protocol that is used for many purposes and the F5 LTM should not repsond in this manner, other devices like Cisco ACE do not!

     

     

     

     

     

  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Oct 11, 2011
    This is a real problem and should be looked at by F5 Developers, ICMP is a protocol that is used for many purposes and the F5 LTM should not repsond in this manner, other devices like Cisco ACE do not!to let them know, please open a support ticket and submit request for enhancement.

     

     

    cheer!
  • portoalegre's avatar
    portoalegre
    Icon for Nimbostratus rankNimbostratus
    Oct 20, 2011
    problem resolved. I disabled the ARP from the Virtual address, once applied the F5 no longer replied to pings. Physical servers now send the ICMP reply.

     

     

    config with problem

     

     

    virtual address 10.210.137.0 {

     

    arp enable

     

    mask 255.255.255.0

     

    }

     

     

    after change arp removed, problem solved.

     

     

    virtual address 10.210.137.0 {

     

    mask 255.255.255.0

     

    }