Verizon router removem vlan update#
The customer had the AdTran consultant update the probe source to use the physical address of the AdTran router.ĭuring the next maintenance window, the customer reconnected the AdTran, but the AdTran consultant was not able to ping the primary interface of the AdTran router. Show Run from AdTran Router AdTranVoIP#show run The AdTran consultant did say that by design the secondary interface was not Layer 3 reachable when the primary interface was active). We thought this was an error (We assumed the other failover stuff should work. It was using 172.31.4.54, which is IP address of the secondary ASA in the ASA pair. Neither the customer nor NetCraftsmen has access credential to the AdTran router.Īfter scanning the AdTran running-configuration, we noticed that there was a probe configured that used a non-local source address. Note: The AdTran commands are very similar Cisco IOS.
Verizon router removem vlan mac#
show interface so we could gather the MAC address of the new interfaces in case we needed to configure static ARP entries on the ASA.We also asked for and received some AdTran show commands:
We asked the customer to remove the unused crypto map statements that pointed to 172.31.4.53. We were wondering about the interaction of proxy ARP on the two ISP routers (both Juniper devices), the AdTran router, and the ASA5545 firewall, but we had not ever seen actual evidence of the issues (The log files on the ASA were too short to provide any details). The customer also had unused crypto map statements on four sets of ASAs pointing to 172.31.4.53 - the fifth ASA previously with address 172.31.4.53 had been removed from service. We heard that the customer initially provided the AdTran consultant with an incorrect IP address of 172.31.4.54 that was the IP of the secondary ASA in the firewall pair, but this was updated (The customer had not recorded the use of the secondary address in his IP spreadsheet). The new public IPs for the AdTran router were not configured in a NAT statement or network object group. The ASA has the default proxy ARP defined on all interfaces. We were not sure why both ISP router MACs were showing up multiple times in the ASA ARP table. Show ARP from ASA5545 After CrashĪfter the crash, the customer reported that ASA5545 showed this show arp output: ASA5545/act# sh arp We never got a chance to see the issues while happening - the customer tested it without asking us to watch. He then needed to remove the AdTran router connections from the ISP switch, and clear the ARP table on the ASA. The customer stated after connecting the AdTran router, the connections to the ISPs were dropped. Note: The 2960X-ISP is a Layer 2 switch with no SVIs in VLAN 800 or 801. Total Mac Addresses for this criterion: 27 Note: We believed the customer had mis-labeled the VLANs going to his two ISP routers. The customer provided a sketch of the environment that looked something like this:Īfter reviewing the switch and ASA configs, we updated the diagram to illustrate what we believed was actually configured, and shared it with the customer.
They want to put it beside ours but that is the scenario that isn’t working.” We can put it in front of our firewall, not preferred, behind, etc. Can we engage you to assist with this issue so that we can get the vendor VoIP router connected? This needs to be fairly immediate engagement as we are looking to deploy VoIP in less than a month and have been trying for almost a month to deploy their router. When added to our edge switch, it brings down both ISP circuits and so our network connections drop.
“We have a problem with our VoIP vendor and a router they are trying to add. My colleague and I have been supporting a customer who had complained about a new AdTran VoIP router added to his environment that was causing his ISP circuits to go down.
0 kommentar(er)
