cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
931
Views
35
Helpful
15
Replies

Can't establish connection between BGP neighbours

DStringfield
Beginner
Beginner

I have two geographically distinct sites, each with an ASA5506, that I am trying to connect via BGP. Please see the attached diagram below

bgp_diagram_1.png

My work so far has been succesful. Both ASA's have BGP enabled, and have Established connections to the common AS (the details of which were given to me by our provider). I next thing I did was advertise the network 192.168.170.0/24 from 64513. When I login to the other ASA (under 64514) and I can view the routes, I can see the following entry in the table: 

Protocol | Type | Destination IP | Netmask       | Gateway    | Interface
BGP | | 192.168.170.0 | 255.255.255.0 | 10.252.0.9 |

When I view the BGP IPv4 Routes I see the following entry:

Status Code | Network       | Next Hop   | Metric | Local Pref | Weight | Path
*> | 192.168.170.0 | 10.252.0.9 | | 0 | 2764 64513 i

Despite this, when I try and send ping or tracert requests from 192.168.36.XXX addresses to 192.168.170.0/24, I don't get any response. I'm trying to understand why, as I have the right routes in place, so I can't see why traffic isn't going through. 

So far my thoughts are:

  • A misconfiguration for iBGP to eBGP. As we can see in the diagram this is an eBGP connection, but the route in the BGP Routes has an i for the origin code. 
    • I've ensured that Allow connections with neighbour that is not directly connected is checked in the BGP Neighbour settings
    • I've tried at various points to add a second neighbour connection to each AS (directly across to the other AS) but I can't get that configured properly, and when I spoke to the provider about it they suggested this shouldn't be necessary (and I have the routes, so seems unecessary).
  • A security issue. On both ASA's the traffic is going between two interfaces (the inside interface, and an interface dedicated to BGP connections). Both interfaces have the same security level and the Enable traffic between two or more interfaces... is checked. 
    • An access rule is in place for both ASAs enabling all IP traffic on both interfaces. 

I've tried everything I can think of. I can provide more configuration as needed, happy to answer more questions or take further reading recommendations to increase my knowledge on this topic. 

Thanks!

1 Accepted Solution

Accepted Solutions

Hello David,

if your provider is an MPLS provider and it is giving you an MPLS L3 VPN, there can be an issue in the forwarding plane that they need to investigate a Label Switched Path in one direction may be not working correctly.

 

Hope to help

Giuseppe

 

View solution in original post

15 Replies 15

Giuseppe Larosa
Hall of Fame Master Hall of Fame Master
Hall of Fame Master

Hello,

the devices are Firewall not routers !

>>Despite this, when I try and send ping or tracert requests from 192.168.36.XXX addresses to 192.168.170.0/24, I don't get any response. I'm trying to understand why, as I have the right routes in place, so I can't see why traffic isn't going through.

 

Then also the return path needs a route so you need to advertise subnet 192.168.36.0 in BGP  as well from the other side that is in AS 64514.

In addition to this the outside ACL applied to each FW to the outside interface  must allow traffic coming from the other site.

example of a line:

access-list outside extended permit ip 192.168.36.0 255.255.255.0 192.167.170.0 255.255.255.0

 

 

Hope to help

Giuseppe

 

Hi Giuseppe,

Thanks for your response. Okay I didn't have the other network advertised: that makes sense. I've now added it. As I said: I was fairly confident I had the correct ACL's in place, but I've gone ahead an added more for good measure. On both devices, for both relevant interfaces (inside & internal_routing) I've added rules allowing traffic in both directions for both networks:

show access-list internal_routing
access-list internal_routing; 6 elements; name hash: 0xff1e75c0
access-list internal_routing line 1 extended permit object-group DM_INLINE_PROTOCOL_5 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0x22a03213
  access-list internal_routing line 1 extended permit ip 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0x8358f5ea
  access-list internal_routing line 1 extended permit icmp 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0x7c83c670
  access-list internal_routing line 1 extended permit icmp6 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0xb5fcc511
access-list internal_routing line 2 extended permit object-group DM_INLINE_PROTOCOL_6 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0x27c062c7
  access-list internal_routing line 2 extended permit ip 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0x74803d9b
  access-list internal_routing line 2 extended permit icmp 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0x31ad0d7b
  access-list internal_routing line 2 extended permit icmp6 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0xe061016a

show access-list inside
access-list inside; 6 elements; name hash: 0x45467dcb
access-list inside line 1 extended permit object-group DM_INLINE_PROTOCOL_4 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0xb10ac335
access-list inside line 1 extended permit ip 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0x88e5cdd9
access-list inside line 1 extended permit icmp 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0xeee90664
access-list inside line 1 extended permit icmp6 192.168.33.0 255.255.255.0 192.168.170.0 255.255.255.0 (hitcnt=0) 0x07e4c468
access-list inside line 2 extended permit object-group DM_INLINE_PROTOCOL_7 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0x500493d4
access-list inside line 2 extended permit ip 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0xfe205f06
access-list inside line 2 extended permit icmp 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0x71a829d5
access-list inside line 2 extended permit icmp6 192.168.170.0 255.255.255.0 192.168.33.0 255.255.255.0 (hitcnt=0) 0x78a0f635

 (Note, these rules are the same on both devices & the target network is not 192.168.33.0/24 unlike the in initial example).

Having done this and double checked the routes, I began running packet traces to see what was happening to the packets. I can confirm the following:

  1. Packets sent from 192.168.170.0/24 reach the inside interface for 64513
  2. Packets sent from 192.168.33.0/24 fail to reach the internal_routing interface for 64514

This is all tested using ping. My understanding is that because packets are being dropped at the internal_routing interface on the ASA for 64514, that echo responses cannot be sent from 192.168.33.0/24 back to 192.168.170/24.

At this point I tried doing captures with the asp_drop capture flag enabled on both devices. However I was unable to find any record of the packets being dropped. I tried a range of packet capture types but nothing seemed to give me more info about what is going on. Feel like I'm getting very close if I can just stop these packets being dropped. I'm happy to show configs or more captures as requested.

Thanks,

David

Hello ,

>> On both devices, for both relevant interfaces (inside & internal_routing) I've added rules allowing traffic in both directions for both networks:

 

What we can note is that all lines in each ACL have hit count 0

From a device in subnet 192.168.33.0/24   from a shell you can try to do

telnet 192.168.170.X 80

 

if you have a web server on host 192.168.170.X

This is just to make a test with a protocol based on TCP instead of ICMP

It may be possible that you need to modify the global inspect policy for ICMP as suggested by Paul Driver.

 

Hope to help

Giuseppe

 

Hi Giuseppe,

 

Okay I performed those steps. From a device 192.168.33.91 I tried to telnet to 192.168.170.35 on port 80, but this was unsuccesful. I also tried this command from another host (one routed without BGP) and was able to connect no problem. I have entered the commands as suggested by Paul. Is there a way I can verify they registered correctly on the ASA?

 

Thanks,

David