Dropping packets using ping from PIX to LD

Discussion in 'Cisco' started by Benny Friedman, Sep 8, 2004.

  1. We have a strange problem on our production network.
    Our client is complaining about timing us out on about 7% of his
    requests.
    On the application there is no visible problem.

    A Cisco consultant says when he tries to ping from the PIX inside
    interface to a shared IP address on the Local Director he is dropping
    packets.
    Also he says the PIX inside interface MAC address changes back and
    forth from its real port to the LD outside interface port.

    We could not find any problem in the configurations of the PIX, LD or
    any of the switches. Cisco support team was no help either.

    We tried to replace the LD and the internal switch but nothing
    changed.
    Any idea what else can we do? It's quite hard to re-build the system
    from scratch since that's a live application.

    OutsideVLAN1->PIX 525->VLAN1->LD 430->VLAN2->servers
    Switches are Cisco 2900.

    There is another system (totally separated) on VLAN2 on the Outside
    switch.

    Thanks
    benny
     
    Benny Friedman, Sep 8, 2004
    #1
    1. Advertisements

  2. :We have a strange problem on our production network.

    :A Cisco consultant says when he tries to ping from the PIX inside
    :interface to a shared IP address on the Local Director he is dropping
    :packets.

    :Also he says the PIX inside interface MAC address changes back and
    :forth from its real port to the LD outside interface port.

    That second sentance doesn't make any sense to me. The PIX MAC
    address itself is changing?? Or the arp entry the PIX has for the LD's
    shared IP flops back and forth?


    Generally speaking, you cannot use a PIX in any situation in which
    incoming packets [e.g., reply packets] have a constant IP but a varying
    MAC. The PIX Adaptive Security Algorithm (ASA) will treat some of the
    packets as being spoofs and will drop them.

    I have never worked with LD or any other load balancer, but I have
    read that -sometimes- this can be gotten around by configuring
    the MAC addresses on all of the destination devices to be the same.
    But that depends on exactly how the load balancing works: this solution
    is only suitable for situations in which the multiple devices are
    communicating between themselves through some other path in order to
    decide between themselves which of the devices will respond to any
    particular packet that they all received a copy of. (Though it also
    works if all the devices process every packet and all reply, with
    the requesting host accepting the first response received and
    silently dropping the duplicate responses -- a scenario that probably
    works best with read-only databases.)
     
    Walter Roberson, Sep 9, 2004
    #2
    1. Advertisements

  3. Are there any other interfaces on the PIX? Is there a PIX interface
    connected to VLAN2?

    I might be wrong but....

    PIX is a layer 3 device. LD is a layer 2 device.

    L3->VLAN1->L2->VLAN2

    PIX will 'proxy arp' for both VLAN's, but the LD is a switch, so it will
    allow the mac addresses from VLAN1 to leak to VLAN2 & vis versa. PIX
    will see mac addresses on both VLANS.

    I'd go around and 'sho arp' and 'sho mac' on all the various devices and
    make sure that you are seeing the mac addresses on the correct
    switchports and LD and PIX interfaces. Then I'd make sure that logging
    is enabled on everything & I's check the logs for interesting error
    messages.

    When we had LD's we had the inside hosts on the same VLAN as the outside
    hosts.

    Can the LD be configured as an L3 device?

    --Mike
     
    Michael Janke, Sep 9, 2004
    #3
  4. If you do show ARP on the switch and get the physical address of the
    PIX, then do show MAC you get that the physical address is on
    FastEthernet0/1 which is correct. Then you do a second time show MAC
    and you get the same address on the same VLAN on FastEthernet0/2 which
    is the port of the LD outside interface.
    I am not doing anything like that.
     
    Benny Friedman, Sep 10, 2004
    #4
  5. No. No other interface on the PIX. No PIX connection to VLAN2.
    There is another PIX 525 connected to a different VLAN on the outside
    switch (not sure if that is significant)
    That's exactly where we see the problem. If I show MAC on the switch,
    I can see the port is changing from 1 to 2 and vice versa. I don't
    know how or who is changing it
    I'm not sure how can that be done?
    AFAIK you need to separate the 2 LD legs on different VLANs.
     
    Benny Friedman, Sep 10, 2004
    #5
  6. L3->VLAN1->L2->VLAN2
    ^ ^
    | |
    +----------+

    Is there ANY chance at all that you've got an extra connection bewteen
    the two VLAN's through some switch-like device?

    I'm thinking that VLAN1 MAC tables are getting corrupted via

    VLAN1->VLAN2->LD->VLAN1

    through some other connection/device.

    Then MAC's on VLAN1 would show up vi the LD outside interface.

    --Mike
    We ran an pair of LD 430 for a few years with both sides on the same
    VLAN. It worked.
     
    Michael Janke, Sep 10, 2004
    #6
  7. Benny Friedman

    Blair Wright Guest


    If you are running 2.2.1 code on your LD your going to lose icmp
    packets when attempting to ping a VIP, that is not a good test (the
    LD's are known for this). Get a sniffer and capture packets between
    the outside firewall interface and the LD and look for the drops.

    Remember that the LD is just a stupid layer 2 bridge, it only has an
    arp table and forwards packets from one int to another.. you cannot
    troubleshoot a complex system with ping bud, get a sniffer out there
    and you will figure it out. Also, consider dumping the "engineer" you
    hired, he is obviously not very good at what he does.
     
    Blair Wright, Sep 30, 2004
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.