Alcatel anybody?


Can anybody tell me how do I reduce the xlate timeout period?

I want my xlat table to flush all entries every 30 minutes.
LVL 11
Who is Participating?

Improve company productivity with a Business Account.Sign Up

PennGwynConnect With a Mentor Commented:
I know of three ways that can give this kind of effect:

1.  La Brea
  This is a tool to slow down the spread of worms that scan a whole address range.  It will "populate" vacant addresses by responding to ARP requests that repeat (i.e., *apparently* were unanswered).  Anybody running such a tool on your network?  Only authorized admins who understand what they're doing should be.

2.  Ettercap, or similar "ARP poisoning" tools
  These allow a switched network to be sniffed, by corrupting the switch ARP tables to redirect traffic of interest to a monitoring port without requiring admin access to the switch.  Nobody should be authorized to do this on a production network and keep their job....

3.  Proxy ARP
  A router may be configured to believe that it is the gateway between the network where it saw an ARP request, and the network where the destination is located.  If these are the same network, something's misconfigured or misconnected.

I don't know of a way to do that, but I'll look into it.

You haven't described what problem you're trying to solve, but I suspect that what you *really* need to flush is the CAM table.  There are two parameters associated with that -- one sets the interval length (default 30 seconds) and one sets the number of intervals an entry lives unused (default 6).  Tuning those parameters can greatly improve the OSR's performance when a worm scans your entire net block.

billwhartonAuthor Commented:
I think you are right.

What would be best is if you could tell me what is the CAM table and what is the XLAT table?

I am from the cisco world and know very little of Alcatel. I have also started to apply my cisco knowledge to Alcatel because terms like the CAM table, etc are used in a completely different way.

So, a description of these two tables would help like crazy!


Could you mail me at bill_wharton AT
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

I've emailed you.
billwhartonAuthor Commented:
I am pasting your email in here for readers to benefit from your beautiful answer.

  The xlat table is Alcatel's name for the ARP table, and holds cached mappings of IP addresses to MAC addresses.  I'd like to say that destinations which don't answer ARP requests don't even get added to the table, but in fact they show in xlat display as "incomplete", so the fact that they didn't answer has also been cached.

  CAM is Content-Addressable Memory; it's used for fast table lookups.  Cisco switches use CAM to map MAC addresses to ports, and Cisco uses TCAM (Ternary (base 3!) CAM) for compiled ACLs.
  The hdstat command includes a couple of lines for CAM table usage.  When the OSR routes a packet to a destination, it caches the route decision in CAM so it can do quick lookup on subsequent packets.  (This is sort of like the hardware "routing" that Cisco multi-layer switches do, such as the 35xx series.)

  One of our recurring problems with OSRs has been that the CAM entries are per single unique IP address.  Several worms of the past year or so would scan our entire Class B block faster than entries would age out of CAM.
  The OSR doesn't handle CAM being full well.  As far as we could determine, if it has an entry to be inserted and the CAM is full, it goes into a hard loop where no traffic passes until a CAM entry ages out so the insertion can be completed.  OUCH.

  So, per an engineer at Alcatel:

> The route_cache_timer can be utilized in dshell or in the .cmd file
> for permanent use-
> This timer is set to 30 seconds by default and can be manipulated with
> the "route_cache_timer" command. If the "route_cache_timer" command is
> executed without any variables, the value will read 1800 which is in
> ticks 1800/60 Ticks per sec=30 seconds.
> When an entry gets made, the entry is assigned a value of 6. Every 30
> Seconds the router cache algorithm is executed and will check the entry.
> If the entry has not been used, the value decrements by one. For this
> reason, an entry that has not been used, will age out in three minutes.
> 30 Secs. X 6=180/60=3 Minutes.
> The timer or frequency the algorithm runs can be manipulated by
> lowering the "route_cache_timer" value.
> Example
>   route_cache_timer=90  (9 seconds)
>   route_cache_timer=180 (18 seconds)
>   route_cache_timer=1800 (default is 180 seconds or 3 minutes)

> The other way you could change it is by lowering the # of ticks used.
> The default for cache entries is 6.
> Default timeout 3 minutes (30*6)
> This value can be changed (1-255) globally in the HREX to shorten the
> timeout.
> To change it from 6 to 3 ticks (90 seconds) put this in the mpx.cmd
> file and reboot
>   hreXtagval=3
> This command should not be issued in dshell, just put in the .cmd file.

David Gillett (PennGwyn)

billwhartonAuthor Commented:
I kept a description of my problem because I wanted an answer to the above first.
This is my environment:

LAN Network
Alcatel Omni switch ---T1--- Alcatel Core Omni Switch --- PIX Firewall --- 1601 Router (T1 link)

One of my IP addresses on the LAN Network suddenly goes bad. This network is using static addresses. Suddenly this IP address cannot accesss a handful of websites. I found out that it's not a DNS resolution problem. I also connected my laptop with the same IP address to rule out a client-side problem.
The problem is resolved when I flush out the xlat entries at the Core switch (refer to above diagram if I can call it that)

Now, it cannot be something to do with IP-ARP translation since the Core switch does not know the MAC addresses for the LAN network. However, the problem WAS resolved when I flushed out the xlat entries.

Also, the xlat timer defined by arpToKill in the dshell has a default of 5 minutes but my problem stays for 2-3 days before the bad IP suddenly turns good.

I am quite confused about this but I want to leverage the fact that when I did a flush->xlat using the Alcatel's menu options, the problem went away.

What can that possibly mean?
Are there any 802.1Q trunks present?  Are you using group mobility?

We spent much of last fall chasing an issue where switches (and clients on them) that were across a trunk from the core would fail to see ARP replies, and so cache the destination in xlat as not responding.  This meant that the destination was unreachable from devices on that switch.  (It turned out that broken group mobility was causing an ARP reply to be seen on the wrong VLAN, and not seen where it was needed.)

As a good diagnostic, removing one VLAN from the trunk and re-adding it would clear the problem.

The ultimate fix included some combination of turning off group mobility, and rebuilding all of our trunks to use Multiple Spanning-Tree.

(In our case, the failed ARP was usually trying to get a next-hop address for the core router, so whenever it happened we would find that all of the clients on some switch were unable to connect outside their own VLAN.)

billwhartonAuthor Commented:
No 802.1Q trunks present. I noticed another wierd thing on my switch today. Look at the ipmac table underneath. First of all, the computer does not have a mac address of 0002A5:2332DC

Also, this MAC address appears in other places such as x.x.1.79 & x.x.2.22

Enter command (Add/Delete/Show/Flush/Macfind/Ipfind/Quit) (Show) : quit
ADO-Main-A /Networking/IP ->ipmac


     IP Address         MAC Address   Slot / Intf
    10.  6.  0.  2     00D095:247EC4     1 / 1
    10.104.  0.  1     00D095:247EC3     1 / 1
    10.104.  0.200     00508B:F38F30     3 / 2
    10.104.  1. 26     0050BF:908F14     5 / 7
    10.104.  1. 79     0002A5:2332DC     5 / 7
    10.104.  1.100     000BCD:AEB2D9     5 / 7
    10.104.  1.163     000BCD:E169B1     5 / 7
    10.104.  2.  3     0002A5:FAA219     5 / 7
    10.104.  2. 22     0002A5:2332DC     5 / 7
    10.104.  2.225     0002A5:2332DC     5 / 7
       *******         000BCD:E169B1     5 / 7
    10.204.  0.200     00508B:B377EC     3 / 1
   192.168.  5.  1     00D095:247EC0     1 / 1

ADO-Main-A /Networking/IP ->
billwhartonAuthor Commented:
Wouldn't the switch tables show something if any of these tools are running? I think they would.

Also, it's more than layer 2. It's actually layer 3 since this problem occurs only with one source and one destination across a T1 line. The source can continue to access another workstation in the destination' subnet.

I had guys from alcatel come over yesterday and they upgraded the code for me but weren't able to figure out the problem.

Penn, you still deserve the points though for inputting all this extra information for me which I have learned from.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.