You have told us that when the problem happens that you can fix it by rebooting the RV325. The next time that it happens would you try disconnecting the WAN interface, waiting a minute, and reconnecting the WAB interface and see if that also fixes the problem?   HTH   Rick ... View more

@Giuseppe Larosa provides an interesting comment about using vlan 1001. I am not sure that using that reserved vlan is the cause of the problem with HSRP. And even if it were the cause of the problem on vlan 1001 it does not explain the problem in vlan 971.   There is a very interesting inconsistency about the issue in vlan 971. It seems that 02 does not see 01, but 01 does see 02. 01#sh standby vlan 971 Vlan971 - Group 9 State is Standby Active router is 10.48.153.131, priority 201 (expires in 8.384 sec) Standby router is local   As a next step in investigating this issue I suggest doing show cdp neighbor on both switches and looking for neighbors in vlan 971. My guess is that one switch does see a neighbor but the other switch does not.   HTH   Rick ... View more

We also need information about the addressing used. What is the public IP of sites A and B? What is the LAN subnet(s) of site A and B? What is the IP addresses of the servers that are now at site B? Did that subnet move from site A to site B or is part of that subnet still at site A?   HTH   Rick ... View more

No your ACL would not be like that. First I am not clear why you have 192.168.16.0 in the ACL. When you include that subnet in the ACL it implies that packets with source address in that subnet will enter the switch on this interface. We do not know about your topology but I doubt that packets from 192.168.16.0 will enter the switch on vlan 21. My guess is that you include this in the ACL believing that it would enable DHCP. But that is not the case. The ACL is using 192.168.16.0 as the source address and for DHCP traffic 192.168.16.0 would be the destination. So remove 192.168.16.0 from the ACL.   Second what you need to do is to deny traffic for DHCP before you permit traffic from 192.168.21.0. Your ACL might look something like this ip access-list extended vlan_21_ACL deny udp any any eq 67 permit ip 192.168.21.0 0.0.0.255 any   HTH   Rick ... View more

If you deny DHCP in the ACL used for PBR it would not stop your devices from getting IP addresses using DHCP. We need to be clear about how ACLs are used. If you apply an ACL on an interface using ip access-group then yes denying DHCP would stop devices from getting IP addresses using DHCP. But apply the ACL in PBR and it works differently. You are just denying DHCP from receiving the special routing in PBR and allowing that traffic to use normal routing. A deny in the ACL for PBR does not deny the packet from being forwarded but only deny for the special routing.   HTH   Rick ... View more

I would not have thought that your PBR would impact DHCP and helper-address since it is looking for IP packet source addresses in specified subnets and the DHCP request source address should be 0.0.0.0. But if it is impacting the assignment of IP addresses then you need to add a statement at the beginning of your ACL that denies traffic for DHCP.   HTH   Rick ... View more

TK   Thanks for the additional information. What you describe here is certainly not the expected behavior. It may take some additional investigation to understand this issue. As a next step would you post the output on both of your BGP CE routers of the command show ip bgp neighbor advertised   HTH   Rick ... View more

Derrick   Thanks for the update. It will be a learning experience. If you need anything else let me know.   HTH   Rick ... View more

Matt   Thanks for the update. I am glad to know that our suggestions about the log parameter were helpful. Good to know that you had anticipated my other suggestions.   HTH   Rick ... View more

Matt   Yes line vty 0 4 transport input ssh means that ssh is the only remote access protocol that will be accepted. Note that you must enable ssh by generating keys to encrypt the ssh traffic (and that will require that you have configured a device name and domain name).    You might think about whether you want to accept both ssh version 1 and version 2 (which is the default) or accept only a single version.   You should also be aware that while line vty 0 4 has been the standard for a long time, that there are many Cisco devices which have more than 5 vty ports (frequently there are also line vty 5 15) so you should check each device to verify how many vty it has and modify your configuration accordingly.   I generally do not use the log parameter when I am configuring access lists for access-class. I do not feel that the information provided is useful enough to justify the effort of generating the log messages.   HTH   Rick ... View more

As I stated in my previous response, are there any parameters or any attributes used in the profile that are different between the tunnels? If there are differences then you need separate profiles. If they use the same parameters and attributes then there is no requirement for a separate profile.    HTH   Rick ... View more

Giuseppe   No need to apologize. You provided context and information about the environment that I did not know. So it was helpful. I agree that at this point we need additional information from Mahesh to be able to understand the issue.   HTH   Rick ... View more

Giuseppe   I appreciate the insight about multiple threads about this network. I did not see the others and so have less information about this environment than you do and can comment only on the bit that I know. I certainly agree that the asymmetric paths that Mahesh is experiencing is quite common. And ultimately it is not something that he can control.   But he asked a question and we are trying to answer it " How can I verify that how many prefixes ISP 2 is allowing from our network? "  I do not want to be overly picky but his question is not whether ISP 2 receives the 3 prefixes but is about what policy ISP 2 has implemented about his prefixes. And without knowing what the policy is on the router connecting ISP 2 to its upstream neighbor we can not really answer that question.   I had an experience with a customer that might be similar to the situation for Mahesh. The customer had 2 ISPs. They had a /24 assigned to them from ISP 1. They received permission to advertise that network to ISP 2. ISP 1 was the preferred path for them. When they tested they verified that their outbound traffic did go out via ISP 1. But they found that return traffic came back via ISP 2. So far sounds sort of like Mahesh. The issue turns out to be that they advertised their /24 to both ISP. ISP 1 aggregated that address block and advertised a much bigger block. ISP 2 advertised the /24 to the Internet. And as we all know the more specific route is always preferred. This explains their asymmetric paths. This is the reason why I was asking about the prefixes that Mahesh has.   HTH   Rick ... View more

It is interesting that it can range from 5 minutes to several days for the problem to occur. When the problem does happen can you check the status of the WAN interface? Can you check the arp table and see if the mac address of the gateway is in the table? Can you ping the gateway address?   HTH   Rick ... View more

In the original post @mahesh18  tells us that they have 3 prefixes which they advertise to both ISP. He does not tell us whether they are doing anything in the advertisement to make one ISP preferred over the other (prepending is the most common way to do this) or is just advertising the prefixes equally to both ISP. He also does not tell us anything about his address space. Is this provider independent addresses? Or are the addresses assigned by one of the ISP? This could have significant effect on how traffic is forwarded to his network.   Mahesh asks a very interesting (and quite subtle) question:" How can I verify that how many prefixes ISP 2 is allowing from our network? " He is not asking how many prefixes he is advertising (so show ip bgp neighbor advertised is not helpful). Giuseppe makes an interesting suggestion about the possibility of a looking glass in ISP 2. But I am not sure that will necessarily provide the right answer. If ISP 2 does have a looking glass it would show how many prefixes of Mahesh it has learned. But the looking glass does not have information about what policy might be implemented by ISP 2 on its router connecting to its upstream neighbor. There is a possibility that ISP 2 might learn 3 prefixes from Mahesh but does not advertise all 3 to its upstream neighbor. So the optimum approach would be to find a looking glass on the upstream neighbor of ISP 2.   HTH   Rick     ... View more