02-05-2016 04:41 AM - edited 03-08-2019 04:29 AM
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
Solved! Go to Solution.
02-17-2016 07:47 AM
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.
02-17-2016 08:09 AM
Glad you got it sorted :)
02-08-2016 12:34 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide