cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
731
Views
0
Helpful
4
Replies

Strange behaviour with FWSM - although I doon't think it is a FWSM issue

astanislaus
Level 2
Level 2

From the attached config I cannot explain why a system with IP address 10.7.1.35/28 for example would loose packets to a system with IP address 10.7.1.36/28 which are in the same subnet. This is just an example. More systems on 10.7.1.32/28 subnet loose packets to other systems in the same subnet.

 

No packet loss occurs when any system in 10.7.1.32/28 subet talks to systems in other subnets.

 

My customer is saying that the problem is due to FWSM. He is almost sure that if he removes this VLAN 70 from the FWSM, then the fault will go away.

 

I said what has the FWSM got to do with this because we are talking of packet loss between systems on the same subnet 10.7.1.32/28

 

Any suggestions?

 

 

 

 

 

 

4 Replies 4

astanislaus
Level 2
Level 2

We have three hosts on network 10.7.1.32/28

The FWSM is 33

MX-ps1 is 35

MX-av is 37

test is 38

We are randomly getting packet loss, it may run for hours then just stop but the problem occurs more if the hosts are not communicating then want to communicate.

This made me look at the arp tables of teh hosts and I found some interesting results

Host 10.7.1.37

===============

Interface: 10.7.1.37 on Interface 0x3000004

Internet Address Physical Address Type

10.7.1.35 00-0f-1f-69-7c-a5 dynamic

10.7.1.38 00-0e-0c-64-0b-34 dynamic

Host 10.7.1.38

===============

Interface: 10.7.1.38 --- 0x30003

Internet Address Physical Address Type

10.7.1.33 00-17-94-3a-ec-80 dynamic

10.7.1.35 00-0f-1f-69-7c-a5 dynamic

10.7.1.37 00-c0-9f-3e-75-3f dynamic

Host 10.7.1.35

===============

Interface: 10.7.1.35 --- 0x10003

Internet Address Physical Address Type

10.7.1.33 00-17-94-3a-ec-80 dynamic

10.7.1.37 00-17-94-3a-ec-80 dynamic

10.7.1.38 00-17-94-3a-ec-80 dynamic

This appears to me that 10.7.1.35 thinks it is on a different subnet to 37 and 38 so it has the routers Mac address. This probably explains the cause but not the solution.

I have checked the switch and the host subnet masks and they are correct.

Here is something interesting, the arp tables I posted in the previous reply has changed within about 5 minute and the arp entries are now good.

I just looked at .35's arp table again and it has changed as explained below:

Arp table posted in previous reply and repeated again here:

============================================

Interface: 10.7.1.35 --- 0x10003

Internet Address Physical Address Type

10.7.1.33 00-17-94-3a-ec-80 dynamic

10.7.1.37 00-17-94-3a-ec-80 dynamic

10.7.1.38 00-17-94-3a-ec-80 dynamic

C:\Documents and Settings\Administrator>arp -a

arp table when everything magically started to work without anyone doing anything:

=============================================

Interface: 10.7.1.35 --- 0x10003

Internet Address Physical Address Type

10.7.1.33 00-17-94-3a-ec-80 dynamic

10.7.1.37 00-c0-9f-3e-75-3f dynamic

10.7.1.38 00-0e-0c-64-0b-34 dynamic

More Info

I have done a packet capture on one of the hosts and what is happening is this

10.7.1.38 arps for the mac address of 10.7.1.37

10.7.1.37 relpies with its correct mac address

10.7.1.33 (The router) also replies saying that 10.7.1.38's mac address is the routers Mac address

FWSM partial config (full config in main entry that I made):

---------------------------------------------

I think I know what the problem is.

Looking at your FWSM config (posted before) especially the following lines:

interface Vlan70

nameif dmz1

security-level 5

ip address 10.7.1.33 255.255.255.240 standby 10.7.1.34

!

interface Vlan71

nameif asa-dmz

security-level 0

ip address 10.7.1.41 255.255.255.248 standby 10.7.1.42

The above config is illegal because subnet 10.7.1.32 / 28 is as follows:

10.7.1.32 / 28 is subnet address

10.7.1.47 / 28 is the broadcast address for this subnet.

First host address for this subnet will be 10.7.1.33

Last host address for this subnet will be 10.7.1.46 which is greater than the host address of 10.7.1.41 allocated to FWSM Vlan71 and hence there is an overlap leading to the behaviour we are seeing

Review Cisco Networking for a $25 gift card