10-20-2015 07:35 AM - edited 03-08-2019 02:17 AM
Hello,
We have implemented a link between two Cisco 3825 routers (R1 and R2) as follows:
R1 - Sw1 [trunk port] - Ub1 - Ub2 - Ub3 - Ub4 - Sw2 [trunk port] - R2 .1 .2 .3 .4 .5 .6
There is a management VLAN (#7) with subnet 10.201.2.0/24 (see specific addresses above).
The wireless devices (Ub1 - Ub4) are Ubiquiti PowerBridge M5.
Their configuration is as follows: http://iweb.noa.gr/files/ubnt-m5-20150420a.png.
(Some months ago I had started this thread, when setting things up: https://supportforums.cisco.com/discussion/12477986/using-different-native-vlans-different-ports-switch-configured-trunks)
.2 and .3 use as gateway the .1 side (R1) and the .4 and .5 use as gateway the .6 side (R2).
There is also a p2p VLAN (#8) using 172.16.1.17/30 (R1) and 172.16.1.18/30 (R2).
Native VLAN is the default (#1).
The P2P VLAN is being used for OSPF / BGP.
This setup has been working fine until recently. At some point the link went down, and we cannot access any of the wireless devices from either side!
We have noticed that if we reset any of the end Ub devices (e.g. .2) we can access it for a short while, right after the reset, and then we lose access permanently.
Can you please advise on how to proceed with resolving this situation? Any ideas/suggestions will be greatly appreciated!
The router interfaces:
R1: interface GigabitEthernet0/0.7 encapsulation dot1Q 7 ip address 10.201.2.1 255.255.255.0 ip flow ingress ip nat inside no ip virtual-reassembly ip policy route-map udp-df0 ! interface GigabitEthernet0/0.8 encapsulation dot1Q 8 ip address 172.16.1.17 255.255.255.252 ip flow ingress ip nat outside ip virtual-reassembly ip ospf message-digest-key 10 md5 7 xxxxxxxxxxxxx ip ospf network point-to-point ip ospf cost 10 shutdown ipv6 address 2001:648:2011:101:xxxx::xxxxx/64 ipv6 enable ipv6 ospf network point-to-point ipv6 ospf cost 10 ipv6 ospf 125 area 0 ipv6 ospf authentication ipsec spi 256 sha1 7 xxxxxxxxxxxx ipv6 flow monitor IPv6_cisco1 input crypto map vpn R2: interface FastEthernet2/0.7 encapsulation dot1Q 7 ip address 10.201.2.6 255.255.255.0 ip flow ingress ip nat inside ip virtual-reassembly ! interface FastEthernet2/0.8 encapsulation dot1Q 8 ip address 172.16.1.18 255.255.255.252 ip flow ingress ip nat outside ip virtual-reassembly ip ospf message-digest-key 10 md5 7 xxxxxxxxxxxxxxxx ip ospf network point-to-point ip ospf cost 10 ipv6 address 2001:648:2011:101::2/64 ipv6 enable ipv6 ospf network point-to-point ipv6 ospf cost 10 ipv6 ospf 125 area 0 ipv6 flow monitor IPv6_cisco2 input crypto map vpn
(Note that the "ipv6 ospf authentication" directive is missing from R2, because after experimentation, where we changed the router interface, the directive has not yet been accepted by the router.)
Notes:
1. We have tried disabling STP on vlans 7 and 8, without any change in behavior (normal port status: Forwarding).
2. ARP entries show availability:
R1# sh ip arp | incl 10.201.2 Internet 10.201.2.1 - 0014.a923.1680 ARPA GigabitEthernet0/0.7 Internet 10.201.2.2 6 dc9f.db00.37fa ARPA GigabitEthernet0/0.7 Internet 10.201.2.3 7 dc9f.db00.3712 ARPA GigabitEthernet0/0.7 Internet 10.201.2.4 0 dc9f.db00.37f8 ARPA GigabitEthernet0/0.7 Internet 10.201.2.5 0 dc9f.db00.36eb ARPA GigabitEthernet0/0.7 R2# sh ip arp | incl 10.201.2. Internet 10.201.2.1 0 Incomplete ARPA Internet 10.201.2.2 7 dc9f.db00.37fa ARPA FastEthernet2/0.7 Internet 10.201.2.3 8 dc9f.db00.3712 ARPA FastEthernet2/0.7 Internet 10.201.2.4 0 dc9f.db00.37f8 ARPA FastEthernet2/0.7 Internet 10.201.2.5 0 dc9f.db00.36eb ARPA FastEthernet2/0.7 Internet 10.201.2.6 - 0014.a923.16b9 ARPA FastEthernet2/0.7
but we cannot access any of .2 to .5 from either side. For example:
R1#ping 10.201.2.2 source 10.201.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.201.2.2, timeout is 2 seconds: Packet sent with a source address of 10.201.2.1 ..... Success rate is 0 percent (0/5)
Thanks in advance for any and all help,
Nick
03-31-2016 01:19 AM
For completeness, I must explain that finally the problem was the Ub4 device; it was found to seriously malfunction due to a power surge (caused by an electrical storm). The device was flooding the network causing abnormal behavior and all sorts of problems.
So, in essence, the issue was due to hardware failure.
Nick
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