Transactional (Candidate) configurations with Nokia SROS

While it’s not a new feature for SROS, the introduction of transactional configurations with SROS was not a day one feature (unlike JunOS), so it may be less known to existing users.

Firstly before getting into rollback configurations, I would like to point out that SROS has been saving multiple copies of configurations via rotation based mechanism for quite some time without needing specific activation.

A:SR1# show system information | match expression "Config|Backup"
Config Source          : primary
Last Booted Config File: cf3:\config.cfg
Last Boot Config Header: # TiMOS-B-14.0.R4 both/i386 Nokia 7750 SR Copyright
Last Saved Config      : cf3:\config.cfg
Max Cfg/BOF Backup Rev : 5

cf3:\config.cfg (which can be changed from this default by modifying the boot options file) will store the current config and the previous 4 versions and while the number of saved configs is modifiable, 5 is most likely enough for most. Anyway, reverting to a previous configuration can be quite a disruptive event, if you copy an older config over cf3:\config.cfg and performing a system reboot. This is where rollback configurations and combining them with transactional (called candidate) configurations become helpful particularly during a complex task like a network migration.

Achyar Nur Andi has a good post discussing the mechanics around rollbacks and candidate configurations at www.achyarnurandi.net, so I will just highlight a few of the main features and how you can enforce the method of router configuration to only use candidate configurations.

The first thing to do is to specify the rollback file prefix (in this case conf-rollback on compact flash 3):

A:SR1# /configure system rollback
A:SR1>config>system>rollback# rollback-location cf3:\conf-rollback
INFO: CLI No checkpoints currently exist at the rollback location.
*A:SR1>config>system>rollback# show system rollback

===============================================================================
Rollback Information
===============================================================================
Rollback Location            : cf3:\conf-rollback
Max Local  Rollback Files    : 10
Max Remote Rollback Files    : 10
Save
  Last Rollback Save Result  : None
  Last Save Completion Time  : N/A
Revert
  In Progress                : No
  Last Revert Initiated User : N/A
  Last Revert Checkpoint File: N/A
  Last Revert Result         : None
  Last Revert Initiated Time : N/A
  Last Revert Completion Time: N/A
Delete
  Last Rollback Delete Result: None

===============================================================================
Rollback Files
===============================================================================
Idx    Suffix    Creation Time            Release           User
         Comment
-------------------------------------------------------------------------------
No Matching Entries
===============================================================================
*A:SR1>config>system>rollback# exit all

We’ll create our first rollback point:

*A:SR1# admin rollback save comment "Baseline Config"
Saving rollback configuration to cf3:\conf-rollback.rb... OK
*A:SR1# show system rollback

===============================================================================
Rollback Information
===============================================================================
Rollback Location            : cf3:\conf-rollback
Max Local  Rollback Files    : 10
Max Remote Rollback Files    : 10
Save
  Last Rollback Save Result  : Successful
  Last Save Completion Time  : 2017/05/23 02:35:38  UTC
Revert
  In Progress                : No
  Last Revert Initiated User : N/A
  Last Revert Checkpoint File: N/A
  Last Revert Result         : None
  Last Revert Initiated Time : N/A
  Last Revert Completion Time: N/A
Delete
  Last Rollback Delete Result: None

===============================================================================
Rollback Files
===============================================================================
Idx    Suffix    Creation Time            Release           User
         Comment
-------------------------------------------------------------------------------
latest .rb       2017/05/23 02:35:38  UTC B-14.0.R4         admin
           Baseline Config
-------------------------------------------------------------------------------
No. of Rollback Files: 1
===============================================================================

There’s only one rollback called latest.rb

For this example, just a simply system name change:
*A:SR1# /configure system name "Wrong Name"Now to compare the current working configuration with the rollback:

*A:Wrong Name# admin rollback compare
Processing current config... 0.010 s
Processing "cf3:\conf-rollback.rb"... 0.020 s
----------------------------------------------
  configure
     system
+        name "Wrong Name"
-        name "SR1"
     exit
  exit
It’s very clear what the differences are. I would just like to highlight that at present, these configuration changes are still immediate – rollbacks on their own just provide a means to manage the change, and doesnt provide any atomic operations yet.

Let’s revert back to our old configuration:

*A:Wrong Name# admin rollback revert latest-rb
Restoring rollback configuration cf3:\rollback-dir.rb
Processing current config... 0.010 s
Processing "cf3:\rollback-dir.rb"... 0.020 s
Resolving dependencies... 0.000 s
Tearing setup down... 0.010 s
Rebuilding setup... 0.000 s
Finished in 0.050 s
*A:SR1#

Using candidate configuration mode, as opposed to the default “immediate” configuration mode does not implement the configuration changes until you commit them, in the event of a failure applying the configuration, the system will back out and re-wind the configuration allowing you the option to discard or modify your changes. Candidate configuration mode is enabled via “candidate edit”. For this example we are going to set the system address on our router, configure an ethernet port, create an IES and attach a VLAN on that port to an IP interface.
A:SR1# candidate edit
A:SR1>edit-cfg# configure router interface "system" address 111.111.111.111/32
A:SR1>edit-cfg# configure port 1/2/3 shutdown
A:SR1>edit-cfg# configure port 1/2/3 ethernet mode access
A:SR1>edit-cfg# configure port 1/2/3 ethernet encap-type dot1q
A:SR1>edit-cfg# configure port 1/2/3 no shutdown
A:SR1>edit-cfg# configure service ies 123 customer 1 create
A:SR1>edit-cfg>config>service>ies# interface TEST create
A:SR1>edit-cfg>config>service>ies>if# address 192.168.1.1/24
A:SR1>edit-cfg>config>service>ies>if# sap 1/2/3:4 create
A:SR1>edit-cfg>config>service>ies>if>sap# back
A:SR1>edit-cfg>config>service>ies>if# back
A:SR1>edit-cfg>config>service>ies# no shutdown
Based on where we are within the configuration tree, we can see the associated configuration changes:
A:SR1>edit-cfg>config>service>ies# candidate view
----------------------------------------------
17:             interface "TEST" create
18:                 address "192.168.1.1/24"
19:                 sap "1/2/3:4" create
20:                 exit
21:             exit
22:*            no shutdown
----------------------------------------------
Or if we get to the root of the configuration tree, we can see all the associated changes that are yet to be applied to the running configuration:
A:SR1>edit-cfg>config>service>ies# exit all
A:SR1>edit-cfg# candidate view
----------------------------------------------
1:  configure
2:      router
3:          interface "system"
4:              address "111.111.111.111/32"
5:          exit
6:      exit
7:      port "1/2/3"
8:          shutdown
9:          ethernet
10:             mode access
11:             encap-type dot1q
12:         exit
13:         no shutdown
14:     exit
15:     service
16:         ies "123" customer 1 create
17:             interface "TEST" create
18:                 address "192.168.1.1/24"
19:                 sap "1/2/3:4" create
20:                 exit
21:             exit
22:*            no shutdown
23:         exit
24:     exit
25: exit
----------------------------------------------
Now we can accept and attempt to push the configuration the router using “candidate commit”
A:SR1>edit-cfg# candidate commit
Processing current config... 0.010 s
Error at line 7: Command 'port "1/2/3"' failed in 'configure'
MINOR: CLI Port "1/2/3" does not exist.
Reverting changes...
Processing current config... 0.010 s
Processing memory checkpoint... 0.000 s
Resolving dependencies... 0.000 s
Tearing setup down... 0.000 s
Rebuilding setup... 0.010 s
Finished in 0.040 s
MINOR: CLI Commit failed and has been reverted.
Since there was an error in the configuration – our router doesn’t have a port 1/2/3 – the configuration failed and the whole new configuration context was backed out allowing the option to correct and reapply, or to reject the changes which is quite a powerful configuration tool and concept. As we know the problem was on line 7, we can specifically edit that line using “candidate replace 7” and replacing the string port “1/2/3” with the proper port which is “1/1/3″
*A:SR1>edit-cfg# candidate replace 7
*A:Replace by: port "1/1/3"
INFO: CLI Added 10 lines: 'port "1/1/3"'.
INFO: CLI Removed 10 lines: 'port "1/2/3"'.
It’s probably worth double checking the revised configuration
*A:SR1>edit-cfg# candidate view
----------------------------------------------
1:  configure
2:      router
3:          interface "system"
4:              address "111.111.111.111/32"
5:          exit
6:      exit
7:      port "1/1/3"
8:          shutdown
9:          ethernet
10:             mode access
11:             encap-type dot1q
12:         exit
13:         no shutdown
14:     exit
15:     service
16:         ies "123" customer 1 create
17:             interface "TEST" create
18:                 address "192.168.2.1/24"
19:                 sap "1/2/3:4" create
20:                 exit
21:             exit
22:*            no shutdown
23:         exit
24:     exit
25: exit
----------------------------------------------
The SAP also requires correction to align with the new port – this is on line 19
*A:SR1>edit-cfg# candidate replace 19
*A:Replace by: sap "1/1/3:4" create
INFO: CLI Added 2 lines: 'sap "1/1/3:4" create'.
INFO: CLI Removed 2 lines: 'sap "1/2/3:4" create'.
Now lets apply the configuration
*A:SR1>edit-cfg# candidate commit
Saving checkpoint file... OK
INFO: CLI Successfully executed 25 lines in 0.000 s.
Configuration mode is still quite handy to view what has been configure by jumping into the right configuration context and doing an info or info detail:
*A:SR1# /configure service
*A:SR1>config>service# info
----------------------------------------------
        customer 1 create
            description "Default customer"
        exit
        ies 1 customer 1 create
            interface "External" create
                address 200.200.200.1/24
                sap 1/1/1 create
                exit
            exit
            no shutdown
        exit
        ies 123 customer 1 create
            interface "TEST" create
                address 192.168.2.1/24
                sap 1/1/3:4 create
                exit
            exit
            no shutdown
        exit
----------------------------------------------
An operational problem can occur if we allow the use of both configuration candidate and immediate configurations such as being able to do
*A:SR1>config>service# ies 123 description "Candidate Config Test"the most likely will end up with people sticking with immediate configuration mode unless they are forced to use candidate configs. Fortunately there it is quite easy to enable this.*A:SR1# /configure system management cli configuration no immediate It doesn’t remove the facility to view configurations, just configuration changes:
*A:SR1# configure service ies 123
*A:SR1>config>service>ies# info
----------------------------------------------
            description "Candidate Config Test"
            interface "TEST" create
                address 192.168.2.1/24
                sap 1/1/3:4 create
                exit
            exit
            no shutdown
----------------------------------------------
If we now attempt a non-candidate mode configuration change:
*A:SR1>config>service>ies# description "New Description"
MINOR: CLI Direct modification of the configuration is not allowed. Use 'candidate edit' for all changes.
We are now forced to use candidate configs:
*A:SR1>config>service>ies# candidate edit
*A:SR1>edit-cfg# configure service ies 123 description "New Description"
*A:SR1>edit-cfg# candidate commit
Processing current config... 0.010 s
Saving checkpoint file... OK
INFO: CLI Successfully executed 7 lines in 0.000 s.

Coupled with the right processes, this is one of the tools to help increase the MTBM (Mean Time Between Mistakes) and reduce the amount of network disruption.

Using BGP Flowspec with Nokia SROS to protect the network edge

This post is about how you can use BGP to augment your network edge protection. Specifically BGP Flow spec can be used to dynamically add entries to an access control list (or ip-filter in Nokia SROS speak). Previous posts have been using ExaBGP as the method to inject traffic, and while it’s good at what it does, I’ve moved on to use GoBGP not because it seems to be quite a high performance BGP implementation (I’m just doing proof of concept work) but because GoBGP’s command line interface is more friendly and better documented than ExaBGP, making it the more versatile tool to generate route advertisements in a lab on the fly (at least for me).

BGP Flowspec Test Topology

The lab topology is designed to demonstrate filtering with flowspec – two routers (SR1 is under my control, while the External router is a gateway to unscrupulous entities that I cannot control) and GoBGP running on a computer in my Network Operations centre.

Before getting into the flowspec piece, I’ll go through the installation process for GoBGP and the Go Language for Ubuntu 16.04 (as the routers I’m using as running on eve-ng) and the computer in the example is bridged to SR1) and then how to develop the initial GoBGP configuration.

The Go Programming language is available via the standard Ubuntu repository
adam@m4600:~$ sudo apt-get install golang-go

GoBGP is pulled down as source code and compiled as part of the download process. An environmental variable needs to be set so Go knows where to pull down code, and where to build the binaries.
adam@m4600:~$ export GOPATH=$HOME/go
Tell go to pull down and build gobgpd (this takes awhile at least on my machine and you don’t get an indication on what it’s doing)
adam@m4600:~$ go get github.com/osrg/gobgp/gobgpd
The gobgp cli is a separate program that talks to gobgpd using the GoBGP API – downloading and building it is pretty quick in comparison to gobgpd:
adam@m4600:~$ go get github.com/osrg/gobgp/gobgp
Once built, we shall copy the generated binaries to the an executable path
adam@m4600:~$ sudo cp $GOPATH/bin/* /usr/local/sbin/
For those of us using the default bash shell, we can enable tab completion for the cli

adam@m4600:~$ sudo cp $GOPATH/src/github.com/osrg/gobgp/tools/completion/*.bash /etc/bash_completion.d/

Once GoBGP is installed, we can develop a configuration file that will be used to set up the GoBGP instance – in this case we’re defining the router itself and SR1 as a neighbor for the IPv4 FlowSpec address family:
A configuration file that will be used by the GoBGP Daemon enabling FlowSpec for IPv4 where we peer against SR1:

adam@m4600:~$ cat gobgp-flowspec.conf
[global.config]
  as = 64512
  router-id = "1.2.3.4"

[[neighbors]]
[neighbors.config]
  neighbor-address = "192.168.1.123"
  peer-as = 64512
[[neighbors.afi-safis]]
  [neighbors.afi-safis.config]
  afi-safi-name = "ipv4-flowspec"

The GoBGP documentation is also a bit nicer than ExaBGP too – additional information on setting up a configuration (including different formats is described in the GoBGP getting started document)

Start the GoBGP Daemon and read our new config:

adam@m4600:~$ sudo gobgpd -f gobgp-flowspec.conf
{"level":"info","msg":"gobgpd started","time":"2017-05-18T22:57:22+10:00"}
{"Topic":"Config","level":"info","msg":"Finished reading the config file","time":"2017-05-18T22:57:22+10:00"}
{"level":"info","msg":"Peer 192.168.1.123 is added","time":"2017-05-18T22:57:22+10:00"}
{"Topic":"Peer","level":"info","msg":"Add a peer configuration for:192.168.1.123","time":"2017-05-18T22:57:22+10:00"}
{"Key":"192.168.1.123","State":"BGP_FSM_OPENCONFIRM","Topic":"Peer","level":"info","msg":"Peer Up","time":"2017-05-18T22:57:40+10:00"}
We can see shortly after gobgpd started, it has already established a peering session with SR1 (192.168.1.123)

Opening up a new shell, we can use the gobgp client to verify that:

adam@m4600:~$ gobgp neighbor
Peer             AS  Up/Down State       |#Received  Accepted
192.168.1.123 64512 00:00:22 Establ      |        0         0
adam@m4600:~$ gobgp neighbor 192.168.1.123
BGP neighbor is 192.168.1.123, remote AS 64512
  BGP version 4, remote router ID 123.123.123.123
  BGP state = established, up for 00:01:53
  BGP OutQ = 0, Flops = 0
  Hold time is 90, keepalive interval is 30 seconds
  Configured hold time is 90, keepalive interval is 30 seconds
  %s
  Neighbor capabilities:
    multiprotocol:
        ipv4-flowspec:  advertised and received
    route-refresh:      advertised and received
    4-octet-as: advertised and received
  Message statistics:
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:             4          5
    Route Refresh:          0          0
    Discarded:              0          0
    Total:                  5          6
  Route statistics:
    Advertised:             0
    Received:               0
    Accepted:               0

We can also get SR1 to confirm it too:
*A:SR1# show router bgp summary | match Summ post-lines 100
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
                   AS PktRcvd InQ  Up/Down   State|Rcv/Act/Sent (Addr Family)
                      PktSent OutQ
-------------------------------------------------------------------------------
192.168.1.46
               64512        9    0 00h00m54s 0/0/0 (FlowIPv4)
                           13    0
-------------------------------------------------------------------------------

Now that the flowspec session is up and running but no one has exchanged any routes yet, I’ll park this for a moment to create a simple ip-filter (or ACL)

*A:SR1# /configure filter
*A:SR1>config>filter# info
----------------------------------------------
        match-list
            ip-prefix-list "FPL_RFC1918" create
                prefix 10.0.0.0/8
                prefix 172.16.0.0/12
                prefix 192.168.0.0/16
            exit
        exit
        ip-filter 100 create
            default-action forward
            embed-filter flowspec router "Base" offset 1000
            entry 10 create
                match
                    src-ip ip-prefix-list "FPL_RFC1918"
                exit
                action
                    drop
                exit
            exit
            entry 20 create
                match
                    dst-ip ip-prefix-list "FPL_RFC1918"
                exit
                action
                    drop
                exit
            exit
        exit
----------------------------------------------

The match-list ip-prefix-list “FPL_RFC1918” is a way to consolidate a number of network prefixes into a single named list enabling filter configurations to be smaller and more manageable (and easier to debug)

ip-filter 100 is the thing of interest. The default-action is what happens if none of the previous entries are matched – in this case it is a black-list ip-filter, since anything we don’t specifically drop will get forwarded
Each filter entry has a number which is used for the ascending evaluation order (entry 10 before entry 20 here) and usually has a match entry and an action to perform when the match was successful. This filter is relatively simple since all it is doing is blocking IP packets that either have source or destination IP addresses from RFC1918 space.

The interesting thing is the embed-filter flowspec entry. Router “Base” is the base routing instance (as opposed to a VPRN) and offset 1000 means that any flowspec entries will be dynamically added to ip-filter 100 starting at entry 1000 (and with an additional offset determined by flowspec)

This filter will be applied to the IP interface facing the external router – This interface is associated with an Internet Enhanced Service (IES) associated with the SR1’s Global Routing Table (Router “Base”)

*A:SR1>config>service>ies# /configure service ies 1
*A:SR1>config>service>ies# info
----------------------------------------------
            interface "External" create
                address 200.200.200.1/24
                sap 1/1/1 create
                exit
            exit
            no shutdown
----------------------------------------------
*A:SR1>config>service>ies# show router route-table

===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric
-------------------------------------------------------------------------------
1.1.1.1/32                                    Local   Local     00h20m17s  0
       Loop_1                                                       0
0.0.0.0/0                                     Remote  Static    00h20m02s  5
       200.200.200.2                                                1
123.123.123.123/32                            Local   Local     00h20m17s  0
       system                                                       0
192.168.1.0/24                                Local   Local     00h20m02s  0
       NetOps                                                       0
200.200.200.0/24                              Local   Local     00h20m02s  0
       External                                                     0
-------------------------------------------------------------------------------
No. of Routes: 5
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available

In this contrived example SR1 just has a default route point to the External interface in IES 1.
Before we apply the IP filter – check to see we can reach an RFC1918 IP Address:
A:External# ping 1.1.1.1 source 172.16.0.1 count 2
PING 1.1.1.1 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.40ms.
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.91ms.

---- 1.1.1.1 PING Statistics ----
2 packets transmitted, 2 packets received, 0.00% packet loss
round-trip min = 1.40ms, avg = 1.66ms, max = 1.91ms, stddev = 0.253ms

Apply the IP Filter in the ingress direction of interface External on SR1:
*A:SR1>config>service>ies# interface "External" sap 1/1/1 ingress filter ip 100
*A:SR1>config>service>ies# info
----------------------------------------------
            interface "External" create
                address 200.200.200.1/24
                sap 1/1/1 create
                    ingress
                        filter ip 100
                    exit
                exit
            exit
            no shutdown

And repeat the test:
*A:External# ping 1.1.1.1 source 172.16.0.1 count 2
PING 1.1.1.1 56 data bytes
Request timed out. icmp_seq=1.
Request timed out. icmp_seq=2.

---- 1.1.1.1 PING Statistics ----
2 packets transmitted, 0 packets received, 100% packet loss

We can see the ping failed and if we look at the counters
*A:SR1>config>service>ies# show filter ip 100 counters

===============================================================================
IP Filter
===============================================================================
Filter Id           : 100                          Applied        : Yes
Scope               : Template                     Def. Action    : Forward
System filter       : Unchained
Radius Ins Pt       : n/a
CrCtl. Ins Pt       : n/a
RadSh. Ins Pt       : n/a
PccRl. Ins Pt       : n/a
Entries             : 2
Sub-Entries         : 6
Description         : (Not Specified)
-------------------------------------------------------------------------------
Filter Match Criteria : IP
-------------------------------------------------------------------------------
Entry               : 10
Ing. Matches        : 2 pkts (204 bytes)
Egr. Matches        : 0 pkts

Entry               : 20
Ing. Matches        : 0 pkts
Egr. Matches        : 0 pkts

===============================================================================
We can see the ping was unsuccessful because of entry 10 stopping traffic coming back to SR1 (because we weren’t filtering traffic leaving SR1)

Now all of a sudden we find a ping flood (well okay, calling two packets a flood is a rather long bow to draw but anyway) is coming from 100.100.100.100 and hitting 1.1.1.1

A:External# ping 1.1.1.1 source 100.100.100.100 count 2
PING 1.1.1.1 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.16ms.
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.26ms.

These ICMP packets are causing havok to 1.1.1.1, so it would be nice to add some precision filtering to stop that from occuring, while allowing other traffic through – this is where our GoBGP instance and flowspec comes back into the story. We will ask gobgp to announce a flowspec “route” that specifies a discard action (actually a rate-limit of 0 kbps) for traffic from 100.100.100.100 to 1.1.1.1 using ICMP:
adam@m4600:~$ gobgp global rib add -a ipv4-flowspec match source 100.100.100.100/32 destination 1.1.1.1/32 protocol icmp then discard
SR1 can confirm it recieved this route:
*A:SR1>config>service>ies# show router bgp routes flow-ipv4
===============================================================================
 BGP Router ID:123.123.123.123  AS:64512       Local AS:64512
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP FLOW IPV4 Routes
===============================================================================
Flag  Network             Nexthop                 LocalPref       MED
      As-Path
-------------------------------------------------------------------------------
u*>?  --                  0.0.0.0                 100             None
      No As-Path

      Community Action:  rate-limit: 0 kbps
      NLRI Subcomponents:
      Dest Pref : 1.1.1.1/32
      Src Pref  : 100.100.100.100/32
      Ip Proto  : [ == 1 ]
-------------------------------------------------------------------------------
Routes : 1
===============================================================================

Flowspec can do quite interesting things, besides rate-limiting traffic to 0kbps (dropping it), it’s possible to use flowspec to tell the router to rate limit flows rather than completely blocking, remark traffic to a different level of priority or even redirect traffic to a VRF by setting the appropriate route targets (this could for example allow the forwarding of traffic into a VPRN or VRF to reach a scrubbing network prior to re-injection of clean traffic back into the network)

Lets see if ip filter has taken this flowspec entry:

*A:SR1>config>service>ies# show filter ip 100

===============================================================================
IP Filter
===============================================================================
Filter Id           : 100                          Applied        : Yes
Scope               : Template                     Def. Action    : Forward
System filter       : Unchained
Radius Ins Pt       : n/a
CrCtl. Ins Pt       : n/a
RadSh. Ins Pt       : n/a
PccRl. Ins Pt       : n/a
Entries             : 2/0/0/1 (Fixed/Radius/Cc/Embedded)
Sub-Entries         : 6/0/0/1
Description         : (Not Specified)
-------------------------------------------------------------------------------
Filter Match Criteria : IP
-------------------------------------------------------------------------------
Entry               : 10
Description         : (Not Specified)
Log Id              : n/a
Src. IP             : ip-prefix-list "FPL_RFC1918"
Src. Port           : n/a
Dest. IP            : 0.0.0.0/0
Dest. Port          : n/a
Protocol            : Undefined                    Dscp           : Undefined
ICMP Type           : Undefined                    ICMP Code      : Undefined
Fragment            : Off                          Src Route Opt  : Off
Sampling            : Off                          Int. Sampling  : On
IP-Option           : 0/0                          Multiple Option: Off
TCP-syn             : Off                          TCP-ack        : Off
Option-pres         : Off
Egress PBR          : Disabled
Primary Action      : Drop
Ing. Matches        : 2 pkts (204 bytes)
Egr. Matches        : 0 pkts

Entry               : 20
Description         : (Not Specified)
Log Id              : n/a
Src. IP             : 0.0.0.0/0
Src. Port           : n/a
Dest. IP            : ip-prefix-list "FPL_RFC1918"
Dest. Port          : n/a
Protocol            : Undefined                    Dscp           : Undefined
ICMP Type           : Undefined                    ICMP Code      : Undefined
Fragment            : Off                          Src Route Opt  : Off
Sampling            : Off                          Int. Sampling  : On
IP-Option           : 0/0                          Multiple Option: Off
TCP-syn             : Off                          TCP-ack        : Off
Option-pres         : Off
Egress PBR          : Disabled
Primary Action      : Drop
Ing. Matches        : 0 pkts
Egr. Matches        : 0 pkts

Entry               : 1256
Origin              : Inserted by embedded filter fSpec-0 entry 256
Description         : (Not Specified)
Log Id              : n/a
Src. IP             : 100.100.100.100/32
Src. Port           : n/a
Dest. IP            : 1.1.1.1/32
Dest. Port          : n/a
Protocol            : 1                            Dscp           : Undefined
ICMP Type           : Undefined                    ICMP Code      : Undefined
Fragment            : Off                          Src Route Opt  : Off
Sampling            : Off                          Int. Sampling  : On
IP-Option           : 0/0                          Multiple Option: Off
TCP-syn             : Off                          TCP-ack        : Off
Option-pres         : Off
Egress PBR          : Disabled
Primary Action      : Drop
Ing. Matches        : 0 pkts
Egr. Matches        : 0 pkts

===============================================================================
We had specified that the offset for flowspec was 1000, this flowspec entry (number 256) became ip filter 100 entry 256. Time to verify that the ping now should fail:
*A:External# ping 1.1.1.1 source 100.100.100.100 count 2
PING 1.1.1.1 56 data bytes
Request timed out. icmp_seq=1.
Request timed out. icmp_seq=2.

---- 1.1.1.1 PING Statistics ----
2 packets transmitted, 0 packets received, 100% packet loss

Yes, and we can verify that it’s only blocking icmp between those endpoints by sending IP packets from another protocol say UDP by doing a traceroute:
*A:External# traceroute 1.1.1.1 source 100.100.100.100
traceroute to 1.1.1.1 from 100.100.100.100, 30 hops max, 40 byte packets
  1  1.1.1.1 (1.1.1.1)    1.74 ms  1.51 ms  1.52 ms
Yes, this is pretty good as far as network based filters (that aren’t performing payload based inspection) are doing, there’s quite a few match conditions that can be used to narrow things down even further. In this contrived example it may be similar effort to configure a filter on the fly but in a production environment, you could hook GoBGP to your route reflector and through a single procedure push updates to all your edge routers in one go. Another good thing about this method, is if the filtering is only temporary, it’s just as easy to remove as it was to put in.
To see what’s currently in the rib for ipv4-flowspec:
adam@m4600:~$ gobgp global rib  -a ipv4-flowspec
    Network                                                              Next Hop             AS_PATH              Age        Attrs
*>  [destination:1.1.1.1/32][source:100.100.100.100/32][protocol:==icmp ]fictitious                                00:12:06   [{Origin: ?} {Extcomms: [discard]}]
Withdraw the announcement:
adam@m4600:~$ gobgp global rib del -a ipv4-flowspec match source 100.100.100.100/32 destination 1.1.1.1/32 protocol icmp then discard
adam@m4600:~$ gobgp global rib  -a ipv4-flowspec                                Network not in table

Verify SR1 ip filter 100 no longer has the entry:
*A:SR1>config>service>ies# show filter ip 100

===============================================================================
IP Filter
===============================================================================
Filter Id           : 100                          Applied        : Yes
Scope               : Template                     Def. Action    : Forward
System filter       : Unchained
Radius Ins Pt       : n/a
CrCtl. Ins Pt       : n/a
RadSh. Ins Pt       : n/a
PccRl. Ins Pt       : n/a
Entries             : 2
Sub-Entries         : 6
Description         : (Not Specified)
-------------------------------------------------------------------------------
Filter Match Criteria : IP
-------------------------------------------------------------------------------
Entry               : 10
Description         : (Not Specified)
Log Id              : n/a
Src. IP             : ip-prefix-list "FPL_RFC1918"
Src. Port           : n/a
Dest. IP            : 0.0.0.0/0
Dest. Port          : n/a
Protocol            : Undefined                    Dscp           : Undefined
ICMP Type           : Undefined                    ICMP Code      : Undefined
Fragment            : Off                          Src Route Opt  : Off
Sampling            : Off                          Int. Sampling  : On
IP-Option           : 0/0                          Multiple Option: Off
TCP-syn             : Off                          TCP-ack        : Off
Option-pres         : Off
Egress PBR          : Disabled
Primary Action      : Drop
Ing. Matches        : 2 pkts (204 bytes)
Egr. Matches        : 0 pkts

Entry               : 20
Description         : (Not Specified)
Log Id              : n/a
Src. IP             : 0.0.0.0/0
Src. Port           : n/a
Dest. IP            : ip-prefix-list "FPL_RFC1918"
Dest. Port          : n/a
Protocol            : Undefined                    Dscp           : Undefined
ICMP Type           : Undefined                    ICMP Code      : Undefined
Fragment            : Off                          Src Route Opt  : Off
Sampling            : Off                          Int. Sampling  : On
IP-Option           : 0/0                          Multiple Option: Off
TCP-syn             : Off                          TCP-ack        : Off
Option-pres         : Off
Egress PBR          : Disabled
Primary Action      : Drop
Ing. Matches        : 0 pkts
Egr. Matches        : 0 pkts

===============================================================================
Entry 1256 has left the building.

Hopefully that was a reasonable introduction to using BGP Flowspec with filtering and GoBGP.

Flowspec is quite often a piece of the puzzle in DDoS mitigation tools, usually there is some kind of automation attached which makes decisions using inputs such a Netflow/IPFIX data, SNMP polling of interfaces to track anomalous loading and in some cases threat intelligence feeds from security vendors.

TACACS+ Authentication with Nokia Service Routers

Nokia SROS supports the use of AAA for a range of tasks, some of the more interesting and complicated are related to subscriber management when the Service Router is acting as a Broadband Network Gateway (BNG) however AAA is also useful for the network operations teams to provide centralised authentication for a fleet of routers where managing individual local accounts is not really something to contemplate.

SROS supports the use of RADIUS or TACACS+ for this management access control and today TACACS+ will be the method used with a linux daemon based on code from http://www.shrubbery.net/tac_plus/ which will be configured to support a Nokia Service Router (however this configuration would be quite Cisco IOS friendly) and the SROS router will use TACACS+ for authentication and identifying what access rights the user has my mapping using profiles.

Nokia SR and TACACS+ Server Test Topology

As you can see above, R1 (instantiated service router in eve-ng) has port 1/1/3 bridged to the internal Ethernet of the computer running eve-ng so both the router interface and the internal Ethernet are on the same IP subnet allowing connectivity to the TACACS+ server that will be run on the laptop.

To install the TACACS+ software, as eve-ng is built on Ubuntu 16.04, installation is as simple as invoking:
root@m4600:~# apt-get install tacacs+
The config was then modified to look like below:

root@m4600:~# cat /etc/tacacs+/tac_plus.conf
# shared secret with TACACS client
key = "tac_secret"
# Set where to send accounting records
accounting syslog;
accounting file = /var/log/tac_plus/tac_plus.acct

acl = mgmt_acl {
        # regex to allow access hosts from 192.168.1.0/24
        permit = 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4])
}

# administrative group, priv-lvl 15 to be mapped to SROS administative profile
group = administrative {
        default service = permit
        expires = "Jan 1 2020"
        acl = mgmt_acl
        service = exec {
         priv-lvl = 15
        }
}
# limited group, priv-lvl 1 to be mapped to SROS limited profile
group = limited {
        default service = permit
        expires = "Jan 1 2020"
        acl = mgmt_acl
        service = exec {
         priv-lvl = 1
        }
}

# our tacacs test accounts
# des password is generated by running tac_pwd on the plaintext
user = testadmin {
        member = administrative
        login = des JZ1fHFoSp.v/E
        # plaintext password = pass
}

user = testlimited {
        member = limited
        login = des O8ZepJOyIIuYo
        # plaintext password = test
}

A couple of the key things here besides the key which is the shared secret between the TACACS+ server and the router is that there are two groups defined administrative and limited, where the only difference is the priv-lvl. With Cisco platforms, this is what is used for TACACS+ uses during the authorisation stage to tell IOS what access rights a user has. SROS is able to map this to a “profile”.

Out of the box, SROS has two built in profiles, administrative (used for most installation and commissioning activities) and default which is somewhat less capable, however it is possible to define specific profiles in line with the roles of your users. In the config above there is a group called limited which will be identified by priv-lvl 1.

On R1 we can define a custom profile in the system security configuration context:

A:R1# /configure system security profile "limited"
A:R1>config>system>security>profile# info
----------------------------------------------
                default-action deny-all
                entry 10
                    match "show router route-table"
                    action permit
                exit
                entry 20
                    match "show users"
                    action permit
                exit
                entry 30
                    match "show system security user"
                    action permit
                exit
                entry 40
                    match "logout"
                    action permit
                exit
This example is certainly quite limited in what can be done due to the default-action deny-all, requiring specific white-listing of commands
To enable TACACS+ support on the router we first need to configure the TACACS server using the aggreed shared secret (configuring the timeout is optional but it specifies how many seconds we shall wait for a response – if the server is down, this is effectively how long you will wait to fall back to local authentication)
A:R1>config>system>security>profile# /configure system security tacplus
*A:R1>config>system>security>tacplus$ server 1 address 192.168.1.47 secret "tac_secret"
*A:R1>config>system>security>tacplus$ timeout 5

Now to create the priv-lvl mapping to profiles:
*A:R1>config>system>security>tacplus$ priv-lvl-map
A:R1>config>system>security>tacplus$ priv-lvl-map
A:R1>config>system>security>tacplus>priv$ priv-lvl 1 "limited"
A:R1>config>system>security>tacplus>priv$ priv-lvl 15 "administrative"

We also need to enable authorisation to be associated with these mappings:
A:R1>config>system>security>tacplus>priv$ back
A:R1>config>system>security>tacplus$ authorization use-priv-lvl

Now to actually enable tacacs authentication, within the password context we specify the authentication order to include the methods we prefer.
*A:R1>config>system>security>tacplus$ /configure system security password
*A:R1>config>system>security>password# authentication-order tacplus local exit-on-reject

If TACACS+ is unavailable, we fall back to local authentication accounts – if we hadn’t include “exit-on-reject”, a failed authentication attempt with TACACS+ (reject) would move onto the next authentication mechanisms (local)

SROS performs a AAA server health check by sending dummy authentication requests to a server and determines if the server is alive based on obtaining a response, this can end up with the authentication logs getting a lot of failed access attempts, however it can be disabled if desired:
*A:R1>config>system>security>password# no health-check
For this testing, I’ll be using telnet, so I need to enable the telnet-server (outside of a lab, I would not suggest this at all!)

*A:R1>config>system>security>password# back
*A:R1>config>system>security# telnet-server

So to recap the router configuration:
*A:R1>config>system>security# info
----------------------------------------------
            telnet-server
            profile "limited"
                default-action deny-all
                entry 10
                    match "show router route-table"
                    action permit
                exit
                entry 20
                    match "show users"
                    action permit
                exit
                entry 30
                    match "show system security user"
                    action permit
                exit
                entry 40
                    match "logout"
                    action permit
                exit
            exit
            password
                authentication-order tacplus local exit-on-reject
                no health-check
            exit
            tacplus
                authorization use-priv-lvl
                priv-lvl-map
                    priv-lvl 1 "limited"
                    priv-lvl 15 "administrative"
                exit
                timeout 5
                server 1 address 192.168.1.47 secret "1mSYRiobfhHAdFA9cZH3wBviQtXKFDld" hash2
            exit

Time to test if this works. Start the tacacs service on (m4600 has the IP of 192.168.1.47 which is what R1 will be communicating with)
root@m4600:~# tac_plus -d 16 -L -C /etc/tacacs+/tac_plus.conf
And start viewing syslog
root@m4600:~# tail -f /var/log/syslog
May 14 14:39:14 m4600 tac_plus[28164]: Reading config
May 14 14:39:14 m4600 tac_plus[28164]: Version F4.0.4.27a Initialized 1
May 14 14:39:14 m4600 tac_plus[28164]: tac_plus server F4.0.4.27a starting
May 14 14:39:14 m4600 tac_plus[28165]: Backgrounded
May 14 14:39:14 m4600 tac_plus[28166]: socket FD 0 AF 2
May 14 14:39:14 m4600 tac_plus[28166]: socket FD 2 AF 10
May 14 14:39:14 m4600 tac_plus[28166]: uid=0 euid=0 gid=0 egid=0 s=-1637085952

Open up another session on m4600 and telnet to 192.168.1.123 using the credentials of testadmin/pass:
May 14 14:39:23 m4600 tac_plus[28201]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:39:23 m4600 tac_plus[28201]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:39:23 m4600 tac_plus[28201]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:39:23 m4600 tac_plus[28201]: host ACLs for user 'testadmin' permit
May 14 14:39:23 m4600 tac_plus[28201]: login query for 'testadmin' port console from 192.168.1.123 accepted
May 14 14:39:23 m4600 tac_plus[28202]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:39:23 m4600 tac_plus[28202]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:39:23 m4600 tac_plus[28202]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:39:23 m4600 tac_plus[28202]: host ACLs for user 'testadmin' permit
May 14 14:39:23 m4600 tac_plus[28202]: authorization query for 'testadmin' console from 192.168.1.123 accepted

Lets go back to the telnet session and check who we are and our access rights:
*A:R1# show users
===============================================================================
User                             Type    Login time             Idle time
  From
===============================================================================
                                 Console       --               0d 00:00:21
  --
testadmin                        Telnet  14MAY2017 04:41:41     0d 00:00:00
  192.168.1.47
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================
*A:R1>config>system>security# show system security user testadmin detail

===============================================================================
Users
===============================================================================
User ID      New User Permissions            Password   Login    Failed   Local
             Pwd console ftp li snmp netconf Expires    Attempts Logins   Conf
-------------------------------------------------------------------------------
testadmin    n   y       n   n  n    n       never      1        0        n
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================

===============================================================================
Temporary User Configuration Detail
===============================================================================
===============================================================================
user id            : testadmin
-------------------------------------------------------------------------------
console parameters
-------------------------------------------------------------------------------
new pw required    : n/a                cannot change pw   : n/a
home directory     :
restricted to home : no
login exec file    :
profile            : administrative
locked-out         : no
===============================================================================

Okay, that’s good. Lets log out and log back in R1 using the credentials of testlimited/test:
May 14 14:43:37 m4600 tac_plus[29058]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:43:37 m4600 tac_plus[29058]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:43:37 m4600 tac_plus[29058]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:43:37 m4600 tac_plus[29058]: host ACLs for user 'testlimited' permit
May 14 14:43:37 m4600 tac_plus[29058]: login query for 'testlimited' port telnet from 192.168.1.123 accepted
May 14 14:43:37 m4600 tac_plus[29059]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:43:37 m4600 tac_plus[29059]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:43:37 m4600 tac_plus[29059]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:43:37 m4600 tac_plus[29059]: host ACLs for user 'testlimited' permit
May 14 14:43:37 m4600 tac_plus[29059]: authorization query for 'testlimited' telnet from 192.168.1.123 accepted

Looks promising from the TACACS server, lets go back to the telnet session and check who we are and our access rights:
*A:R1# show users
===============================================================================
User                             Type    Login time             Idle time
  From
===============================================================================
                                 Console       --               0d 00:04:55
  --
testlimited                      Telnet  14MAY2017 04:43:36     0d 00:00:00
  192.168.1.47
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================
*A:R1# show router route-table

===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric
-------------------------------------------------------------------------------
192.168.1.0/24                                Local   Local     01h07m25s  0
       TACACS                                                       0
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================
*A:R1# admin display-config
MINOR: CLI Command not allowed for this user.

Certainly appears to be a limited user,

*A:R1# show system security user testlimited detail

===============================================================================
Users
===============================================================================
User ID      New User Permissions            Password   Login    Failed   Local
             Pwd console ftp li snmp netconf Expires    Attempts Logins   Conf
-------------------------------------------------------------------------------
testlimited  n   y       n   n  n    n       never      1        0        n
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================

===============================================================================
Temporary User Configuration Detail
===============================================================================
===============================================================================
user id            : testlimited
-------------------------------------------------------------------------------
console parameters
-------------------------------------------------------------------------------
new pw required    : n/a                cannot change pw   : n/a
home directory     :
restricted to home : no
login exec file    :
profile            : limited
locked-out         : no
===============================================================================

Okay, so we’re correctly associated with the limited profile account.

Role based access control is a good idea for managing your network and being able to leverage your existing AAA infrastructure helps make operating a heterogeneous network that little bit easier.

Route aggregation is not always straight forward

Today’s post is a simple 3 router topology based on a true story when route aggregation didn’t appear to working as expected at first glance and some additional thought was required as to why things were behaving that way and what was required to make it do what I wanted.

I’m using 3 x Nokia VSR-Sims running SROS 14.0R4, and while the concepts discussed here are definitely flavoured through a SROS lens, the concepts will be familiar to different router platforms and their associated operating systems.

R1 and R2 are in BGP AS 12 and use ospf to advertise their respective system addresses which are used for their IBGP peerings

configure
    system
        name "R1"
    exit
    card 1
        card-type iom3-xp-b
        mda 1
            mda-type m5-1gb-sfp-b
            no shutdown               
        exit
        no shutdown
    exit
    port 1/1/1
        ethernet
        exit
        no shutdown
    exit
    router
        interface "Loop"
            address 100.100.100.1/24
            loopback
            no shutdown
        exit
        interface "R2"
            address 10.1.2.1/27
            port 1/1/1
            no shutdown
        exit
        interface "system"
            address 1.1.1.1/32
            no shutdown
        exit
        autonomous-system 12
        ospf 0
            area 0.0.0.0
                interface "system"
                    no shutdown
                exit
                interface "R2"        
                    no shutdown
                exit
            exit
            no shutdown
        exit
        policy-options
            begin
            prefix-list "PL_LOOP"
                prefix 100.100.100.0/24 exact
            exit
            policy-statement "PS_LOOP_EXP"
                entry 10
                    from
                        protocol direct
                        prefix-list "PL_LOOP"
                    exit
                    action accept
                    exit              
                exit                  
            exit                      
            commit                    
        exit
        bgp
            group "IBGP"
                export "PS_LOOP_EXP"
                peer-as 12
                neighbor 2.2.2.2
                exit
            exit
            no shutdown
        exit
    exit
exit all

configure
    system
        name "R2"
    exit
    card 1
        card-type iom3-xp-b
        mda 1
            mda-type m5-1gb-sfp-b
            no shutdown               
        exit
        no shutdown
    exit
    port 1/1/1
        ethernet
        exit
        no shutdown
    exit
    port 1/1/2
        ethernet
        exit
        no shutdown
    exit
    router
        interface "R1"
            address 10.1.2.2/27
            port 1/1/1
            no shutdown
        exit
        interface "R3"
            address 10.2.3.2/27
            port 1/1/2
            no shutdown
        exit
        interface "system"
            address 2.2.2.2/32
            no shutdown
        exit
        autonomous-system 12          
        router-id 2.2.2.2
        ospf 0
            area 0.0.0.0
                interface "system"
                    no shutdown
                exit
                interface "R1"
                    no shutdown
                exit
            exit
            no shutdown
        exit
    exit
        bgp
            group "IBGP"
                peer-as 12
                neighbor 1.1.1.1
                exit
            exit
            no shutdown
        exit
    exit
exit all

R3 which is in BGP AS 3 will be peering with R2. While we can configure R2, as R3 is in a different AS, we cannot touch it nor modify its configuration. R3 is already configured to peer with R2 and is waiting for R2 to come online.

Our configuration for R2 to establish the BGP Session:

A:R2# configure router bgp 
A:R2>config>router>bgp# group EBGP 
*A:R2>config>router>bgp>group$ neighbor 10.2.3.3 peer-as 3 
*A:R2>config>router>bgp>group$ exit all 

Assuming enough time has passed for BGP to come up, lets get a quick state of play with BGP on R2:

*A:R2# show router bgp summary | match "BGP Sum" post-lines 100  
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
                   AS PktRcvd InQ  Up/Down   State|Rcv/Act/Sent (Addr Family)
                      PktSent OutQ
-------------------------------------------------------------------------------
1.1.1.1
               12          11    0 00h03m30s 1/1/0 (IPv4)
                           10    0           
10.2.3.3
               3            6    0 00h00m34s 8/8/1 (IPv4)
                            5    0           
-------------------------------------------------------------------------------

Right now R2 has active BGP sessions with R1 and R3 – we can see that R2 has received 8 routes from R3 and has sent 1 (from R1). R2 hasn’t yet sent any routes learnt from R3 to R1 however this should happen shortly.

These are the BGP routes that R2 knows of

*A:R2# show router bgp routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
u*>i  3.0.0.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.1.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.2.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.3.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.4.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.5.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.6.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.7.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  100.100.100.0/24                                   100         None
      1.1.1.1                                            None        -
      No As-Path                                                      
-------------------------------------------------------------------------------
Routes : 9
===============================================================================

As this post is about route aggregation, on R2 we want to send a summary route through to R1 (3.0.0.0/21) instead of all the individual routes. To do this we will create the aggregate route and specify it to be a summary-only route and because we can, we will include the AS-Set in the aggregate so R1 knows these came from AS 3
*A:R2# configure router aggregate 3.0.0.0/21 summary-only as-set description "Aggregate from AS3"
*A:R2# show router aggregate detail 

===============================================================================
Legend: G - generate-icmp enabled
===============================================================================
Aggregate Route Table (Router: Base)
===============================================================================
Prefix           : 3.0.0.0/21
Description      : Aggregate from AS3
Summary          : True           AS Set           : True
Aggr AS          : 0              Aggr IP-Address  : 0.0.0.0
Aggr OperState   : Active         
Nexthop Type     : None           Nexthop          :    
Community        :                
-------------------------------------------------------------------------------
No. of Aggregate Routes: 1
==============================================================================="

We can see the aggregate appear in the routing table as a blackhole route from protocol aggregate
*A:R2# show router route-table 

===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric   
-------------------------------------------------------------------------------
1.1.1.1/32                                    Remote  OSPF      00h10m16s  10
       10.1.2.1                                                     100
2.2.2.2/32                                    Local   Local     00h11m14s  0
       system                                                       0
3.0.0.0/21                                    Blackh* Aggr      00h02m13s  130
       Black Hole                                                   0
3.0.0.0/24                                    Remote  BGP       00h05m59s  170
       10.2.3.3                                                     0
3.0.1.0/24                                    Remote  BGP       00h05m59s  170
       10.2.3.3                                                     0
3.0.2.0/24                                    Remote  BGP       00h05m59s  170
       10.2.3.3                                                     0
3.0.3.0/24                                    Remote  BGP       00h05m59s  170
       10.2.3.3                                                     0
3.0.4.0/24                                    Remote  BGP       00h05m59s  170
       10.2.3.3                                                     0
3.0.5.0/24                                    Remote  BGP       00h06m00s  170
       10.2.3.3                                                     0
3.0.6.0/24                                    Remote  BGP       00h06m00s  170
       10.2.3.3                                                     0
3.0.7.0/24                                    Remote  BGP       00h06m00s  170
       10.2.3.3                                                     0
10.1.2.0/27                                   Local   Local     00h11m00s  0
       R1                                                           0
10.2.3.0/27                                   Local   Local     00h11m00s  0
       R3                                                           0
100.100.100.0/24                              Remote  BGP       00h08m53s  170
       10.1.2.1                                                     0
-------------------------------------------------------------------------------
No. of Routes: 14
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================
* indicates that the corresponding row element may have been truncated.

As we can see in the routing table, an aggregate route is treated as its own routing protocol, so we need to develop a routing policy to advertise the aggregate to R1
*A:R2# configure router policy-options 
*A:R2>config>router>policy-options# begin 
*A:R2>config>router>policy-options# policy-statement PS_AGGREGATE 
*A:R2>config>router>policy-options>policy-statement$ entry 10 from protocol aggregate 
*A:R2>config>router>policy-options>policy-statement$ entry 10 action accept 
*A:R2>config>router>policy-options>policy-statement>entry>action$ exit 
*A:R2>config>router>policy-options>policy-statement$ info 
----------------------------------------------
                entry 10
                    from
                        protocol aggregate
                    exit
                    action accept
                    exit
                exit
----------------------------------------------
*A:R2>config>router>policy-options>policy-statement$ exit 
*A:R2>config>router>policy-options# commit

We then can use the policy to export to our neighbor (using group IBGP or on the neighbor directly)
*A:R2>config>router>policy-options# /configure router bgp group "IBGP"     
*A:R2>config>router>bgp>group# export "PS_AGGREGATE"

One thing we haven’t done yet is that the EBGP next-hop 10.2.3.3 will not be visible to R1, so we can either add that interface into OSPF (as a passive interface so we don’t attempt to peer with an external router at the IGP level) or have R2 set next-hop-self (I generally prefer this as it keeps the IGP just for internal core links)
*A:R2>config>router>bgp>group# next-hop-self 
*A:R2>config>router>bgp>group# info 
----------------------------------------------
                next-hop-self
                export "PS_AGGREGATE" 
                peer-as 12
                neighbor 1.1.1.1
                exit
----------------------------------------------

Okay, so now R1 should have 3.0.0.0/21 and the job is done, so lets verify this is working on R1
A:R1# show router route-table 

===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric   
-------------------------------------------------------------------------------
1.1.1.1/32                                    Local   Local     00h18m48s  0
       system                                                       0
2.2.2.2/32                                    Remote  OSPF      00h17m57s  10
       10.1.2.2                                                     100
10.1.2.0/27                                   Local   Local     00h18m32s  0
       R2                                                           0
100.100.100.0/24                              Local   Local     00h18m48s  0
       Loop                                                         0
-------------------------------------------------------------------------------
No. of Routes: 4
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================

3.0.0.0/21 is not present, so something is wrong here. What is R2 sending to R1?
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================

Nothing – let’s double check our policy
*A:R2>config>router>bgp>group# show router policy "PS_AGGREGATE" 
    entry 10
        from
            protocol aggregate
        exit
        action accept
        exit
    exit
*A:R2>config>router>bgp>group# show router aggregate 

===============================================================================
Legend: G - generate-icmp enabled
===============================================================================
Aggregates (Router: Base)
===============================================================================
Prefix                                          Aggr IP-Address   Aggr AS
   Summary                                         AS Set          State
     NextHop                                         Community     NextHopType
-------------------------------------------------------------------------------
3.0.0.0/21                                      0.0.0.0           0
   True                                            True            Active
                                                                      None
-------------------------------------------------------------------------------
No. of Aggregates: 1
===============================================================================

Well that looks okay but maybe the aggregate route is wrong
*A:R2>config>router>bgp>group# /admin display-config | match expression "^\ +agg"
        aggregate 3.0.0.0/21 summary-only as-set description "Aggregate from AS3"

Lets try it without including the summary-only option and see if the contributing routes will get advertised to R1.
*A:R2>config>router>bgp>group# /configure router aggregate 3.0.0.0/21 as-set description "Agg AS3 no summary-only"
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
i     3.0.0.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.1.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.3.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.4.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.5.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.6.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.7.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
-------------------------------------------------------------------------------
Routes : 7
===============================================================================

We are only sending 7 routes but we received 8 from R3!
*A:R2>config>router>bgp>group# show router bgp neighbor 10.2.3.3 received-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
u*>i  3.0.0.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.1.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.2.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.3.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.4.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.5.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.6.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.7.0/24                                         n/a         None
      10.2.3.3                                           None        -
      3                                                               
-------------------------------------------------------------------------------
Routes : 8
===============================================================================

So what is it about 3.0.2.0/24?
*A:R2>config>router>bgp>group# show router bgp routes 3.0.2.0/24 detail 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Original Attributes
 
Network        : 3.0.2.0/24
Nexthop        : 10.2.3.3
Path Id        : None                   
From           : 10.2.3.3
Res. Nexthop   : 10.2.3.3
Local Pref.    : n/a                    Interface Name : R3
Aggregator AS  : None                   Aggregator     : None
Atomic Aggr.   : Not Atomic             MED            : None
AIGP Metric    : None                   
Connector      : None                 
Community      : no-advertise
Cluster        : No Cluster Members
Originator Id  : None                   Peer Router Id : 3.3.3.3
Fwd Class      : None                   Priority       : None
Flags          : Used  Valid  Best  IGP  
Route Source   : External
AS-Path        : 3 
Route Tag      : 0                      
Neighbor-AS    : 3
Orig Validation: NotFound               
Source Class   : 0                      Dest Class     : 0
Add Paths Send : Default                
Last Modified  : 03h55m28s              
 
Modified Attributes
 
Network        : 3.0.2.0/24
Nexthop        : 10.2.3.3
Path Id        : None                   
From           : 10.2.3.3
Res. Nexthop   : 10.2.3.3
Local Pref.    : None                   Interface Name : R3
Aggregator AS  : None                   Aggregator     : None
Atomic Aggr.   : Not Atomic             MED            : None
AIGP Metric    : None                   
Connector      : None
Community      : no-advertise
Cluster        : No Cluster Members
Originator Id  : None                   Peer Router Id : 3.3.3.3
Fwd Class      : None                   Priority       : None
Flags          : Used  Valid  Best  IGP  
Route Source   : External
AS-Path        : 3 
Route Tag      : 0                      
Neighbor-AS    : 3
Orig Validation: NotFound               
Source Class   : 0                      Dest Class     : 0
Add Paths Send : Default                
Last Modified  : 03h55m30s              
 
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Routes : 1
===============================================================================

3.0.2.0/24 has no-advertise attached to it!
One of the things about aggregate routes is that they aggregate the associated communities as well, so the aggregate route will have no-advertise attached to it, so it will not be advertised to R1.
Unfortunately this doesn’t appear in the show “show router aggregate detail” – the community there is the one that is manually added during the creation of the aggregate.
So how can we fix this? Well there are two methods that spring to mind and I am sure that there are more.

Option 1 – Create an import policy on R2 that just drops the no-advertise community on imported routes.
I think this is the easiest option to implement because then the normal aggregate configuration will work.

*A:R2>config>router>bgp>group# /configure router policy-options 
*A:R2>config>router>policy-options# begin 
*A:R2>config>router>policy-options# community NO_ADV members no-advertise 
*A:R2>config>router>policy-options# policy-statement PS_IGNORE_NO_ADV 
*A:R2>config>router>policy-options>policy-statement$ entry 10
*A:R2>config>router>policy-options>policy-statement>entry$ from community NO_ADV
*A:R2>config>router>policy-options>policy-statement>entry$ action accept 
*A:R2>config>router>policy-options>policy-statement>entry>action$ community remove "NO_ADV" 
*A:R2>config>router>policy-options>policy-statement>entry>action$ back 
*A:R2>config>router>policy-options>policy-statement>entry$ back 
*A:R2>config>router>policy-options>policy-statement$ info 
----------------------------------------------
                entry 10
                    from
                        community "NO_ADV"
                    exit
                    action accept
                        community remove "NO_ADV"
                    exit
                exit
----------------------------------------------
*A:R2>config>router>policy-options>policy-statement$ back 
*A:R2>config>router>policy-options# commit 
*A:R2>config>router>policy-options# /configure router bgp group "EBGP" 
*A:R2>config>router>bgp>group# neighbor 10.2.3.3 import "PS_IGNORE_NO_ADV"

Let’s see if that has resolved things:
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
i     3.0.0.0/21                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.0.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.1.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.2.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.3.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.4.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.5.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.6.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
i     3.0.7.0/24                                         100         None
      2.2.2.2                                            None        -
      3                                                               
-------------------------------------------------------------------------------
Routes : 9
===============================================================================

Yes, 3.0.2.0/24 is present and because none of the routes that contribute to the aggregate have no-advertise attached, the aggregate is also advertised to R1. So time to change the Aggregate route so it’s back to summary only:
*A:R2>config>router>bgp>group# /configure router aggregate 3.0.0.0/21 summary-only as-set description "Aggregate from AS3"
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes                                        
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
i     3.0.0.0/21                                         100         None
      2.2.2.2                                            None        -
      3                                                               
-------------------------------------------------------------------------------
Routes : 1
===============================================================================

Okay sorted.

Option 2 – Using Static Routes for Aggregation
If we wish to respect the no-advertise binding on 3.0.2.0/24, we can simulate some of the behavior of an aggregate route without caring about no-advertise (or no-export if we are concerned about advertisements outside of our AS).
First we need to remove the import policy on R2 facing R3.

*A:R2>config>router>bgp>group# info 
----------------------------------------------
                neighbor 10.2.3.3
                    import "PS_IGNORE_NO_ADV" 
                    peer-as 3
                exit
----------------------------------------------
*A:R2>config>router>bgp>group# neighbor 10.2.3.3 no import

And remove the aggregate for 3.0.0.0/21
*A:R2>config>router>bgp>group# /configure router no aggregate 3.0.0.0/21
Now we create a static black-hole route with BGP community 12:12 attached to it. We’re attaching the community so we can distinguish between regular static routes and our “aggregate”
A:R2>config>router# static-route-entry 3.0.0.0/21 
*A:R2>config>router>static-route-entry$ black-hole 
*A:R2>config>router>static-route-entry>black-hole$ community 12:12 
*A:R2>config>router>static-route-entry>black-hole$ no shutdown

As a note, SROS Release 14 changed the specific syntax for creating static routes but the concepts generally remain the same for previous SROS versions.
Now we’ll work on the routing policy to advertise our static aggregate route.
First we’ll create a named community that was used for our aggregate:
*A:R2>config>router>static-route-entry$ /configure router policy-options 
*A:R2>config>router>policy-options# begin
*A:R2>config>router>policy-options# community STATIC_AGG members 12:12 

Now we create a prefix list to match the routes that contribute to our aggregate
*A:R2>config>router>policy-options# prefix-list PL_R3_CONTRIB 
*A:R2>config>router>policy-options>prefix-list$ prefix 3.0.0.0/21 longer
*A:R2>config>router>policy-options>prefix-list$ exit

Finally we take the existing PS_AGGREGATE and modify it to work with our static aggregate and drop the contributing routes:
*A:R2>config>router>policy-options# policy-statement "PS_AGGREGATE" 
*A:R2>config>router>policy-options>policy-statement# info 
----------------------------------------------
                entry 10
                    from
                        protocol aggregate
                    exit
                    action accept
                    exit
                exit
*A:R2>config>router>policy-options>policy-statement# entry 10 
*A:R2>config>router>policy-options>policy-statement>entry# from protocol static 
*A:R2>config>router>policy-options>policy-statement>entry# from community "STATIC_AGG"
*A:R2>config>router>policy-options>policy-statement>entry# back 
*A:R2>config>router>policy-options>policy-statement# entry 20 
*A:R2>config>router>policy-options>policy-statement>entry$ from prefix-list "PL_R3_CONTRIB" 
*A:R2>config>router>policy-options>policy-statement>entry$ action drop 
*A:R2>config>router>policy-options>policy-statement>entry>action$ exit 
*A:R2>config>router>policy-options>policy-statement>entry$ exit 
*A:R2>config>router>policy-options>policy-statement# info 
----------------------------------------------
                entry 10
                    from
                        protocol static
                        community "STATIC_AGG"
                    exit
                    action accept
                    exit
                exit
                entry 20
                    from
                        prefix-list "PL_R3_CONTRIB"
                    exit
                    action drop
                    exit
                exit
*A:R2>config>router>policy-options>policy-statement# back 
*A:R2>config>router>policy-options# commit

Lets check what R2 is advertising to R1:
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
?     3.0.0.0/21                                         100         None
      2.2.2.2                                            None        -
      No As-Path                                                      
-------------------------------------------------------------------------------
Routes : 1
===============================================================================

There are a couple of issues with this implementation the AS-Path information is lost (nothing we can do about that) but more importantly, this “aggregate” will stay up even if the contributing routes are not present. To overcome this issue, the static route can be associated with a prefix-list which will be used to determine if the static route can become active. It should be noted that although we already have PL_R3_CONTRIB, it cannot be used here as the prefix list in the static route requires specific prefixes to match against. While matching all possible prefixes could be problematic, in most instances simply matching against a few key prefixes will be sufficient:
*A:R2>config>router>bgp>group# /configure router policy-options 
*A:R2>config>router>policy-options# begin
*A:R2>config>router>policy-options# prefix-list PL_R3_STATIC_AGG_OK  
*A:R2>config>router>policy-options>prefix-list$ prefix 3.0.0.0/24 
*A:R2>config>router>policy-options>prefix-list$ prefix 3.0.7.0/24 
*A:R2>config>router>policy-options>prefix-list$ exit 
*A:R2>config>router>policy-options# commit 

Modify the static route to be up when any of the prefixes in PL_R3_STATIC_AGG_OK are in the routing table:
*A:R2>config>router>policy-options# /configure router static-route-entry 3.0.0.0/21 black-hole prefix-list "PL_R3_STATIC_AGG_OK" any

We can see the route is active and the prefix-list being used to validate:
*A:R2>config>router>policy-options# show router static-route detail 

===============================================================================
Static Route Table (Router: Base)  Family: IPv4
===============================================================================
Prefix           : 3.0.0.0/21
Nexthop          : n/a
Type             : Blackhole
Dynamic BGP      : disabled                        Generate ICMP     : disabled
Interface        : n/a                             Active            : Y
Prefix List      : PL_R3_STATIC_AGG_OK             Prefix List Type  : Any
Metric           : 1                               Preference        : 5
Source Class     : 0                               Dest Class        : 0
Admin  State     : Up                              Tag               : 0
Creation Origin  : manual                          
BFD              : disabled
Community        : 12:12                           
CPE-check        : disabled
-------------------------------------------------------------------------------
No. of Static Routes: 1

===============================================================================

If we shutdown our BGP session to R3, the routes in PL_R3_STATIC_AGG_OK will disappear from the routing table and the static route will be brought out of service
*A:R2>config>router>policy-options# /configure router bgp group "EBGP" 
*A:R2>config>router>bgp>group# shutdown 
*A:R2>config>router>bgp>group# show router static-route detail    

===============================================================================
Static Route Table (Router: Base)  Family: IPv4
===============================================================================
Prefix           : 3.0.0.0/21
Nexthop          : n/a
Type             : Blackhole
Dynamic BGP      : disabled                        Generate ICMP     : disabled
Interface        : n/a                             Active            : N
Prefix List      : PL_R3_STATIC_AGG_OK             Prefix List Type  : Any
Metric           : 1                               Preference        : 5
Source Class     : 0                               Dest Class        : 0
Admin  State     : Up                              Tag               : 0
Creation Origin  : manual                          
BFD              : disabled
Community        : 12:12                           
CPE-check        : disabled
Inactive Reason  : prefix-list match failed
-------------------------------------------------------------------------------
No. of Static Routes: 1

===============================================================================

We can see the static route is down because the prefix-list match has failed and we can confirm that we aren’t advertising this to R1:
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================

So we’ll restore the EBGP session between R2 and R3 and give it enough time to exchange routes again:
*A:R2>config>router>bgp>group# no shutdown              
*A:R2>config>router>bgp>group# show router bgp routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
u*>i  3.0.0.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.1.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.2.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.3.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.4.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.5.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.6.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  3.0.7.0/24                                         None        None
      10.2.3.3                                           None        -
      3                                                               
u*>i  100.100.100.0/24                                   100         None
      1.1.1.1                                            None        -
      No As-Path                                                      
-------------------------------------------------------------------------------
Routes : 9
===============================================================================

The routes from R3 are back, lets confirm the static blackhole is back in service:
*A:R2>config>router>bgp>group# show router static-route detail 

===============================================================================
Static Route Table (Router: Base)  Family: IPv4
===============================================================================
Prefix           : 3.0.0.0/21
Nexthop          : n/a
Type             : Blackhole
Dynamic BGP      : disabled                        Generate ICMP     : disabled
Interface        : n/a                             Active            : Y
Prefix List      : PL_R3_STATIC_AGG_OK             Prefix List Type  : Any
Metric           : 1                               Preference        : 5
Source Class     : 0                               Dest Class        : 0
Admin  State     : Up                              Tag               : 0
Creation Origin  : manual                          
BFD              : disabled
Community        : 12:12                           
CPE-check        : disabled
-------------------------------------------------------------------------------
No. of Static Routes: 1

===============================================================================

Yes, so we should be offering this to R3 again:
*A:R2>config>router>bgp>group# show router bgp neighbor 1.1.1.1 advertised-routes 
===============================================================================
 BGP Router ID:2.2.2.2          AS:12          Local AS:12         
===============================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete

===============================================================================
BGP IPv4 Routes
===============================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
?     3.0.0.0/21                                         100         None
      2.2.2.2                                            None        -
      No As-Path                                                      
-------------------------------------------------------------------------------
Routes : 1
===============================================================================

Yes, the aggregate route is now conditionally advertised.

While this scenario isn’t likely to occur all the time, based on my experience it is something to consider if things are not working quite as expected.