Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Paul_Warnagiris
Advisor

Filtering learned BGP routes

Good Afternoon,

I'm setting up a new datacenter cluster and I'm going to be learning routes from three peers via BGP.  I understand I need an inbound filter to add them to my routing table, but I don't want to blindly learn any route that I'm sent based on AS number.  How can I setup a prefix list and apply it to a neighbor (in Cisco terms) so I can trust but verify?

I understand its probably in CLI as opposed to WebUI, but I'm having trouble finding documentation for specifically what I'm trying to do.  Any guidance would be appreciated.

Thanks,
Paul

0 Kudos
8 Replies
FedericoMeiners
Advisor

Paul,

Hope you are doing fine, I think that this could be achieved with inbound filters and route maps from the advance routing section

Advance Routing - Inbound filters & Route maps 

Let us know how it goes 🙂

____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
Lari_Luoma
Ambassador Ambassador
Ambassador

You can do something like this.

set prefix-list routes-inbound sequence-number 10 prefix 11.12.0.0/16 between 16 and 30
set routemap routes-inbound id 1 on
set routemap routes-inbound id 1 allow
set routemap routes-inbound id 1 match prefix-list routes-inbound preference 1 on
set bgp external remote-as 65000 import-routemap "routes-inbound" preference 1 on

0 Kudos
Brian_Deutmeyer
Collaborator

Here is another example:

Let's say you are peering with ASN 54321 and ASN 12345.  In the example below, we will NOT accept a default route from 54321 and we are validating that any other route from that peer must have ASN 54321 in the AS Path.  For peer 12345, we are again validating ASN 12345 is in the path by only accepting routes with that ASN in the path and then we will accept any 10/8 route or smaller, only 172.16/12 (nothing more, nothing less) and anything smaller than 192.168/16.

set routemap bgp-in-54321 id 10 on
set routemap bgp-in-54321 id 10 restrict
set routemap bgp-in-54321 id 10 match network 0.0.0.0/0 exact
set routemap bgp-in-54321 id 20 on
set routemap bgp-in-54321 id 20 allow
set routemap bgp-in-54321 id 20 match as 54321 on
set routemap bgp-in-12345 id 20 on
set routemap bgp-in-12345 id 20 allow
set routemap bgp-in-12345 id 20 match as 12345 on
set routemap bgp-in-12345 id 20 match network 10.0.0.0/8 all
set routemap bgp-in-12345 id 20 match network 172.16.0.0/12 exact
set routemap bgp-in-12345 id 20 match network 192.168.0.0/16 refines

set bgp external remote-as 54321 import-routemap bgp-in-54321 preference 10 on
set bgp external remote-as 12345 import-routemap bgp-in-12345 preference 10 on

 

Here are some commands I've found helpful:

show bgp peers    <-- shows the state
show bgp peer 1.2.3.4 advertise   <-- shows the routes being sent to that peer
show bgp peer 1.2.3.4 received    <-- shows the routes being learned from that peer (even routes that are not made active in the firewall's route table)
show route bgp aspath   <-- see the aspath on routes
show route bgp all   <-- see all active and inactive bgp routes

0 Kudos
Paul_Warnagiris
Advisor

Thank you for your reply.  I found it to be very helpful.  I think I am missing something though.  I did this routemap just for a test:

set routemap bgp-in-65534 id 10 on
set routemap bgp-in-65534 id 10 restrict
set routemap bgp-in-65534 id 10 match network 10.0.0.0/8 all 

However, when I do a show configuration my set command is commented out as shown below.  I believe this is my problem.  Have you ever seen this?

## The following items are listed under their respective command sets
## (e.g. "set bgp") and are displayed here for informational purposes:
# set bgp external remote-as 65534 import-routemap bgp-in-65534 preference 10 on

Therefore I am still getting advertisements, but they are still inactive/hidden.  See some show commands below.

FW01> show route exact 10.21.6.0/24

Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),

       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)

       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,

       U - Unreachable, i - Inactive

 

FW01> show route bgp detailed
FW01> show bgp peer 172.31.31.74 received

IPv4 Route          MED         LocalPref   Nexthop          Communities 
10.1.4/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.1.5/24           None        N/A (eBGP)  172.31.31.74     8009:8009
10.1.8/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.1.9/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.1/24             None        N/A (eBGP)  172.31.31.74     8009:8009    
10.4.4/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.4.6/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.4.8/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.4.9/24           None        N/A (eBGP)  172.31.31.74     8009:8009
1
0.4/24             None        N/A (eBGP)  172.31.31.74     8009:8009    
10.5.2/24           None        N/A (eBGP)  172.31.31.74     8009:8009    
10.5.4/24           None        N/A (eBGP)  172.31.31.74     8009:8009    

FW01> show route all

Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),

       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),

       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,

       U - Unreachable, i - Inactive

 

S         0.0.0.0/0           via 8.9.10.11, eth1, cost 0, age 560686 

C         1.1.1.0/30          is directly connected, bond1 

                                  Bond FW01 

B    H i  10.1.4.0/24         via 172.31.31.74, eth2, cost None, age 931 

                                  SDWan BGP 

B    H i  10.1.4.0/24         via 172.31.31.73, eth2, cost None, age 931 

                                  SDWan BGP 

B    H i  10.1.5.0/24         via 172.31.31.74, eth2, cost None, age 931 

                                  SDWan BGP 
B    H i  10.1.5.0/24         via 172.31.31.73, eth2, cost None, age 931 

                                  SDWan BGP 
B    H i  10.1.8.0/24         via 172.31.31.74, eth2, cost None, age 931 

                                  SDWan BGP 

0 Kudos
Brian_Deutmeyer
Collaborator

First off, the routemap you are testing with does nothing, so I'm not sure what you are trying to test.  

The commented out line for applying the routemap is for informational use only when looking at the routemap config.  The actual config line that is used is with the bgp config.

show configuration bgp  <-- it lives here
show configuration routemaps  <-- comment line is here for information use only

 

The way the routing table is setup, it contains:
1. Active routes
2. Inactive routes (i)
3. Hidden routes  (H)

By default, with no routemaps configured, all received routes from peers will be Hidden (and inactive).  Once you configure a routemap to accept routes, those routes will no longer be hidden and become active.  However, if you have two or more exact routes (like 192.168.0.0/24) from two or more peers, then a selection process takes place to make one route active and the others will remain inactive.  If the peer with the active route goes away, the route from the next peer based on the selection will go active.

show route  <-- shows only active routes
show route all   <-- show all routes  (active, inactive and hidden)

 

Your 'show bgp peer x.x.x.x received' shows that you are receiving routes from that specific peer.  Your 'show route all' shows the routes in the routetable.  So far, so good.  You just need a routemap to flip those routes active. If you are just wanting the routes shown to go active, run this command:

set routemap bgp-in-65534 id 10 allow   <-- This will start making routes active, instead of the restrict you currently have to keep them hidden

 

At the simplest form, this routemap will accept any route from the peer:

set routemap bgp-in id 10 on
set routemap bgp-in id 10 allow
set bgp external remote-as 12345 import-routemap bgp-in preference 10 on

 

And this will redistribute any directly connected network, static route and any BGP route that are active in the route table:

set routemap bgp-out id 10 on
set routemap bgp-out id 10 allow
set routemap bgp-out id 10 match protocol direct
set routemap bgp-out id 20 on
set routemap bgp-out id 20 allow
set routemap bgp-out id 20 match protocol static
set routemap bgp-out id 30 on
set routemap bgp-out id 30 allow
set routemap bgp-out id 30 match protocol bgp
set bgp external remote-as 12345 export-routemap bgp-out preference 10 on

0 Kudos
Paul_Warnagiris
Advisor

Got it.  I knew most of what you described, but my problem was restrict and not allow in my route map.  Stupid.  I just needed a second set of eyes I guess.  After removing restrict and adding allow my routes are now redistributed into the CP routing table.  Thanks for the sanity check.

I'm still not 100% certain why  set bgp external statement is commented out, but thats fine.  As long as it works.

FW01> show configuration routemaps
set routemap bgp-in-65534 id 10 on
set routemap bgp-in-65534 id 10 allow
set routemap bgp-in-65534 id 10 match network 10.0.0.0/8 all
## The following items are listed under their respective command sets
## (e.g. "set bgp") and are displayed here for informational purposes
# set bgp external remote-as 65534 import-routemap bgp-in-65534 preference 10 on
FW01>

 

Thank you to all that replied.
Paul

0 Kudos
Brian_Deutmeyer
Collaborator

Glad it is working.  

 

The set bgp external...import-routemap... command will show commented out when you run 'show configuration routemaps'.  It will not be commented out when you run 'show configuration bgp'.

0 Kudos
Lari_Luoma
Ambassador Ambassador
Ambassador

As BGP doesn't accept any routes by default, the inbound filters must always be configured.

You can use the following command to allow all IPv4 for example.

set inbound-route-filter bgp-policy 512 based-on-as as 65000 on
set inbound-route-filter bgp-policy 512 accept-all-ipv4

 

bgp_inbound_route_filter.PNG

 

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events