Drops with 1711 (4ESW), policy route and vlans

dro · ‎07-02-2004

Hi folks,

I'm running into an odd problem involving a new 1711 and the built in WIC-4ESW. I've read some of the other threads on this subject, but mine seems to differ a little bit.

I have three separate networks in the same building, each with their own PIX and Internet connection, which connect via VPN to another office. I bought the 1711 to route between all three segments and am using policy routes to forward Internet traffic out the appropriate PIX/ADSL connection.

However, I keep getting hit by random packet loss between the different segments. Each port on the 4ESW is on a separate vlan, which is connected to an external switch for distribution out to the workstations (hp procurve).

Everything works as it should, if it wasn't for the randomly dropped packets. The interface counters show the drops and a show ip traffic shows them listed as encapsulation errors.

I had disabled CEF based on some previous posts to try and correct the problem, but it's still occurring. I haven't been able to reproduce the problem in a test environment, but it happens when I try to deploy in production (of course though, I don't have anywhere near the same amount of hosts to test with in the lab compared to production).

Any ideas? The 1711 is running 12.3(7).T2.

Segment one is 172.16.203.0/26.

Segment two is 172.16.203.128/26.

Segment three is 172.16.205.0/26.

The 1711 is the first usable IP in each segment and the PIX is the second.

172.16.8.0/22 is sent over the VPN tunnels. Listed below is the relevant configuration:

interface FastEthernet1

switchport access vlan 10

no ip address

no cdp enable

!

interface FastEthernet2

switchport access vlan 20

no ip address

no cdp enable

!

interface FastEthernet3

switchport access vlan 30

no ip address

no cdp enable

!

interface Vlan10

ip address 172.16.203.1 255.255.255.128

ip policy route-map SEG1

ip route-cache policy

!

interface Vlan20

ip address 172.16.203.128 255.255.255.128

ip policy route-map SEG2

ip route-cache policy

!

interface Vlan30

ip address 172.16.205.1 255.255.255.128

ip policy route-map SEG3

ip route-cache policy

!

ip route 0.0.0.0 0.0.0.0 172.16.203.2

ip route 172.16.0.0 255.240.0.0 Null0 5

ip route 172.16.8.0 255.255.252.0 172.16.203.2

access-list 110 deny ip 172.16.203.0 0.0.0.127 172.16.203.128 0.0.0.127

access-list 110 deny ip 172.16.203.0 0.0.0.127 172.16.205.0 0.0.0.127

access-list 110 permit ip 172.16.203.0 0.0.0.127 any

access-list 120 deny ip 172.16.203.128 0.0.0.127 172.16.203.0 0.0.0.127

access-list 120 deny ip 172.16.203.128 0.0.0.127 172.16.205.0 0.0.0.127

access-list 120 permit ip 172.16.203.128 0.0.0.127 any

access-list 130 deny ip 172.16.205.0 0.0.0.127 172.16.203.0 0.0.0.255

access-list 130 permit ip 172.16.205.0 0.0.0.127 any

!

route-map SEG1 permit 10

match ip address 110

set ip next-hop 172.16.203.2

!

route-map SEG2 permit 10

match ip address 120

set ip next-hop 172.16.203.130

!

route-map SEG3 permit 10

match ip address 130

set ip next-hop 172.16.205.2

!

Regards,

-Joshua

Georg Pauwen · ‎07-02-2004

Hello Joshua,

I guess you are referring to the ´drops: encapsulation failed´ counter ? This counter increases every time the router receives an ARP request for which it has no entry. Turn on ´debug arp´ and look for entries that look like this:

1w2d: IP ARP: creating incomplete entry for IP address: 135.13.20.1 interface Ethernet0

At the same time, when you do a ´show arp´ you should briefly see an incomplete entry in the router´s ARP table:

Protocol Address Age (min) Hardware Addr Type Interface

Internet 135.13.20.2 - 0050.5498.ef35 ARPA Ethernet0

Try to find out which address is being ARPed and why it is unreachable, it might be a routing protocol...

HTH,

Georg

dro · ‎07-03-2004

I didn't see anything out of the ordinary in the last show arp I did before my client turned off the router. The encapsulation errors might be unrelated to the problem at hand though.

During our tests, users who were working fine without an issue would start to have random problems reaching hosts that were already known (and in the arp table). If I did a ping with large numbers of packets from and to devices on different switch ports, it appears to have bursts of packet loss.

-Joshua