I am currently trying to sort out (with my ISP) whether or not a particular BGP service is configured (using two ASA5506X) correctly. Currently the following is configured:
Currently, from the address 172.16.10.3 I can ping:
From the address 172.16.20.3 I can ping:
I can't ping between the two local networks (eg 172.16.20.3 to 172.16.10.3). On ASA interface for 10.252.0.2 I can see outbound packets to 10.252.0.9 and 172.16.20.3 but no inbound ones. So I reason there are two possibilities:
So far I have tried:
Is there are way for me to tell if the packets arriving at 10.252.0.2 are being dropped? Should they be viewable using Packet Capture? Is there another method for seeing if those packets are being dropped? This would be helpful either way as if I can determine the packets are in fact being dropped I can show that to the provider of evidence that my end is setup correctly.
Happy to clarify any of these or post configs.
Can you post -
1) configs of both firewalls
2) routing tables for both firewalls
3) BGP tables for both firewalls
remove any sensitive info from firewall configs before posting.
Hello @DStringfield ,
in addition to what @Jon Marshall has asked I would like to add the following:
>> Should they be viewable using Packet Capture?
Yes you can use packet capture on the ASA and you can specify a filter so that only interesting packets are captured
The command syntax from CLI is similar to the following example:
capture VMTEST interface inside match icmp host 10.2.0.203 any
You need to change the interface name to match the one connected to the provider and the host IP address can be 172.16.10.X
show capture VMTEST to show packets
and to delete a capture
no capture VMTEST
also the capture name can be chosen .
This can allow you to understand if you are facing a unidirectional forwarding plane in the SP network
for a a working network you would see incoming imcp echo packets and outgoing echo replies.
Hope to help
By default icmp inspection is denied on ASA, so have you tried allowing this?
Super frustratingly it ended up being a provider error that took a month to resolve. I really appreciate everyone's help and I learnt a lot during the process if that's at all a reward
Hello @DStringfield ,
nice to know that you have solved your issue and yes also service providers can make errors.