cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4340
Views
0
Helpful
17
Replies

LAN Crashes

Hi to everyone,

I would like to share with you a problem that I'm facing nowadays in our showroom network. The architecture is really simple no segmentation and one VLAN:

FTTH Alcatel Lucent router plays role of modem.

Cisco 887VA router connected to above alcatel.

HP Switch manageable 10/100 connected to the cisco port FA3

TPLINK Switch 10/100/1000 connected to the HP Switch in 10/100 port.

Dlink 10/100 Switch connected to TPLINK switch.

3 access point TPLINK in the whole house.

HP Switch has 5 devices.

TPLINK Switch almost 20 devices.

Dlink Switch has 7 Devices.

Finally the users' devices (phones, iPad ...)

The main problem we have is after certain period of time the network seems not responding anymore, no internet no communication inside the LAN. We saw each time that all the LED switches blink at the same time. I tried to get info from cisco router to have an idea what causing this and the result of "sh processes cpu sorted" shows me "IP NAT AGER" has 99%/0%. Sometimes I saw that "IGMP Snooping RE" and "IGMPSN"  consume 35% to 40% of cisco resources. So I disabled the IGMP snooping and I don't know if it is healthy for the network or not ?

I'm trying to figure out what is the best way to find out who's causing this: Is worm ? is a specific protocol ? IP fragmentation ?  ....

Just for information this network is used for home entertainment solutions like (Lighting control, Media control ...) and these devices need to be in the same segment of the network to be able to communicate with users applications. The idea of making VLANS seems tricky to me because I'm thinking should I forward broadcasts to another VLANS is the same thing if everything is in the same segment or not and if it is a bad or good way of doing things ...

I have some skills in networking but not really experienced in network analysis and network crash. I'm really confused and I need your recommendations and your expertise, bearing in mind that the most of the equipment will need broadcast to communication with the end users.

This is my cisco router config:

Router>en
Password:
Router#sh run
Building configuration...

Current configuration : 3382 bytes
!
! Last configuration change at 11:50:07 UTC Fri Feb 5 2016
version 15.3
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
no logging console
no logging monitor
!
no aaa new-model
!
!
no ip source-route
ip options drop
!
!
!
!


!
ip dhcp excluded-address 192.168.1.1 192.168.1.50
ip dhcp excluded-address 192.168.2.1 192.168.2.50
ip dhcp excluded-address 192.168.3.1 192.168.3.50
ip dhcp excluded-address 192.168.1.254
!
ip dhcp pool USERS
 import all
 network 192.168.1.0 255.255.255.0
 default-router 192.168.1.1
 dns-server 8.8.8.8 8.8.4.4
!
ip dhcp pool SAVANT
 import all
 network 192.168.2.0 255.255.255.0
 dns-server 8.8.8.8 8.8.4.4
 default-router 192.168.2.1
!
ip dhcp pool SONOS
 import all
 network 192.168.3.0 255.255.255.0
 default-router 192.168.3.1
 dns-server 8.8.8.8 8.8.4.4
!
!
!
no ip domain lookup
ip cef
no ip igmp snooping
no ipv6 cef
!
!
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
license udi pid C887VA-K9 sn FCZ191471DA
!
!
!
!
!
!
!
controller VDSL 0
!
!
!
!
!
!
!
!
!
!
!
interface ATM0
 no ip address
 shutdown
 no atm ilmi-keepalive
!
interface Ethernet0
 no ip address
 shutdown
!
interface FastEthernet0
 no ip address
!
interface FastEthernet1
 switchport access vlan 999
 no ip address
!
interface FastEthernet2
 switchport access vlan 3
 no ip address
!
interface FastEthernet3
 no ip address
 storm-control broadcast level 40.00
 storm-control multicast level 40.00
!
interface Vlan1
 ip address 192.168.1.1 255.255.255.0
 ip flow ingress
 ip nat inside
 ip virtual-reassembly in
 ip policy route-map CLEAR_DF
!
interface Vlan2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
!
interface Vlan3
 ip address 192.168.3.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
!
interface Vlan999
 no ip address
 ip virtual-reassembly in
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface Dialer1
 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in max-fragments 64 max-reassemblies 1024
 encapsulation ppp
 dialer pool 1
 ppp authentication chap pap callin
 ppp chap hostname xxx
 ppp chap password 7 xxx
 ppp pap sent-username xxx password 7 xxx
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip nat translation tcp-timeout 300
ip nat translation udp-timeout 600
ip nat translation max-entries 200
ip nat inside source list FTTH_WAN interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip access-list extended FTTH_WAN
 permit ip host 0.0.0.0 any
 permit ip 192.168.1.0 0.0.0.255 any
!
!
route-map CLEAR_DF permit 10
 match ip address TCP
 set ip df 0
!
!
control-plane
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
!
!
line con 0
 password 7 xxxx
 login
 no modem enable
line aux 0
line vty 0 4
 password 7 xxx
 login
 transport input all
!
scheduler allocate 20000 1000
!
end

17 Replies 17

Hi Folks,

I thank you guys for your effort to diagnose with me this problem. We could solve that problem by changing TP-Link Switch  by a catalyst 2969. I was very impressed by the strengh of these switches it helps a lot when you have good equipment.

It's a week now since we installed the switch. The traffic is normal. I didn't notice any high CPU. So, it seems OK.

Thank you guys.

Glad you got it sorted :)

Unmanageable switches make some things difficult.  In a mostly-Cisco environment we used to have similar issues, and and enabled bpdu detection on all client (meeting room) ports.  If you saw a BPDU inbound, the port would get shut down; as used to occasionally happen in meeting rooms where hubs were used and users "cabled creatively" i.e. linked a port back to itself.  Not really a spanning tree issue; but it would confuse an entire network segment until located. 

With BPDU detection, the only problem is periodically re-enabling ports that would otherwise cause mysterious outages.