Forming the Aggregate Based on a subset of specific routes

In this example we create an aggregate on a limited set of prefixes. This is not to be confused with the "aggregate plus a subset of more-specific prefixes" as shown with suppress maps in a previous post.

Set up the aggregate map to select only 192.68.10.0.24 via a route-map

RTA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTA(config)#no route-map SET_ATTRIBUTE
RTA(config)#route-map SELECT_MORE_SPECIFIC_ROUTES permit 10
RTA(config-route-map)#match ip add 1
RTA(config-route-map)#acces 1 permit 192.68.10.0 0.0.0.255
RTA(config)#router bgp 3
RTA(config-router)#$0.0 255.255.0.0 as-set adv SELECT_MORE_SPECIFIC_ROUTES
RTA(config-router)#end
RTA#

In the above config:

RTA(config-router)#$0.0 255.255.0.0 as-set adv SELECT_MORE_SPECIFIC_ROUTES

has been trunctuated and the full command is:

aggregate-address 192.68.0.0 255.255.0.0 as-set adv SELECT_MORE_SPECIFIC_ROUTES

Below you will see BGP shows the aggregates path as only 2, where previously we were aggregating addresses also for AS 1.

RTA#sh ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0/16, version 16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.16.1.2 172.16.20.1 172.16.220.2
2, (aggregated by 3 172.16.2.254)
0.0.0.0 from 0.0.0.0 (172.16.2.254)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
RTA#

This means that the aggregate can now be advertised to AS 1 because the AS_PATH does not include AS 1. AS 2 will not be able to receive the aggregate.

Changing the aggregates attributes

In some situations, changing the aggregate's attributes is required. The example in this post shows one scenario in which this could be useful.

As you have already seen, the aggregate can carry information about the individual elements if configured with the AS_SET option. If one or more of the routes forming the AS_SET aggregate are configured with no-export community attribute, the aggregate itself will carry the same attribute. his will prevent the aggregate from being exported. To remedy this situation, you can modify the community attribute of the aggregate by using what Cisco calls an attribute map, another form of a route map that applies only to aggregates.

Setup: As Figure 11-13 in Chapter 11 of Internet Routing Architectures.

First we configure RTC to send the Community: no-export attribute

RTC(config)#router bgp 1
RTC(config-router)#no neighb 192.68.6.1 send-comm
RTC(config-router)#neighb 172.16.20.2 send-comm
RTC(config-router)#neighb 172.16.20.2 route-map SETCOMMUNITY out
RTC(config-router)#exit
RTC(config)#acces
RTC(config)#access-list 1 permit 192.68.11.0 0.0.0.255
RTC(config)#route-map SETCOMMUNITY
RTC(config-route-map)#route-map SETCOMMUNITY permit 10
RTC(config-route-map)#match ip add 1
RTC(config-route-map)#set community no-export
RTC(config-route-map)#route-map SETCOMMUNITY permit 20
RTC(config-route-map)#

Before we go any futher, make sure RTA is picking up this attribute.

RTA>sh ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Flag: 0x880
Advertised to non peer-group peers:
172.16.1.2
{2,1}, (aggregated by 3 172.16.2.254)
0.0.0.0 from 0.0.0.0 (172.16.2.254)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
Community: no-export

"Community: no-export" confirms that it is, but this is not what we want so configure RTA to set up a attribute-map to specify the attribute to send ie; "community: none".

RTA# conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTA(config)#route-map SET_ATTRIBUTE permit 10
RTA(config-route-map)#set community none
RTA(config-route-map)#router bgp 3
RTA(config-router)#agg 192.68.0.0 255.255.0.0 as-set attribute-map SET_ATTRIBUTE
RTA(config-router)#end
RTA#

Have a look now on RTA!

RTA#sh ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0/16, version 15
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.16.1.2 172.16.20.1 172.16.220.2
{2,1}, (aggregated by 3 172.16.2.254)
0.0.0.0 from 0.0.0.0 (172.16.2.254)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
RTA#

No longer do we have the "community: no export" attribute.

Loss of information inside aggregates

When an Aggregate is sent we lose the finer granularity of the actual AS Paths to the Aggregated prefixes.

Using AS_SET we can advertise the AS path information that would normally not be sent in an aggregate advertisement.

We setup our network as shown in Figure 11-13 of Internet Routing architectures in chapter 11.

The only new command we encounter is an option appended to the aggregate-address command under Router BGP configuration.

RTA(config)#aggregate-address 192.68.0.0 255.255.0.0 as-set

Cleaning up we run the following commands on routers RTA & RTF:

RTA(config)#no route-map SUPPRESS/ALLOW
RTA(config)#no access-list 1
RTA(config)#no aggregate-address 172.16.0.0 255.255.0.0

Before we use the as_set option, just add the aggregate-address command and view the BGP table on router RTK.

RTA(config)#aggregate-address 192.68.0.0 255.255.0.0

RTK>sh ip bgp
BGP table version is 18, local router ID is 172.16.220.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 172.16.220.1 0 0 3 i
*> 172.16.20.0/24 172.16.220.1 0 0 3 i
*> 172.16.65.0/26 172.16.220.1 0 3 i
* 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 0.0.0.0 0 32768 i
*> 192.68.0.0/16 172.16.220.1 0 0 3 i
*> 192.68.5.0 172.16.220.1 0 3 i
*> 192.68.10.0 172.16.220.1 0 3 2 i
*> 192.68.11.0 172.16.220.1 0 3 1 i

Notice, the 192.68.0.0 aggregate address only shows AS 3 in the path, when in fact the more specific 192.68.0.0 networks reach into AS 1 & AS 2.

Apply the as_set option and review the changes.

RTA(config)#aggregate-address 192.68.0.0 255.255.0.0 as-set

RTK>sh ip bgp
BGP table version is 19, local router ID is 172.16.220.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 172.16.220.1 0 0 3 i
*> 172.16.20.0/24 172.16.220.1 0 0 3 i
*> 172.16.65.0/26 172.16.220.1 0 3 i
* 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 0.0.0.0 0 32768 i
*> 192.68.0.0/16 172.16.220.1 0 0 3 {2,1} i
*> 192.68.5.0 172.16.220.1 0 3 i
*> 192.68.10.0 172.16.220.1 0 3 2 i
*> 192.68.11.0 172.16.220.1 0 3 1 i
RTK>

You will notice how the aggregate 192.68.0.0/16 changes to include a SET{2,1} within its path information.This indicates that the aggregate actually summarizes routes that have passed via ASs 1 or 2. The AS_SET information becomes important in avoiding routing loops because it keeps an indication of where the route has been.

Given that the aggregate with the AS_SET contains information about each individual route, that is summarized, changes in the individual route will cause the aggregate to be updated. In the example if 192.68.11.0/24 goes down, the path information of the aggregate will change from 3{3,1} to 3 2, and the aggregate will be updated. It the aggregate summarizes 100's or 1000's of routes , the aggregate will constantly be oscillating if the rotes forming the aggregate are unstable.

Aggregate with a subset of more specific routes

Unlike in the Aggregate plus more specific routes post, we will limit the prefixes that are leaked as opposed to leaking all the prefixes covered by that specific aggregate.

We use a special type of route-map here called “suppress-maps” to permit or deny more specific routes of an aggregate to be sent.

Setup: Again this is based on the examples in Chapter 11 of Internet Routing Architectures.

Let's clean up from the previous post by stripping the route-map SETNOEXPORT route-map on RTA & RTF

RTA(config)#no route-map SETNOEXPORT out
RTA(config)#no access-list 101
RTA(config-router)#no neighbor 172.16.20.1 send-community
RTA(config-router)#no neighbor 172.16.20.1 route-map SETNOEXPORT out

Next, RTF needs to advertise RTA’s 172.16.220.0 route in BGP & RTA needs to advertise RTF’s 172.16.65.0 route in BGP. In AS 3’s IBGP, these will be suppressed via the bgp suppress-map so they need to be originated from the routers IGP, in this instance OSPF.

Create our suppress-map and access-lists. Adjust our aggregate-address commands:

On RTA:

Aggregate-address 172.16.0.0 255.255.0.0 suppress-map SUPPRESS

access-list 1 permit 172.16.220.0 0.0.0.255
access-list 1 deny any

route-map SUPPRESS permit 10
match ip address 1

On RTF:

Aggregate-address 172.16.0.0 255.255.0.0 suppress-map ALLOW

access-list 1 deny 172.16.220.0 0.0.0.255
access-list 1 permit any

route-map ALLOW permit 10
match ip address 1

You'll see we can easily control updates for network 172.16.220.0 with SUPPRESS & ALLOW route-maps. In RTA we "PERMIT network 172.16.220.0 to be SUPPRESSED", this means this route will not be advertised. Vis-à-vis RTF will "DENY 172.16.220.0 to be SUPPRESSED" , this means the route will be advertised.

Below is output from Show ip bgp on RTA, note how route 172.16.220.0 is marked with "s for Suppressed".

RTA#sh ip bgp
BGP table version is 16, local router ID is 172.16.2.254
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i172.16.0.0 172.16.1.2 0 100 0 i
*> 0.0.0.0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.20.0/24 0.0.0.0 0 32768 i
s i172.16.220.0/24 172.16.1.2 74 100 0 i
s> 0.0.0.0 0 32768 i
*>i192.68.5.0 172.16.1.2 0 100 0 i
* 172.16.20.1 0 1 i
* i192.68.6.0 172.16.1.2 0 100 0 1 i
*> 172.16.20.1 0 0 1 i
RTA#

A traceroute from RTC, as setup in the Internet Routing Architectures example will reveal the route to 172.16.220.0

RTC>traceroute 172.16.220.1

Type escape sequence to abort.
Tracing the route to 172.16.220.1

1 192.68.6.1 12 msec 16 msec 12 msec
2 192.68.5.1 28 msec 28 msec 28 msec
3 172.16.1.1 [AS 3] 28 msec * 24 msec
RTC>

Aggregate plus more specific routes

In some cases, more-specific routes, in addition to the aggregate, need to be passed (leaked) to a neighbouring AS. This is usually done in a Customer AS multihomed to a single provider. The Provider AS that gets the more-specific routes from the Customer AS would be able to make a better decision about which way to reach the route within the Customer AS.

Setup: Network Topology & configuration as in Chapter 11 - Internet Routing Architectures. I will cover basics of configuration & theory of this example.

Our starting configuration will list the networks we wish to advertise via BGP. This is determined with the network command under BGP configuration.
Next, on each of the Customer AS EBGP routers, configure BGP to send the aggregate network.

Aggregate-address 172.16.0.0 255.255.0.0

Note that we have not included the "summary-only" option, so both the aggregate and more-specific will be advertised.

We have seen on the Aggregate only, suppressing more specific routes post, what we would expect to see in the neighbours BGP table, however, we would also now see the more specific routes.

What is important now is that these more-specific routes do not leak further into the Internet, upstream of the Provider AS. We will do this with the Community attribute.

With the "community: no-export" attribute the Customer AS Routers can instruct the Provider AS Routers to export only the aggregate and not the more-specific routes upstream. This reduces the Internet BGP Table as the Provider AS will only advertise aggregates for all the networks under its control.

Community No-Export Configuration:

Under our Customer AS BGP Configuration we first need to establish our Provider AS neighbours to receive community attribute advertisements.
By default, BGP community attributes are not advertised to peers. The "neighbour send-community" command enables the sending of BGP community attributes to BGP peers.

Neighbour 192.68.5.2 send-community

Then, we set up an access list to catch the addresses we are interested in.

access-list 101 permit ip 172.16.0.0 0.0.255.255 host 255.255.0.0

The host 255.255.0.0 makes sure nothing more-specific than 172.16.0.0 is let through.

Next, we set up a route-map to tag the more-specific routes with the community no-export attribute.

Route-map SETNOEXPORT permit 10
Match ip address 101
Route-map SETNOEXPORT permit 20
Set community no-export

Finally in our Customer AS BGP configuration we apply the route-map

Neighbour 192.68.5.2 route-map SETNOEXPORT out

All seems good and well and if you even run "show ip bgp" on an upstream (from the provider) router you might even get a nicely aggregated route to the 172.16.0.0 networks or you might not.

The reason routes could be leaking into the Internet is because the nature of the community attribute is that of an optional transitive attribute. This means we have to decide on each router whether we will pass the community attribute. As it stands, one of our multihomed routers in the Provider AS is passing on the routes to the Provider AS EBGP neighbor via IBGP and then if these are the best routes to the specific networks BGP will propagate these upstream.

Though my working example (yours may differ), the route being propagated upstream has the community attribute set. This is because that route so happens to be deemed as the best. However, the backup routes community is not set. If this alternative route were to become the best route, the more-specific route it describes would be propagated upstream. Bad!

I garnered this information by the command "sh ip bgp 172.16.20.0.0" ( a network in the aggregate I am advertising).

RTD>sh ip bgp 172.16.20.0
BGP routing table entry for 172.16.20.0/24, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to non peer-group peers:
192.68.6.2
3
192.68.5.1 from 192.68.5.1 (192.68.5.1)
Origin IGP, localpref 100, valid, external, best
Community: no-export
3
172.16.20.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal

See! The back up route does not have the community set. Bad!

On our BGP Neighbors in the Provider AS we need to propagate the community attribute to the Provider AS EBGP neighbour.

Neighbour 192.68.6.1 send-community

RTD>sh ip bgp 172.16.20.0
BGP routing table entry for 172.16.20.0/24, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to non peer-group peers:
192.68.6.2
3
192.68.5.1 from 192.68.5.1 (192.68.5.1)
Origin IGP, localpref 100, valid, external, best
Community: no-export
3
172.16.20.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal
Community: no-export
RTD>

See! Both routes are now part of the community. Good!

Aggregate only, suppressing more specific routes

Setup: This example network is based on the topology outlined on page 343 of Internet Routing Architectures.

First we look at the BGP Table without aggregates or any summary.

RTC>sh ip bgp
BGP table version is 27, local router ID is 192.68.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 192.68.6.1 0 2 3 i
*> 172.16.65.0/26 192.68.6.1 0 2 3 i
*> 172.16.220.0/24 192.68.6.1 0 2 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i

In our example we have three "172.16.0.0" networks that we will aggregate with the command:

aggregate-address 172.16.0.0 255.255.0.0 summary-only

The "summary only" option makes sure no more-specific routes than the aggregate will be advertised.

You do not need to "clear ip bgp address soft out" for this to take effect as you would with a route-map.

Let’s have a look at the new BGP table on our BGP neighbour.

RTC>sh ip bgp
BGP table version is 30, local router ID is 192.68.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* 172.16.0.0 192.68.6.1 0 2 3 i
*> 172.16.20.2 0 0 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i

As we expected, a reduced BGP table. We can discover further information about our aggregate network with the "show ip bgp address" command.

RTC>sh ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 15
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.68.6.1
2 3, (aggregated by 3 192.68.5.1)
192.68.6.1 from 192.68.6.1 (192.68.10.1)
Origin IGP, localpref 100, valid, external, atomic-aggregate
3, (aggregated by 3 172.16.2.254)
172.16.20.2 from 172.16.20.2 (172.16.2.254)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
RTC>

This gives us details of the "atomic-aggregate" attribute and which AS and Router it was set by.

Static Routes into BGP

Rather than the above example which relied on dynamic routing with each network defined in the routers BGP configuration a static route can be set.

With the following commands we will remove the aggregate configuration & networks.

RTF#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTF(config)#router bgp 3
RTF(config-router)#no aggregate-address 172.16.0.0 255.255.0.0 summary-only
RTF(config-router)#no network 172.16.1.0 255.255.255.0
RTF(config-router)#no network 172.16.65.0 255.255.255.192
RTF(config-router)#no network 172.16.220.0 255.255.255.0

Then install a network that advertises the aggregate address.

RTF(config-router)#network 172.16.0.0
RTF(config-router)#exit

Along with a static address.

RTF(config)#ip route 172.16.0.0 255.255.0.0 null0
RTF(config)#end

Remember with BGP, the process will only advertise a network that is in the ip routing table so we need to add the static ip route so it appears in the said routing table. The null0 interface ensures that if the 172.16.0.0 network router has no knowledge of more-specific routes than the traffic is sent to the "bit bucket" rather than possibly creating a routing loop.

We can run the show ip bgp commands from our neighbour router to verify our configurations. The basic "show ip bgp" will give us the same table as our aggregated table, however if we "show ip bgp 172.16.0.0" you will notice the lack of atomic-aggregate attributes.

You can auto-magically aggregate address with the "auto-summary" command under Cisco BGP configuration but not in Zebra/Quagga so it’s probably better not to. Plus I find it more re-assuring to have the aggregate looking back at me when I’m scanning through the runn/start conf.

BGP-4 Aggregation

A route aggregate is a route advertisement that has consolidated contiguous networks.

For instance;

Networks: (192.168.1.0/24, 192.168.2.0/24, …192.168.254.0/24, 192.168.255.0/24)

Aggregate: 192.168.0.0/16

Rather then processing 256 networks, a single aggregate network address that covers all the networks can be advertised. Aggregates vastly reduce the Internet Routing Table size.

The following posts are taken from the book “Internet Routing Architectures”. These examples demonstrate different methods of aggregation that are seen on the Internet. The way aggregates are formed and advertised and whether they carry with them more specific routes will influence traffic patterns and sizes of BGP routing tables. Remember that aggregation applies to routes that exist in the BGP routing table. An aggregate can be sent if at least one more-specific route of that aggregate exists in the BGP table.

Aggregate only, suppressing more specific routes:

Aggregate plus more specific routes:

Aggregate with a subset of more specific routes:

Loss of information inside aggregates:

Changing the aggregates attributes:

Forming the Aggregate Based on a subset of specific routes

Multi Router Looking Glass

Objective: create a web interface for viewing routing tables and other routing commands.

I have chosen John Fraizer's Multi Router Looking Glass (a working example can be seen at RIPE's Routing Information Service page). The latest version of the software can be downloaded at: http://www.op-sec.us/mrlg/source/CURRENT/ .
Basically the software consists of a cgi script to place in your apache server cgi-bin and a couple of perl & bash scripts. There is also code to make fastping, an alternative to ping. I just used plain old ping in my setup.

CPAN Perl Module: First thing we need is the Perl "Network::Telent::Cisco" module to allow the main script to communicate via telnet to our network equipment. SSH is available via the "Network::SSH::Perl" module, however I will not cover this here.

Access your CPAN shell:

$ perl -MCPAN -e shell
cpan>

Note: If this is the first time you have run this command you will have to configure CPAN.

Now install "Network::Telnet::Cisco" module.

cpan> install Net::Telnet::Cisco

With this done all we need is a little file keeping to get our program into place. From our downloaded and extracted tar.gz folder issue the following commands:

cp index.cgi /usr/local/www/apache22/cgi-bin/
chmod +x /usr/local/www/apache22/cgi-bin/index.cgi
cp fping1 ztr ztraceroute /usr/local/bin
chmod +x /usr/local/bin/fping1 /usr/local/bin/ztr /usr/local/bin/ztraceroute
cp mrlg.conf.sample /etc/mrlg.conf

Note: These are for FreeBSD, your directory structure may vary.
Now, we need to edit fping1, ztr & ztraceroute to make sure all paths within these files are correct for your system. For FreeBSD I had to edit paths to bash & traceroute, also exchange fastping for ping and its's correct path.

mrlg.conf set up:
To get anything out of your index.cgi, ie. MRLG, you need to config /etc/mrlg.conf.
First, we have to tell MRLG the host details we will be running MRLG on.

## Set the URL for the location of the looking-glass....
$::url="http://10.1.1.3/cgi-bin/index.cgi";

Secondly, we can amend a router to the details of one of our local routers.

$::Routers{'Folkestone-AS2'} = {
comment => 'Cisco 2600 Series',
server => '10.1.1.2',
use_port => '23',
login_pass => 'cisco',
full_tables => '1',
cisco => '1',
debug => "0",
};

That is all we need to get an interface into our routers as demonstrated below.



The conf file has lots of settings not discussed here but which can be very useful so I would advise this be your first point of call if you decide to install MRLG.
Phil

BGP Peer Groups on Quagga

Objective: To set up a "peer-group" on our Quagga router to limit advertisements within an Autonomous System.

Setup: Refer to previous post "Headless BSD Quagga Router" to get you started.

Under the running config on the quagga router I have formed the peer group 'localAS' for AS3 with the following command:

neighbor localAS remote-as 3

next I include the neighbors I wish to be in the peer-group:

neighbor 172.16.1.2 peer-group localAS
neighbor 192.68.1.1 peer-group localAS

It is the same as declaring a normal neighbor however I use the 'peer-group' option. The 'remote-as' option is not needed, as in the preceding command 'neighbor localAS remote-as 3' confirms which remote the peer-group is in.

Excerpt on BGP Technology from Cisco Systems:

The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces the amount of system resources (CPU and memory) necessary in an update generation. A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load.

BGP peer groups also simplifies the BGP configuration. Instead of configuring each neighbor with the same policy individually, a peer group allows you to group the policies which can be applied to individual peers thus making efficient update calculation along with simplified configuration.

..

Headless BSD Quagga Router

Objective Get an old box running as a bgp router for lab exercises.

Install a minimum installation of FreeBSD. See previous post for installation media.
Of note, My "Hard Drive" I am using for installation, is a 1gb Compact Flash Card, so to reduce "writes" to this I have not partitioned a "swap" space.

Also regards a headless install don't forget when asked if there are any last configurations you need to preform choose yes and navigate to the "TTYs" menu item. From here you need to edit thr /etc/ttys file.

scroll down to serial terminals section and edit so you can log on via the first serial console:

# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyd0 "/usr/libexec/getty std.9600" xterm on secure

so on reboot we should be at a login prompt.

Quagga Installation:

FreeBSD2# pkg_add -r quagga
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/quagga.tbz... Done.
Added group "quagga".
Added user "quagga".
FreeBSD2#

Quagga is installed but we need two config files written to operate as a BGP router.
These go in /usr/local/etc/quagga/ and are "zebra.conf"

!
! Zebra configuration saved from vty
! 2007/12/22 22:25:59
!
hostname zebraBSD1
password zebra
enable password zebra
log stdout
!
debug zebra events
!
interface fxp0
ip address 10.2.2.2/24
ipv6 nd suppress-ra
!
interface fxp1
ipv6 nd suppress-ra
!
interface fxp2
ipv6 nd suppress-ra
!
interface lo0
!
interface plip0
ipv6 nd suppress-ra
!
!
line vty
password zebra
!

and "bgpd.conf"

!
!zebra BGP conf file
!
router bgp 65001
!
line vty
password zebra
!

now run zebra and bgpd as daemons.

freebsd1# zebra -d
2007/12/29 19:12:39 ZEBRA: MESSAGE: ZEBRA_INTERFACE_ADDRESS_ADD 10.2.2.2/24 on fxp0
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
freebsd1# bgpd -d
freebsd1#

To access Quagga/zebra:

freebsd1# telnet localhost 2601
Trying ::1...
Connected to localhost.
Escape character is '^]'.

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


User Access Verification

Password:
zebraBSD1> exit
Connection closed by foreign host.

To access Quagga/bgpd:

freebsd1# telnet localhost 2605
Trying ::1...
Connected to localhost.
Escape character is '^]'.

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


User Access Verification

Password:
zebraBSD1> exit
Connection closed by foreign host.
freebsd1#

but you probably thinking this is going to be a hassle having to telnet into each daemon. Well the good news is quagga ships with a "vtysh". This enables one login for all daemons.

FreeBSD2# vtysh

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

best of all you get your trace and ping commands back!

FreeBSD2.home# ping 172.16.1.2
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=253 time=25.635 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=253 time=25.425 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=253 time=25.575 ms
64 by^C
--- 172.16.1.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 25.399/25.509/25.635/0.099 ms
FreeBSD2.home# trace 172.16.1.2
traceroute to 172.16.1.2 (172.16.1.2), 64 hops max, 40 byte packets
1 172.99.1.2 (172.99.1.2) 1.365 ms 1.306 ms 1.283 ms
2 172.16.20.2 (172.16.20.2) 15.764 ms 15.719 ms 15.741 ms
3 172.16.1.2 (172.16.1.2) 16.314 ms * 16.326 ms
FreeBSD2.home#

now, vi /etc/rc.conf to enable zebra & routing daemons on startup.

freebsd1# vi /etc/rc.conf

quagga_enable="YES"
quagga_daemons="zebra bgpd"

oh, and if you really want to forward packets, you will also have to add the following to /etc/rc.conf to enable FreeBSD as a router.

gateway_enable="YES"

bada bing!

BGP Summarization and Path-Selection

Objective In the previous exercises we have set up an inter-network spanning several AS’s. BGP is routing advertisement for several networks as you will have verified in with different “show ip” commands. Although it is not a large amount of advertisements, we can slim down our routing table with “Route Aggregation”. In larger networks aggregation is imperative.


Download Equipment list, configuration files and network topology. ccnp-c9t1.zip

Setup
This exercise starts where "Configuring Full-Mesh IBGP" ended. Above is a link to the completed config files of the "Configuring Full-Mesh IBGP" exercise. You may have to bring up some interfaces. Run “show ip interface brief” to work out which.

In this exercise it is a matter of only running one command on the edge routers and then discovering how this affects the networks.

On the edge routers, summarize the pod network to 10.1.0.0/16 to the core AS’s using the “aggregate-address” command with the “summary-only” option. You do not need to include the loopback interfaces of the internal routers in the summary.

P1R1(config-router)#aggregate-address 10.1.0.0 255.255.0.0 summary-only
P1R1(config-router)#end

Telnet to either of the backbone routers. Now, have a look at the routing tables. Can you see where the aggregate address is for your pod?

The following output is from the BBR2 router.

BBR2>sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.31.0.0/16 is variably subnetted, 3 subnets, 2 masks
B 172.31.1.0/24 [20/0] via 10.254.0.1, 05:43:37
R 172.31.0.0/16 [120/1] via 10.254.0.1, 00:00:29, Ethernet0/0
C 172.31.11.0/24 is directly connected, Serial0/0.1
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.97.97.0/24 [20/0] via 10.254.0.3, 06:25:30
B 10.1.0.0/16 [20/0] via 172.31.11.1, 00:07:39
C 10.254.0.0/24 is directly connected, Ethernet0/0
BBR2>

Can you still ping the internal routers from the backbone?

BBR1#ping 10.1.3.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/50/52 ms
BBR1#

With the summary-only option, the more specific routes are suppressed. This is indicated in the BGP table with the “s” character at the start of the line.

P1R1>sh ip bgp
BGP table version is 18, local router ID is 10.200.200.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
s> 10.1.0.0/24 0.0.0.0 0 32768 i
* i10.1.0.0/16 10.1.0.2 0 100 0 i
*> 0.0.0.0 32768 i
s> 10.1.1.0/24 0.0.0.0 0 32768 i
s> 10.1.2.0/24 10.1.1.3 2 32768 i
s> 10.1.3.0/24 10.1.1.3 1 32768 i
* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i
* i10.254.0.0/24 172.31.1.3 0 100 0 64998 i
* 172.31.11.4 0 64999 64998 i
*> 172.31.1.3 0 0 64998 i
r i172.31.1.0/24 172.31.1.3 0 100 0 64998 i
r 172.31.11.4 0 64999 64998 i
r> 172.31.1.3 0 0 64998 i
r i172.31.11.0/24 172.31.11.4 0 100 0 64999 i
r> 172.31.11.4 0 0 64999 i
Network Next Hop Metric LocPrf Weight Path
r 172.31.1.3 0 64998 64999 i
P1R1>

Path-Selection:

You’ll notice in the BGP Table there are 3 routes to the 10.97.97.0 network.

* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i

I’ll use these routes as an opportunity to run over route selection briefly and introduce the “show ip bgp network” command.

P1R1>sh ip bgp 10.97.97.0
BGP routing table entry for 10.97.97.0/24, version 4
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.0.2 10.200.200.13 10.200.200.14 172.31.11.4
64999 64997
172.31.11.4 from 10.1.0.2 (10.200.200.12)
Origin IGP, metric 0, localpref 100, valid, internal
64999 64997
172.31.11.4 from 172.31.11.4 (172.31.22.4)
Origin IGP, localpref 100, valid, external
64998 64997
172.31.1.3 from 172.31.1.3 (172.31.2.3)
Origin IGP, localpref 100, valid, external, best
P1R1>

The weight & local preference are the same for all routes so this does not decide on route selection. Nor are any of the routes originated from the local router.
All the AS paths are the same length, as are the origin codes & the MED’s.

Therefore the path-selection process looks at EBGP vs IBGP with a preference to EBGP. Finally one of the candidates is eliminated as it has an “internal” reference. Two routes are left and at this stage the path-selection process chooses the router with the lowest neighbor BGP route-id. The route through 172.31.1.3 is preferred over the route through 172.31.11.4

Configuring Full-mesh IBGP

Configuring Full-Mesh IBGP

Objective In the previous exercise you will remember the internal routers of our pod did not learn of external routes, but used default routes to lead them towards the frame switch. In this exercise we will set up Full-Mesh IBGP so our pod learns routes via BGP.

Download Equipment list, configuration files and network topology. ccnp-c8t2.zip

Setup
This exercise starts where "a simple IBGP and EBGP network" ended. Above is a link to the completed config files of the "a simple IBGP and EBGP network" exercise.

The first thing we will do here is strip the default route advertisements down on the edge routers.

P1R1(config)#no ip route 0.0.0.0 0.0.0.0 172.31.11.4
P1R1(config)#router rip
P1R1(config-router)#no default-information originate
P1R1(config-router)#end
P1R1#

Once this is done we set up the full mesh for the pod. This requires adding 2 more sessions on the edge routers and 3 sessions on the internal routers. We use the loopback addresses for this example.

P1R1(config)#router bgp 65001
P1R1(config-router)#neighb 10.200.200.13 remote-as 65001
P1R1(config-router)#neighb 10.200.200.14 remote-as 65001
P1R1(config-router)#end
P1R1#

Loopbacks provide added stability in full-mesh networks as the interface does not go down, in comparison to a physical interface when their is a failure. For this reason we will configure the internal routers to send their IBGP updates from their loopback address.
The following shows an example of what is required:

P1R3(config)#router bgp 65001
P1R3(config-router)#neighb 10.200.200.11 update-source loopback0
P1R3(config-router)#neighb 10.200.200.12 update-source loopback0
P1R3(config-router)#neighb 10.200.200.14 update-source loopback0
P1R3(config-router)#end

You should immediately see IBGP sessions become established. You could also check with the "show ip bgp summary" command.
The edge routers should see 2 EBGP and 3 IBGP sessions. The internal routers should just see the 3 IBGP sessions.

Show ip bgp to determine next hop for the route to 10.254.0.0

P1R1#sh ip bgp
BGP table version is 13, local router ID is 10.200.200.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i10.1.0.0/24 10.1.0.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i10.1.1.0/24 10.1.2.4 2 100 0 i
*> 0.0.0.0 0 32768 i
*> 10.1.2.0/24 10.1.1.3 2 32768 i
* i 10.1.0.2 0 100 0 i
* i10.1.3.0/24 10.1.2.4 1 100 0 i
*> 10.1.1.3 1 32768 i
* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i
* i10.254.0.0/24 172.31.1.3 0 100 0 64998 i
* 172.31.11.4 0 64999 64998 i
*> 172.31.1.3 0 0 64998 i
r i172.31.1.0/24 172.31.1.3 0 100 0 64998 i
r 172.31.11.4 0 64999 64998 i
r> 172.31.1.3 0 0 64998 i
Network Next Hop Metric LocPrf Weight Path
r i172.31.11.0/24 172.31.11.4 0 100 0 64999 i
r> 172.31.11.4 0 0 64999 i
r 172.31.1.3 0 64998 64999 i
P1R1#

It shows 172.31.1.3. (Backbone Router). You will also see these routes in the BGP table of the internal pod routers. Howerver, these routes are not in the ip route table because this route is unreachable.

P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:23, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:16, Serial0
R 10.200.200.12/32 [120/2] via 10.1.3.4, 00:00:16, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:16, Serial0
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:24, Ethernet0
P1R3#

Problem: EBGP distributes the next hop (remote address) into the IBGP, but the pod does not have a route, static or otherwise to the remote network.
Solution: The local EBGP speaker has to advertise to the pod , that it is the next hop for this remote network, as opposed to the Backbone router. Achieve this with the following commands on both edge routers.

P1R1(config-router)#neighbor 10.200.200.13 next-hop-self
P1R1(config-router)#neighbor 10.200.200.14 next-hop-self

Now “show ip route” on P1R3. There is still no route to the 10.254.0.0 prefix!

This is because synchronization is on. If you disable synchronization, BGP can use routes learned from IBGP neighbors that are not present in the local routing table.
On all pod routers issue the following command.

P1R1(config-router)#no synchronization

BGP Synchronization is on by default in current IOS releases.
The BGP Synchronization rule states that a bgp router should not use or advertise to a neighbour a route learned by IBGP, unless that route is local or learned from the IGP.
Because we are running full mesh IBGP we can turn off synchronization with the ‘no synchronization’ command on all pod routers.

Sh ip route on P1R3 and verify BGP has injected the route into the local routing table.

P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.31.0.0/24 is subnetted, 2 subnets
B 172.31.1.0 [200/0] via 10.200.200.11, 00:00:15
B 172.31.11.0 [200/0] via 10.200.200.11, 00:00:15
10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:26, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:01, Serial0
R 10.200.200.12/32 [120/2] via 10.1.3.4, 00:00:01, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:02, Serial0
B 10.97.97.0/24 [200/0] via 10.200.200.11, 00:00:16
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:27, Ethernet0
B 10.254.0.0/24 [200/0] via 10.200.200.11, 00:00:34
P1R3#

Finally ping 10.254.0.254

P1R3#ping 10.254.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
P1R3#

Wrapping Up
In this exercise we learnt about the "next-hop-self" command which is used to force BGP to use its own IP address as the next hop for eachnetwork it advertises to the neighbor, rather than letting the protocol choose the next-hop address to use.

We also learnt about Synchronization in the Cisco IOS. Sychronization is ON by default! If your AS is passing traffic from one AS to another, BGP should not advertise a route before all routers in your AS have learned about the route via IGP.
This behavior can be changed with the "no synchronization" command. Make sure you have a full mesh topology before disabling sychronization, otherwise you could end up with routing "black holes".

this post is based on an exercise from the book
CCNP Self Study:
Building Scalable Cisco Internetworks (BSCI)
Second Edition

a simple IBGP and EBGP network

Objective This post demonstrates how to configure a simple IBGP and EBGP network.

Download Equipment list, configuration files and network topology. ccnp-c8t1.zip

Setup
After successfully loading config files into your equipment we need to verify installation.

First let's make sure all our interfaces are up on each router that we would expect with "sho ip interface brief".

P1R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
Ethernet0 10.1.1.1 YES manual up up
Loopback0 10.200.200.11 YES manual up up
Serial0 unassigned YES manual up up
Serial0.1 172.31.1.1 YES manual up up
Serial0.2 172.31.11.1 YES manual up up
Serial1 10.1.0.1 YES manual up up

Next we wil ping through to the backbone routers to see that the Frame Switch is operational.

P1R1#ping 172.31.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/45/88 ms

BGP Configuration
Here we set up our pod as AS65001 with IBGP and EBGP sessions on both edge routers.

P1R1#conf t
P1R1(config)#router bgp 65001
P1R1(config-router)#neighbor 172.31.1.3 remote-as 64998
P1R1(config-router)#neighbor 172.31.11.4 remote-as 64999
P1R1(config-router)#neighbor 10.1.0.2 remote-as 65001
P1R1(config-router)#end

Following this we mannualy set up which networks BGP will advertise, again on the routers we configured as AS65001.

P1R1(config)#router bgp 65001
P1R1(config-router)#net 10.1.0.0 mask 255.255.255.0
P1R1(config-router)#net 10.1.1.0 mask 255.255.255.0
P1R1(config-router)#net 10.1.2.0 mask 255.255.255.0
P1R1(config-router)#net 10.1.3.0 mask 255.255.255.0
P1R1(config-router)#end
P1R1#

You will see notifications on the console as the sessions are established. You can verify you have the 3 expected bgp sessions with the "show ip bgp summary" command.

P1R1#sh ip bgp summ
BGP router identifier 10.200.200.11, local AS number 65001
BGP table version is 10, main routing table version 10
8 network entries using 776 bytes of memory
20 path entries using 720 bytes of memory
13 BGP path attribute entries using 780 bytes of memory
6 BGP AS-PATH entries using 144 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2420 total bytes of memory
BGP activity 8/0 prefixes, 20/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.2 4 65001 25 25 10 0 0 00:15:31 7
172.31.1.3 4 64998 27 26 10 0 0 00:18:55 4
172.31.11.4 4 64999 27 27 10 0 0 00:18:42 4

State/PfxRcd shows how many prefixes have been received from which peer

RIPv2 & IBGP
RIPv2 is running between PxR1 and PxR2, because the network statement for RIPv2 includes the entire 10.0.0.0 network. For this exercise, you only want to run IBGP between PxR1 and PxR2. We will need to configure int s0/1 on both edge routers as passive interfaces to suppress RIPv2 between the 2 edge routers.

P1R1(config)#router rip
P1R1(config-router)#passive-interface s0/1

Verify these commands with "show ip protocols". You will now see interfaces serial0/1 under the "Passive Interfaces" header.

Passive Interface(s):
Serial0/1

From the edge routers we have full connectivity with the 10.254.0.0 prefix however because we are not redistributing BGP into RIPv2, the internal routers do not know any routes outside their pod.
Use the "default-information originate" command on the edge routers to generate a default route to the internal routers.

P1R1(config)#router rip
P1R1(config-router)#default-information originate

Verify this with "show ip route" on the internal routers.You will see a new default route generated via RIPv2.

P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.1.1.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:22, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:03, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:03, Serial0
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:22, Ethernet0
R* 0.0.0.0/0 [120/1] via 10.1.1.1, 00:00:23, Ethernet0

and finally a ping to verify connectivity.

P1R3#ping 10.254.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
P1R3#

this post is based on an exercise from the book
CCNP Self Study:
Building Scalable Cisco Internetworks (BSCI)
Second Edition