6509 Native IOS and CEF ISSUE

[czj7l9]

My problem is this:

On my 6509 native IOS 12.1(11r)E1 when a source host try to reach 2 destination hosts that are on the same subnet the fisrt host is reached ok, and the other host not.When I invoke the traceroute command I see that the 2 routes are different. I have only a static route for the subnet.To solve the problem I've put a specific route to the host. A strong thing is that when I make "sh mls cef " command I see 8 adjacencies to reach this subnet.Why?

[robho]

The first hop router where you execute show ip route x.x.x.x should show the next-hop for the subnet and not the exact host (unless you specfied it otherwise). The sup should use the same hop unless it is running a routing protocol where you have dual next-hop routers for the same subnet. If that is the case, the switch may do per-destination load-balancing (not per-packet load-balancing).

If you are positive that the routing entries are ok along the path, take a sniffer trace on the bad host to make sure that received the packet first. This way, you can isolate and determine if the return path is the issue.

RH

[czj7l9]

Hi Robho, in attachments you'll find my net Layout.There's only a path to reach Y.Y.23.63-70 , but the issue is that with "ip route Y.Y.23.0/24 Y.Y.94.94" is impossible to reach the host Y.Y.23.70, while other hosts in this subnet are reacheble.The solution is to insert the exact route matching the destination host. With traceroute Y.Y.23.70 it loops between "pix-a" and 6509.when I invoke "sh mls cef" command , I see that the first mac in the adj is correct , and the other 7 mac(??) adj following the right mac-address are wrong. When the traceroute is wrong, it uses the second mac-address.Heres my mls cef adj output:

6403 172.22.23.0 255.255.255.0 000a.b788.1b0f*right adj. all the other are wrong! 0000.d1f0.175e 0010.1803.4deb 0010.1803.502b 0030.6e37.1888 0005.3201.b4c1 0003.fed0.2039 0003.fed0.2c39 0800.20ff.f049 0000.0c07.ac01 0005.3201.b4c1

[subbarao.s]

Hi,

May be you sould look at the PFC2 level entries as well, because forwarding is done at hardwdare level. The command output from MSFC2 should be compared with the output from the PFC2.

Can you post the log for below?

from main (MSFC2)consloe,

show ip route Y.Y.23.70

show ip cef Y.Y.23.70 detail

show adjacency detail

show arp

then you switch to SP by below command,

6500-Native# remote login switch

With the above command you are taken in to SP. Here you execute the below

show ip cef Y.Y.23.70 detail

show mls cef adjacency

show mls cef Y.Y.23.70

You take log for both OK and not-OK ip addresses of the destination segment.

[robho]

What happens when you bypass pix-a and source the ping from the switch itself? Send a regular ping first and then an extended ping but sourced from another interface (other than the vlan/routed egress interface). This test will force a sw lookup in one direction (from source to destination) and bypass the cef entries in hw. Then, connect a host directly to the switch and source the ping from there.

Also, have you tried sniffing the end device to see if the the frame actually got there? This will help you isolate the direction of the packet loss.

RH

[czj7l9]

hi robho, in this moment is not possible reproduce the problem , because the server are in production.

To bypass the problem i had iserted in both interfaces a access-list (access-list 3 permit any log ) for bypass a cef.

thanks