BGP breaking IPsec tunnels

General questions
1

Hi All,

Have an issue where as soon as i bring up bgp at one site the remote site drops all its ipsec connections. It appears the public IPs from each side are being advertised and then the preferred route to that IPSec tunnel remote is via the vtiX interface thus breaking the ipsec tunnel. I followed the example docs to exclude these prefixes in the prefix list then added to route-map on the bgp export.

Im pretty sure I have misconfigured something somewhere…

BGP off

show ip route ipsec_remote_ip

Routing entry for 0.0.0.0/0
  Known via "static", distance 5, metric 0
  Last update 2d22h56m ago
    secondaryISP, via bond0.4001, weight 1

Routing entry for 0.0.0.0/0
  Known via "static", distance 1, metric 0, best
  Last update 2d22h56m ago
  * primaryISP, via bond0.4000, weight 1

Routing entry for 0.0.0.0/0
  Known via "static", distance 200, metric 0
  Last update 02w2d23h ago
    10.42.2.253, via bond0.1002, weight 1

BGP ON

show ip route ipsec_remote_ip

Routing entry for ipsec_remote_ip
  Known via "bgp", distance 20, metric 0, best
  Last update 00:00:05 ago
  * 10.100.2.2, via vti2, weight 1

Remote A

BGP / Policy config 
[protocols]
 bgp {
     address-family {
         ipv4-unicast {
             redistribute {
                 connected
             }
         }
     }
     neighbor 10.42.2.253 {
         address-family {
             ipv4-unicast
         }
         interface {
             source-interface "bond0.1002"
         }
         remote-as "65101"
     }
     neighbor vti2 {
         address-family {
             ipv4-unicast {
                 route-map {
                     export "AS65101-staging-colo"
                 }
             }
         }
         interface {
             remote-as "65102"
         }
     }
     parameters {
         router-id "1.0.0.9"
     }
     system-as "65101"
 }
Policy prefix-list AS65101-staging-colo
 rule 10 {
     action deny
     prefix PrimaryISP/29
 }
 rule 20 {
     action deny
     prefix secondaryISP/29
 }
 rule 40 {
     action deny
     prefix 10.100.2.0/30
 }
Policy route-map AS65101-staging-colo
 rule 10 {
     action deny
     match {
         ip {
             address {
                 prefix-list AS65101-staging-colo
             }
         }
     }
 }
 rule 20 {
     action permit
 }

Remote B

BGP/Policy config 
[protocols]                                                                                                                                                                                                                                                                                                                                                                                                                         
 bgp {                                                                                                                                                                                                               
     address-family {                                                                                                                                                                                                
         ipv4-unicast {                                                                                                                                                                                              
             redistribute {                                                                                                                                                                                          
                 connected                                                                                                                                                                                           
             }
         }           
     }                 
     neighbor 10.75.2.253 {
         address-family { 
             ipv4-unicast
         }
         interface {
             source-interface "bond0.2"
         }               
         remote-as "65102"
     }    
     neighbor vti2 {
         address-family {              
             ipv4-unicast {
                 route-map {
                     export "AS65102-colo-dale-staging"
                 }  
             }           
         }                 
         interface {        
             remote-as "65101"                                                                            
         }        
     }        
     parameters {
         router-id "1.0.0.10"
     }                        
     system-as "65102"
 }    
]                
 policy {                    
         prefix-list AS65102-colo-staging {
         rule 10 {        
             action "deny"         
             prefix "PrimaryISP/29"
         }
         rule 20 {                          
             action "deny"
             prefix "SecondaryISP/27"
         }                            
         rule 40 {
             action "deny
             prefix "10.100.2.0/30"
         }
     }
      route-map AS65102-colo-staging {
         rule 10 {
             action "deny"
             match {
                 ip {
                     address {
                         prefix-list "AS65102-colo-staging"
                     }
                 }
             }
         }
         rule 20 {
             action "permit"
         }
     }
 }
2

The issue is that you need a static route to “ipsec_remote_ip” which will cause the traffic to go out through the desired interface. This needs at all times to be preferable to any route learned via BGP. There would seem to be no need to use route-maps to manipulate the incoming routes.

You can get the same issue with other routing protocols.

3

I don’t like “redistribute connected” , as it will advertise all networks , including your WAN.
I’d try adding a summary blackhole route for your internal network (so it’s in route table), then advertise that using network statement

4

Even with the route-map export excluding it?

5

You have an error in your configuration. When you have a deny in a prefix-list, and it is later called in the route-map, you’re telling the route-map to not match on those prefixes. This tells the route-map to continue processing. So the route-map rule 10 is trying to match on the AS65101-staging-colo prefix-list, but all the entries are deny in it, so it will skip all of those. It then continues processing the route-map to rule 20 (because it didn’t match anything in rule 10), which is an explicit permit all, so your ISP prefixes get advertised, causing your recursive tunnel issue.

Just change the rules in your prefix-list to permit and the route-map will deny them like you intend.

With that said, it is better to just scope your redistribute connected command with a route-map, so that those prefixes never even enter your BGP table.

You can do something like this:

set policy prefix-list RED_CONN_PFX rule 10 action 'permit'
set policy prefix-list RED_CONN_PFX rule 10 prefix PrimaryISP/29
set policy prefix-list RED_CONN_PFX rule 20 action 'permit'
set policy prefix-list RED_CONN_PFX rule 20 prefix SecondaryISP/29
set policy prefix-list RED_CONN_PFX rule 30 action 'permit'
set policy prefix-list RED_CONN_PFX rule 30 prefix '10.100.2.0/30'

set policy route-map RED_CONN_RM rule 10 action 'deny'
set policy route-map RED_CONN_RM rule 10 match ip address prefix-list 'RED_CONN_PFX'
set policy route-map RED_CONN_RM rule 20 action 'permit'

set protocols bgp address-family ipv4-unicast redistribute connected route-map 'RED_CONN_RM'
3 Likes
6

@L0crian Thank you for your solution and explanation.

This has fixed my issue. I shall go do a bit more reading :smile:

2 Likes
7

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.