I don't know if "occasional" is the right word, but yes, it appears out of nowhere on as it seems totally random times. I only see packet loss when the VRRP is active on the 42.2 router. How do you experience the packet loss? Do you ping to some place on the Internet and see pings drop? How bad does it get? Is there any possibility that you are, at times, saturating your ISP connection? Are you performing rate limiting/policing anywhere? Are you seeing any dropped packets or errors on any interfaces? So if I understand correclty, you never see packet loss when the VRRP address is active on the 42.3 router, but you see occasional packet loss when the VRRP is active on the 42.2 router. Just ask if you need any clearification of the setup or want to see configuration files. I would very much appreciate any input in this question.
#Juniper ex4300 mac table size how to#
I don't see anything suspicious in the Junos log files, and frankly, I am running out of ideas on how to proceed with the troubleshooting of this problem. I have also pondered the possibility of MAC table errors, but I haven't seen anything that indicates such a problem, and can't find any static ARP entries anywhere either. This should be fine, though, since the Cisco routers was set up the same way as I have set up my J6350's, and the firewalls aren't configured to disallow it. I have been doing a lot of tracerouting, and can see that the routing is assymetric, which is due to the fact that traffic leaves the firewalls through a.b.42.1/23 and is returned from a.b.42.3/23, which for the moment is the only of the two J6350's that has Internet connectivity. I also think I can rule out the firewall, since the packet loss appeared on traffic that doesn't pass through the firewall aswell.
I think I can rule out the switches, since traffic flows just fine through all of them, up to the point where the packet loss starts, and keeps on flowing just as fine after the VRRP failover.
#Juniper ex4300 mac table size manual#
Again, a manual failover of the VRRP address a.b.42.1/23 to the backup node a.b.42.3/23 solved the problem, and it has been working as expected since then, 28 hours and counting. About six hours later, the same problem appeared again. This reset was done some 15 hours after the first manual failover, and when it was done, everything seemed to work OK, even with 900+ Mbps imix going through a.b.42.1/23, via both a.b.42.2/23 and a.b.42.3/23.
We kept running on a.b.42.3/23 as the master VRRP node, but decided to try to reset the configuration, making a.b.42.2/23 master again. I did a reconfiguration to force a.b.42.1/23 over to the other node, a.b.42.3/24, and that made the problem dissapear. At first, a few hours after the whole thing was put in place, the J6350 labeled a.b.42.2/23 started dropping packets going through a.b.42.1/23. Since I put this setup into production on monday night, I've been having very strange problems with lost packets and what not. As you also can see, there are a lot of LACP/EtherChannel/trunking going on, and to top it off, an RSTP tree.
The J6350's uses VRRP to make the address labled a.b.42.1 highly available to the firewalls, which uses it as its default gateway. At present, only the transit peer to AS123 is up and running, which means the J6350 labeled a.b.42.2/23 in the diagram reaches the Internet via iBGP through a.b.42.3/23. Between the J6350's there are iBGP sessions set up, so that both routers can use routes from both eBGP peers. In my opinion, the original design of the network is a bit of a mess, but I didn't really have the possibility to change it.Īs you see in the network diagram attached, I have two J6350's peering via eBGP with one transit provider each. We decided to go for J6350's, which have been set up as drop-in replacements for Cisco 3825's. I work as a systems architect at a medium-sized hosting company, and during the last few months, I've been in charge of replacing our Cisco routers with Juniper ones. First, a short introduction: I am Joakim, 29 years old from Sweden.
0 kommentar(er)
