How Multi is MP-BGP in IOS-XR - Part #2

When two years ago i was writing the first part of "How Multi is MP-BGP in IOS-XR", i concluded with the following:

1. In IOS-XR you need an IPv6 NH in order to activate the IPv6 AF for an IPv4 BGP session.
2. If you don't have an IPv6 NH, then the IPv4 BGP session won't even come up.
3. The above was done to protect against misconfiguration, because otherwise you would get a misleading v4 mapped v6 address as NH.
4. If you have an IPv6 NH, then the IPv4 BGP session with the IPv6 AF will come up.
5. If afterwards you remove the IPv6 NH, then the session deliberately remains up and you get a misleading v4 mapped v6 address as NH.

Although back then i didn't agree with the above behavior, i couldn't do anything more than just accept the "solution" given: print a warning message if such a case is met.

Recently i realized that the same IOS-XR developers decided to bring even more confusion into the engineer's everyday job.

Old Fact: You can't have an IPv4 address as next-hop for IPv6 prefixes
New Fact: You must display an IPv4 address as next-hop for IPv6 prefixes

I probably need to explain it a little bit more, because i'm talking about 6VPE this time. 6VPE is a technology/architecture which allows you to have IPv6 connectivity over an IPv4 MPLS (and not only) network.

The original 6VPE scenario where i met this behavior is quite complex, but for simplicity let's assume that it includes only the following:

2 x CE routers (CE1, CE2)
2 x 6VPE routers (PE1, PE2)
2 x P/RR routers (P1, P2)

This is a very simple VPN topology (with only two sites) like the following:

CE1 <=> PE1 <=> P1 <=> P2 <=> PE2 <=> CE2

All routers are exchanging IPv4/IPv6 prefixes using BGP, in order to have IPv4/IPv6 connectivity between the two CEs. IPJ describes the relevant route advertisement with a very nice picture:

If we could follow the exchange of information between some of these routers, then we would notice something like the following.

CE1 sends its IPv6 prefixes to PE1 through MP-BGP and PE1 sends them to P1 accordingly. Since (as of now) there is no support for LDP over IPv6, PE1 sends the IPv6 prefixes using a v4-mapped IPv6 address as next-hop (that's encoded inside the NLRI as shown in the debugs).

This is how the IPv6 prefix is sent from PE1 (10.10.253.164) to P1 (10.10.253.161).

PE1#sh bgp vpnv6 unicast all neighbors 10.10.253.161 advertised-routes
BGP table version is 7, local router ID is 10.10.253.164
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:109 (default for vrf TEST-VRF)

*> 2001:DB8:2:60::22/127
                    2001:DB8:2:50::23        0         32768 ?
 

This is the relevant debug info that shows how exactly the IPv6 prefix (2001:DB8:2:60::22/127 with next-hop of ::FFFF:10.10.253.164) is sent from PE1 to P1.

BGP(5): (base) 10.10.253.161 send UPDATE (format) [100:109]2001:DB8:2:60::22/127, next ::FFFF:10.10.253.164, label 2689, metric 0, path Local, extended community RT:100:109

And this is how the IPv6 prefix is shown on the P1 (10.10.253.161) when received from PE1 (10.10.253.164):

P1#sh bgp vpnv6 unicast neighbors 10.10.253.164 routes
BGP router identifier 10.10.253.161, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 3888712472
BGP main routing table version 3
BGP NSR Initial initsync version 3 (Reached)
BGP scan interval 60 secs

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
Route Distinguisher: 100:109
*>i2001:DB8:2:60::22/127
                      10.10.253.164           0    100      0 ?

Now, if the old fact was existent in the case of VPNv6 prefixes as in the case of simple IPv6 prefixes, then the IPv6 BGP session shouldn't even come up. Instead, it comes up and works fine. But, in order to confuse me even more, the next-hop of an IPv6 prefix is an IPv4 address (!!!).

Reminder...
Old Fact: You can't have an IPv4 address as next-hop for IPv6 prefixes

Quoting from RFC 4659 (BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN):

When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:

- whose 8-octet RD is set to zero, and

- whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6  address [V6ADDR] containing the IPv4 address of the advertising BGP speaker. This IPv4 address must be routable by the other BGP Speaker.


Now, if we check the PE2 on the other side, who is also getting some IPv6 prefixes from CE2, we'll notice that everything is fine and according to everything we know about 6VPE. So this time the IPv6 prefixes have a v4-mapped IPv6 address as next-hop, which is the expected output for a 6VPE topology.

This is how an IPv6 prefix is shown on the P2 (10.10.231.4) when received from PE2 (10.10.253.165):

P2#sh bgp vpnv6 unicast all neighbors 10.10.253.165 routes
BGP table version is 4, local router ID is 10.10.231.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:141
*>i2001:DB8:10:1::22/127
                    ::FFFF:10.10.253.165
                                             0    100      0 65141 ?

Let's summarize:

P1: IPv6 prefix 2001:DB8:2:60::22/127 with 10.10.253.164 as NH
P2: IPv6 prefix 2001:DB8:10:1::22/127 with ::FFFF:10.10.253.165 as NH

If you still haven't figured out the difference between P1 and P2 based on the outputs given, let me tell you that P1 is an IOS-XR (4.2.x) based platform while P2 is an IOS (15.x) based one. In terms of functionality everything works fine, because internally IOS-XR uses the correct v4-mapped IPv6 address as next-hop. It just doesn't display it on the CLI, neither on the debugs.

Now you might wonder why such a difference in IOS-XR behavior. After waiting for several weeks for a lab reproduction from Cisco, because nobody knew about this behavior, i got a very enlightening answer from the developers:

IOS-XR decided it's best to display the actual next hop which is a v4 nexthop and is also registered with the v4 RIB for tracking purposes, rather than what is transported in the NLRI and matches the output of everything else. So the behaviour is indeed expected and works 'by design'.

Reminder...
Old Fact: You can't have an IPv4 address as next-hop for IPv6 prefixes

Don't you love those guys? First they tell that you can't have a v4 nexthop, but now they tell you that it's better to display a v4 nexthop, although the actual NLRI has a different one.

Luckily, someone inside Cisco (thx Xander once more) agreed that this behavior is misleading, so an enhancement request (CSCuj74543) was opened. If you would like to change this behavior too, please link your case to this DDTS. At the same time a documentation DDTS (CSCuj76745) was opened in order to officially describe this IOS-XR "expected" and "by design" behavior on CCO.

aggregate-address ... summary-only-after-a-while

As it seems, there is always something that you think you know, until it's proven the other way around.

Some years ago, when i was studying for the CCIE, i knew that in order to suppress more specific routes from an aggregate advertisement in BGP, you could use the "aggregate-address .... summary-only" command. And i believed it until recently.

Let's suppose you have the following config in a ASR1k (10.1.1.1) running 15.1(2)S2:

router bgp 100
 bgp router-id 10.1.1.1
 neighbor 10.2.2.2 remote-as 100
 neighbor 10.2.2.2 update-source Loopback0
...
 address-family ipv4
  aggregate-address 10.10.10.0 255.255.255.0 summary-only
  redistribute connected
  neighbor 10.2.2.2 activate
...

Then you have 2 subscribers logging in.
With "show bgp" the 2 /32 routes under 10.10.10.0/24 seem to be suppressed and the /24 is in the BGP table as it should be:

*> 10.10.10.0/24    0.0.0.0                            32768 i
s> 10.10.10.3/32    0.0.0.0                  0         32768 ?
s> 10.10.10.4/32    0.0.0.0                  0         32768 ?

but doing some "debug bgp updates/events" reveals the following:

BGP(0): 10.2.2.2 send UPDATE (format) 10.10.10.3/32, next 10.1.1.1, metric 0, path Local
BGP(0): 10.2.2.2 send UPDATE (format) 10.10.10.4/32, next 10.1.1.1, metric 0, path Local

...and after a while:

BGP: aggregate timer expired

BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.10.10.3/32
BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.10.10.4/32

At the same time on the peer router (10.2.2.2) you can see the above 2 /32 routes being received:

RP/0/RP0/CPU0:ASR9k#sh bgp neighbor 10.1.1.1 routes | i /32
*>i10.10.10.3/32    10.1.1.1            0    100      0 ?
*>i10.10.10.4/32    10.1.1.1            0    100      0 ?

and immediately afterwards you can see the 2 /32 routes being withdrawn:

RP/0/RP0/CPU0:ASR9k#sh bgp neighbor 10.1.1.1 routes | i /32

Cisco is a little bit contradicting on this behavior, as usual.


According to Cisco tac, the default aggregation logic runs every 30 seconds, but bgp update processing will be done almost every 2 seconds. That's the reason the route is being updated initially and later withdrawn (due to the aggregation processing following the initial update). They also admit that the root cause of this problem is with the BGP code. The route will be advertised as soon as the best path is completed. It may take 30 seconds or more for the aggregation logic to complete and withdraw the more specific route.

Then we also have the following:

Bug CSCsu96698

BGP: /32 route being advertised while 'summary-only' is configured

Symptoms: More specific routes are advertised and withdrawn later even if config aggregate-address net mask summary-only is configured. The BGP table shows the specific prefixes as suppressed with s>

Conditions: This occurs only with very large configurations.

Workaround: Configure a distribute-list in BGP process that denies all of the aggregation child routes.

Related Bug Information

It takes 30 seconds for BGP to form aggregate route

Symptom: for approximately 30 seconds router announces specific prefixes instead of aggregate route

Conditions: bgp session up/down

Workaround: unknown yet

Release notes of 12.2SB and 12.0S

The periodic function is by default called at 60 second intervals. The aggregate processing is normally done based on the CPU load. If there is no CPU load, then the aggregate processing function would be triggered within one second. As the CPU load increases, this function call will be triggered at higher intervals and if the CPU load is very high it could go as high as the maximum aggregate timer value configured via command. By default this maximum value is 30 seconds and is configurable with a range of 6-60 seconds and in some trains 0. So, if default values are configured, then as the CPU load increases, the chances of hitting this defect is higher.

Release notes of 12.2(33)SXH6

CLI change to bgp aggregate-timer command to suppress more specific routes.

Old Behavior: More specific routes are advertised and withdrawn later, even if aggregate-address
summary-only is configured. The BGP table shows the specific prefixes as suppressed.

New Behavior: The bgp aggregate-timer command now accepts the value of 0 (zero), which
disables the aggregate timer and suppresses the routes immediately.

Command Reference for "bgp aggregate-timer"

To set the interval at which BGP routes will be aggregated or to disable timer-based route aggregation, use the bgp aggregate-timer command in address-family or router configuration mode. To restore the default value, use the no form of this command.

bgp aggregate-timer seconds
no bgp aggregate-timer

Syntax Description

seconds

Interval (in seconds) at which the system will aggregate BGP routes.

•The range is from 6 to 60 or else 0 (zero). The default is 30.
•A value of 0 (zero) disables timer-based aggregation and starts aggregation immediately.

Command Default

30 seconds

Usage Guidelines

Use this command to change the default interval at which BGP routes are aggregated.

In very large configurations, even if the aggregate-address summary-only command is configured, more specific routes are advertised and later withdrawn. To avoid this behavior, configure the bgp aggregate-timer to 0 (zero), and the system will immediately check for aggregate routes and suppress specific routes.

The interesting part is that the command reference for "aggregate-address ... summary-only" doesn't mention anything about this behavior in order to warn you.

Using the summary-only keyword not only creates the aggregate route (for example, 192.*.*.*) but also suppresses advertisements of more-specific routes to all neighbors. If you want to suppress only advertisements to certain neighbors, you may use the neighbor distribute-list command, with caution. If a more-specific route leaks out, all BGP or mBGP routers will prefer that route over the less-specific aggregate you are generating (using longest-match routing).


The following debug logs show the default aggregate-timer which is 30 secs, vs the default BGP scan timer which is 60 secs:

Nov 12 21:45:32.468: BGP: Performing BGP general scanning
Nov 12 21:45:38.906: BGP: aggregate timer expired
Nov 12 21:46:09.637: BGP: aggregate timer expired
Nov 12 21:46:32.487: BGP: Performing BGP general scanning
Nov 12 21:46:40.379: BGP: aggregate timer expired
Nov 12 21:47:11.099: BGP: aggregate timer expired
Nov 12 21:47:32.506: BGP: Performing BGP general scanning
Nov 12 21:47:41.828: BGP: aggregate timer expired
Nov 12 21:48:12.547: BGP: aggregate timer expired
Nov 12 21:48:32.525: BGP: Performing BGP general scanning
Nov 12 21:48:43.268: BGP: aggregate timer expired
Nov 12 21:49:13.989: BGP: aggregate timer expired
Nov 12 21:49:32.544: BGP: Performing BGP general scanning
Nov 12 21:49:44.765: BGP: aggregate timer expired
Nov 12 21:50:15.510: BGP: aggregate timer expired

Guess what! After changing the aggregate-timer to 0, the cpu load increases by a steady +10%, due to the BGP Router process!

ASR1k#sh proc cpu s | exc 0.00
CPU utilization for five seconds: 17%/6%; one minute: 16%; five minutes: 15%
PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
 61   329991518  1083305044        304  4.07%  4.09%  3.93%   0 IOSD ipc task
340   202049403    53391862       3784  1.35%  2.10%  2.11%   0 VTEMPLATE Backgr
404    84594181  2432529294          0  1.19%  1.18%  1.14%   0 PPP Events
229    49275197     1710570      28806  0.71%  0.33%  0.39%   0 QoS stats proces
152    39536838   801801056         49  0.63%  0.56%  0.51%   0 SSM connection m
159    51982155   383585236        135  0.47%  0.66%  0.64%   0 SSS Manager

ASR1k#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ASR1k(config)#router bgp 100
ASR1k(config-router)# address-family ipv4
ASR1k(config-router-af)# bgp aggregate-timer 0
ASR1k(config-router-af)#^Z

...and after a while:

ASR1k#sh proc cpu s | exc 0.00
CPU utilization for five seconds: 29%/6%; one minute: 26%; five minutes: 25%
PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
394   143774989    19776654       7269  9.91%  7.93%  7.32%   0 BGP Router
 61   329983414  1083280872        304  4.79%  3.97%  3.90%   0 IOSD ipc task
340   202044852    53390504       3784  2.71%  2.22%  2.04%   0 VTEMPLATE Backgr
404    84591714  2432460324          0  1.03%  1.16%  1.09%   0 PPP Events
159    51980758   383575060        135  0.79%  0.66%  0.62%   0 SSS Manager
152    39535734   801779715         49  0.63%  0.54%  0.50%   0 SSM connection m

Conclusions

1) By default, the "aggregate-address ... summary-only" command doesn't immediately stop the announcement of more specific routes, as it's supposed to. You need to also change the BGP aggregate-timer to 0.
2) After changing the BGP aggregate-timer to 0, the announcement of more specific routes stops, but the cpu load increases by 10%.


C'mon Cisco! You gave us NH Address Tracking and PIC, and you can't fix the aggregation process?

How Multi is MP-BGP in IOS-XR?

This caught me on surprise. I had an impression that IOS-XR as an advanced operating system would support all kinds of multi-protocol transferability over BGP.

As it seems, there is an issue when transferring IPv6 prefixes over an IPv4 peering or IPv4 prefixes over an IPv6 peering. This happens for sure on ASR9k running latest 4.1.0, but i haven't verified it on the CRS yet.

IPv4 prefixes over IPv6 peering
This doesn't seem to be supported based on the available configuration options.
What is even more worrying, is that no other address family is supported too.

RP/0/RSP0/CPU0:ASR#conf t
RP/0/RSP0/CPU0:ASR(config)#router bgp 100
RP/0/RSP0/CPU0:ASR(config-bgp)#neighbor 2001::1:2:3
RP/0/RSP0/CPU0:ASR(config-bgp-nbr)#address-family ?
  ipv6  IPv6 Address Family

IPv6 prefixes over IPv4 peering
This is supported according to the configuration options, but it doesn't work.
Cisco also insists that this is definitely supported.

RP/0/RSP0/CPU0:ASR#conf t
RP/0/RSP0/CPU0:ASR(config)#router bgp 100
RP/0/RSP0/CPU0:ASR(config-bgp)#neighbor 10.11.254.37
RP/0/RSP0/CPU0:ASR(config-bgp-nbr)#address-family ?
  ipv4   IPv4 Address Family
  ipv6   IPv6 Address Family
  l2vpn  L2VPN Address Family
  vpnv4  VPNv4 Address Family
  vpnv6  VPNv6 Address Family

As soon as you enable the IPv6 address family under the IPv4 neighbor, the BGP session is dropped and it never comes up.

RP/0/RSP0/CPU0:ASR#sh bgp sum
BGP router identifier 10.11.254.38, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0000000   RD version: 1
BGP main routing table version 1
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               1          1          1          1           1           1

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.11.254.37      0  100        0       0        0    0    0 00:00:00 Idle

Also, debug shows that there are no tries of BGP to establish a session. It's like BGP gets disabled.

The only doc that refers such a limitation (in IOS-XR 3.3 for CRS) is the one in http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.3/conversion/reference/guide/cn33main.html#wp1028960

A given address family is only supported with a neighbor whose address is from that address family. For instance, IPv4 neighbors support IPv4 unicast and multicast address families, and IPv6 neighbors support IPv6 unicast and multicast address families. However, you cannot exchange IPv6 routing information with an IPv4 neighbor and vice versa.

I searched all CCO for more information, but i didn't manage to find something useful. Does anyone have extra information to share? TAC is struggling (as usual) to find an answer...

Update #1
Cisco verified once more that this is a supported configuration. Arie Vayner (and later tac) proposed to add an IPv6 address to the interface being used as an IPv4 next-hop. Indeed, this solved the problem and the BGP session came up. But then it became even more interesting...

Two IPv6 prefixes are learned from the IPv4 neighbor. Next-hop is an IPv6 address.

RP/0/RSP0/CPU0:ASR#sh bgp ipv6 uni 
BGP router identifier 10.11.254.38, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0800000   RD version: 5
BGP main routing table version 5
BGP scan interval 60 secs

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
* i2001::1:2:3/128    2003::1:2:3              0    100      0 ?
* i2003::/64          2003::1:2:3              0    100      0 ?

Processed 2 prefixes, 2 paths

If i remove the IPv6 address from the interface that is being used as next-hop (the one i added before), then i automatically get an IPv6 prefix with an IPv4 next-hop!!!

RP/0/RSP0/CPU0:core-distr-kln-02#sh bgp ipv6 uni 
BGP router identifier 10.11.254.38, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0800000   RD version: 6
BGP main routing table version 6
BGP scan interval 60 secs

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
*>i2001::1:2:3/128    10.11.254.41             0    100      0 ?

Processed 1 prefixes, 1 paths

The BGP session stays up, until something happens that will reset it. Then it will stay down forever, as it was happening in the beginning.

I must say that i cannot endorse such an implementation. Using exactly the same configuration, you get different results, depending on the order of (un)configuring things. Also, i cannot understand why the establishment of an IPv4 BGP session that is going to negotiate IPv4/IPv6 address-family capabilities should depend on whether an IPv6 next-hop exists or not. That should be left for the NLRI exchange routine.

After all, RFC 4271 defines among others two error conditions for the NEXT_HOP attribute:

If the NEXT_HOP attribute field is syntactically incorrect, then the Error Subcode MUST be set to Invalid NEXT_HOP Attribute. The Data field MUST contain the incorrect attribute (type, length, and value). Syntactic correctness means that the NEXT_HOP attribute represents a valid IP host address.

If the NEXT_HOP attribute is semantically incorrect, the error SHOULD be logged, and the route SHOULD be ignored. In this case, a NOTIFICATION message SHOULD NOT be sent, and the connection SHOULD NOT be closed.


Update #2
After the developers got involved, we ended up with the following:

1. In IOS-XR you need an IPv6 NH in order to activate the IPv6 AF for an IPv4 BGP session.
2. If you don't have an IPv6 NH, then the IPv4 BGP session won't even come up.
3. The above was done to protect against misconfiguration, because otherwise you would get a misleading v4 mapped v6 address as NH.
4. If you have an IPv6 NH, then the IPv4 BGP session with the IPv6 AF will come up.
5. If afterwards you remove the IPv6 NH, then the session deliberately remains up and you get a misleading v4 mapped v6 address as NH.

Cisco agreed (thx Xander) that the behavior in 3 and 5 contradict each other, so a short-term solution (update the documentation and print a warning message) got recorded in CSCtq26829.

Trying to calculate the IPv6 BGP table in 2015

As you may have already noticed, during the last months there isn't anything new written here by me. This is mainly due to two reasons: 1) lack of free time due to new responsibilities in my company and 2) most of my writing happens in our internal wiki (almost 200 "docs" during the last 12 months!).

On the other hand, there are a lot of "new" things happening in the internet, one of them being the IPv6 "paranoia". Since we have made IPv6 be a strict requirement in my company for any new product evaluation during the last 2 years, one of the things i'm trying lately to calculate is the size of the IPv6 BGP routing table in the forthcoming years.

Geoff has a diagram showing the size of IPv4 BGP table from 1994 till today.

As you can see, it started at ~20k in 1994 and has reached ~360k in 2011.

Imho, it's too risky to believe the same trend-line will also be used by IPv6. I expect IPv6 to have a higher rate and a sharper curve, especially in the next 2 years, where IPv4 will probably lower its increase rate. The only thing that can stop this is a translation method that works for everything (current translations have a lot of issues). If such a thing doesn't appear soon (lately, IPv6 related RFCs are being updated/published/expired quite frequently), everyone will soon or later try to move to IPv6, meaning more routes in the global IPv6 BGP table.

Currently, the IPv6 BGP table has ~5k routes, but the potential for rapid increase seems quite promising. As you can see in the following diagram, the IPv6 table has near-doubled its size during the last year and 2011 started quite aggressively.

Based on the above diagram, one could suppose the increase will continue to happen on the same rate during the next years too.

Another approach is based on the number of prefixes that each ASN announces. The average in IPv4 is a steady ~10 prefixes per ASN all these years (currently there are ~37k IPv4 ASNs and ~360k IPv4 routes). The average in IPv6 is 1.4 prefixes per ASN (currently there are ~3.5k IPv6 ASNs and ~5k IPv6 routes), but that might change soon.

Another thing to keep in mind is the average prefix size in IPv6. It started as ~/33, had many up-downs and it has now reached ~/38. This will probably keep on showing this up-down behavior, but in general i expect a small increase as time passes by, for the reason i explain below. Also, having as a reference the IPv4 diagram, where it has stabilized somewhere above /22, i expect the IPv6 one to stabilize around /44.

IPv4 didn't have a competition and/or push from another protocol all the past years, so its increase was based solely in the number of new networks being connected to the internet. IPv6 has to support all current IPv4 networks in a shorter time-frame that IPv4 did (the translation case applies here too), plus all the new ones that are coming out due to more devices getting connected to the internet. This of course doesn't necessarily mean more IPv6 prefixes in the BGP table.

A /32 is usually what a provider gets these days when asking of IPv6 space. And although a single /32 announcement could probably cover all routing needs of the provider, this is difficult to happen in reality. The usual interconnections between providers are based on multiple 10 Gbps or 2,5 Gbps links. In order to distribute the /32 traffic among all of them, something must be done in terms of traffic engineering; split the /32 in multiples of /40,/48, etc. (imho, a IPv4 /24 is like a IPv6 /48 in terms of network announcement; most providers will filter anything smaller). Currently this isn't needed, because IPv6 traffic is minimal, so a single 1 Gbps link is more than enough. But in the near future, a 10 Gbps link won't be enough to service a provider's /32.

Meanwhile, 40 Gbps and 100 Gbps are around the corner. I don't know if these will become a commodity before IPv6 traffic explosion. If yes, we might see IPv6 table increasing in the beginning and decreasing after a while.

Regarding vendors, the things are quite complicated as usual. Here is the information i managed to gather about IPv6 routes capacity (FIB), based on the available info on the internet.

Cisco CRS-1 : 1m IPv6 routes
Cisco ASR9k : 1m IPv6 routes
Cisco ASR1k/RP2 : 2m/4m IPv6 routes (?)
Cisco ASR1k/RP1 : 250k IPv6 routes
Cisco C12k : 450k IPv6 routes
Cisco 7600/CXL : 500k IPv6 routes
Cisco 6500/CXL :  500k IPv6 routes
Juniper T640 : 750k IPv6 routes
Juniper MX960 : 720k IPv6 routes
AlcaLu 7750 : 512k IPv6 routes (RADIX compression)
Brocade XMR : 240k IPv6 routes
Brocade MLX : 240k IPv6 routes
Ericsson SE1200 : 2m IPv6 routes

Note : These have not been verified by the vendors. If you have any other numbers, please inform me.

Also, before taking into account the above numbers, you should remember that dual-stack will consume IPv4+IPv6 space (future IPv4 estimations talk about 500k routes) and some of these numbers might be hardcoded, while some other are configurable.

A linear scenario starting from today would be the following, which would leads us to ~29k IP6 routes.

Some "exponential" scenarios starting from today would be the following, which would lead us to ~104k/141k/194k IPv6 routes.

Lastly, an exponential scenario based on past utilisation would be the following, which would lead us to ~32k IPv6 routes.

Personally, i would feel very safe with ~125k IPv6 routes until 2015. I would even risk for ~50k. Anyway, i believe it will be much easier to predict in 2 years from now.

As a last note, i have added a poll to the right regarding your estimation about the IPv6 BGP table in 2015. Please feel free to submit your vote.

Decoding the RIPE BGP experiment

A lot of you probably saw your BGP routers go crazy on Friday 27th of August in the morning, especially if you happened to have a CRS (or another router running IOS-XR, like a C12k or ASR9k) in your (or a near) network.

RIPE and Duke University decided to experiment with Quagga's BGP and the result was to make some routers reset their BGP sessions, because they were receiving malformed BGP update packets. Malformed packets were generated by other routers in the middle, not by the Quagga BGP daemon where the experiment started.

Error messages generated on BGP routers that had peerings with affected (i.e. IOS-XR) routers, were like the following:

%BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 3/1 (update malformed) 188  bytes F0630BB8 00000000 00000000 00000000 00
BGP: x.x.x.x Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0118
0200 0000 FD40 0101 0040 0206 0202 0D1C 316E 4003 04C3 10A1 6180 0404 0000 0000 4005 0400 0000 3CC0 081C 0D1C 0002 0D1C 0016 0D1C 0056 0D1C
01F7 0D1C 029A 0D1C 0813 FDE8 FDDE F063 0BB8 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 185D AF90

According to BGP's RFC, the "3/1" in the error message translates to Code "UPDATE Message Error" and Subcode "Malformed Attribute List".

Wireshark offers an "easy" way to decode packets in ASCII format, as long as you feed them in the right way. The following perl script (which is based on my previous ciscodump2text) will convert the BGP packet included in the above Cisco error messages into a format that can be understood by Wireshark's text2pcap.

#!/opt/perl/bin/perl
#
# bgpdump2text v0.1
#
# Convert BGP packets included in Cisco BGP notification error messages 
# to a special text format that can then be fed into text2pcap
# so a pcap file for Wireshark can be created at the end.
# You have to remove any extra characters included in the error messages.
#
# Copyright (C) 2010 Tassos (http://ccie-in-3-months.blogspot.com)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see http://www.gnu.org/licenses/.

@packets = ();
$first_line = 0;


while (<>) {
        $line = $_;

        if ( ( $line =~ /^FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF/ ) || ( $first_line == 1 ) ) {
                $first_line = 1;

                $line =~ s/\s//g;
                $packets[1] .= $line;
        }
}

for ($i = 1; $i <= @packets; $i++) {

        if ( exists $packets[$i] ) {

                for ( $j = 0; $j < length($packets[$i]); $j += 2 ) {
                        if ( $j == 0 )  {
                                printf "# BGP Packet $i\n%08X", $j/2;
                        } elsif ( $j % 32 == 0 ) {
                                printf " #\n%08X", $j/2;
                        }
                        print " ".substr($packets[$i], $j, 2);
                }

                print " #\n";
        }
}

print "\n";

By using as input a text file with the BGP packet as shown in the original error message, you'll get an output text file ready to be processed by text2pcap.

The format the source text file (test-bgp.text) should have is the following.

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0118 0200 0000 FD40 0101 0040 0206 0202 0D1C
 316E 4003 04C3 10A1 6180 0404 0000 0000 4005 0400 0000 3CC0 081C 0D1C 0002 0D1C 001
6 0D1C 0056 0D1C 01F7 0D1C 029A 0D1C 0813 FDE8 FDDE F063 0BB8 0000 0000 0000 0000 00
00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0
000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 000
0 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 185D AF90

You just need to erase all extra characters from the original error message and it's ready. The actual data starts after the "Bad attributes" string. Keep in mind that the packet might have been spitted in more than one messages, like in the above case. Just remove the initial characters from every line and it'll be ok.

Script is executed like below:

tassos$ bgpdump2text test-bgp.text > test-bgp.txt

The generated text file (test-bgp.txt) will have the following contents:

# BGP Packet 1
00000000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF #
00000010 01 18 02 00 00 00 FD 40 01 01 00 40 02 06 02 02 #
00000020 0D 1C 31 6E 40 03 04 C3 10 A1 61 80 04 04 00 00 #
00000030 00 00 40 05 04 00 00 00 3C C0 08 1C 0D 1C 00 02 #
00000040 0D 1C 00 16 0D 1C 00 56 0D 1C 01 F7 0D 1C 02 9A #
00000050 0D 1C 08 13 FD E8 FD DE F0 63 0B B8 00 00 00 00 #
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 #
00000110 00 00 00 00 18 5D AF 90 #

Note : right now, only one packet can be processed.

In our case (BGP data only) we need to add a L2 header, an IP header and a TCP header with values that resemble BGP, so we add the required parameters in the text2pcap program:

C:\Program Files\Wireshark>text2pcap.exe -T 179,1025 -d test-bgp.txt test-bgp.pcap
Input from: test-bgp.txt
Output to: test-bgp.pcap
Generate dummy Ethernet header: Protocol: 0x800
Generate dummy IP header: Protocol: 6
Generate dummy TCP header: Source port: 179. Dest port: 1025
Start new packet
Wrote packet of 280 bytes at 0

-------------------------
Read 1 potential packet, wrote 1 packet

Now, if you load this pcap file into Wireshark, you'll get the following output:



As you can clearly see, there was an unknown attribute (with Type Code 99) inserted into the UPDATE message with the following characteristics:

Flags: Optional, Transitive, Partial, Extended Length
Type code : 99
Length : 3000 bytes

The length of the BGP UPDATE message has been defined as 280 in the BGP header, having 253 as total path attribute length, so something went clearly wrong.

This unknown attribute should have a length of 3000 bytes as defined in its length attribute, but it was only 184 bytes if you count the octets from where zeros start (after 0x0BB8) till the end. From this number comes 188 (184 + 4 for Flags/TypeCode/Length), the number that's included in the initial error message.

So, the length of the unknown attribute has been defined as 3000 into the packet, which is 0x0BB8 in hex. If you somehow remove the first octet, then it becomes 0xB8, which is 184 in decimal. If you add the 4 extra bytes (Flags, Type code, Length), then it becomes 188 and the sum of all attributes becomes 253, which is the one shown in the packet too.

In reverse order, if you calculate the supposed total path attribute length in case all attributes were correct, then it should be 3069, which is 0x0BFD in hex. If again you somehow remove the first octet, it becomes 0xFD (253).

I guess, in general anything larger than 0xFF (255) would have caused the same issue too.

Cisco issued an advisory after some hours, providing fixes for its IOS-XR software.


Regarding the behavior of BGP, the relevant RFC (4271) says the following, so everything was expected:

NOTIFICATION messages are sent in response to errors or special conditions. If a connection encounters an error condition, a NOTIFICATION message is sent and the connection is closed.
...
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.
...
Error checking of an UPDATE message begins by examining the path attributes. If the Withdrawn Routes Length or Total Attribute Length is too large (i.e., if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List.


There is also a lot of discussion happening regarding the notification and reset thing after this event and draft-ietf-idr-optional-transitive seems quite interesting.

Links
http://mailman.nanog.org/pipermail/nanog/2010-August/024837.html
http://www.networkworld.com/news/2010/082710-research-experiment-disrupts-internet-for.html
http://www.renesys.com/blog/2010/08/house-of-cards.shtml
https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/

Question
Is there a chance by creating "dummy" and large attributes to cause memory issues on BGP routers?

BGP - Can an aggregate-address suppress another aggregate-address on the same router?

Or can an aggregate-address aggregate another aggregate-address on the same router?

Today i was playing with BGP a little (i found some time to prepare for my CCIP) and here is what i found out:

Suppose you have the following config on a router:

interface Loopback1
 ip address 1.1.1.1 255.255.255.128
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.128
 aggregate-address 1.1.0.0 255.255.0.0 summary-only
 aggregate-address 1.1.1.0 255.255.255.0 summary-only
 neighbor 10.10.10.2 remote-as 2
 no auto-summary

What do you think "sh ip bgp" will show? (please take some time and think about it...)

To be honest, as a first thought i was hoping it would display only the 1.1.0.0/16 summary, which actually "overlaps" the 1.1.1.0/24 summary.

Guess what?

R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.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
*> 1.1.0.0/16       0.0.0.0                            32768 i
s> 1.1.1.0/25       0.0.0.0                  0         32768 i
*> 1.1.1.0/24       0.0.0.0                            32768 i

According to Cisco, in order to aggregate an address, you must have a more-specific route of that address in the BGP table. And if you want the more-specific route to be suppressed, you must use the "summary-only" keyword.

So, if we want to be as strict as possible, in our case we do have a more-specific route in the BGP table (and in the routing table).

R1#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.10.10.2
  Local, (aggregated by 1 1.1.1.1)
    0.0.0.0 from 0.0.0.0 (1.1.1.1)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
R1#
R1#sh ip route 1.1.1.0 255.255.255.0
Routing entry for 1.1.1.0/24
  Known via "bgp 1", distance 200, metric 0, type locally generated
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
      AS Hops 0

Although the aggregation part seems to be working fine (it actually isn't), the suppression one isn't. As it seems, an aggregate-address cannot suppress another more-specific aggregate-address, when both are created locally in the same router.

Now, let's change the configuration and make it more interesting by removing the "summary-only" keyword from the more-specific aggregate-address :

router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.128
 aggregate-address 1.1.0.0 255.255.0.0 summary-only
 aggregate-address 1.1.1.0 255.255.255.0
 neighbor 10.10.10.2 remote-as 2
 no auto-summary


R1#clear ip bgp *

R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.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
*> 1.1.0.0/16       0.0.0.0                            32768 i
s> 1.1.1.0/25       0.0.0.0                  0         32768 i
*> 1.1.1.0/24       0.0.0.0                            32768 i

What do you think of that? We still have the same output. The more-specific (lower level) aggregate-address is not suppressed, but the more-specific network is (by the 1.1.0.0/16 aggregate-address).

Why is that? Although i'm not sure, looking at the following debugs (after adding another level of aggregation using the "aggregate-address 1.0.0.0 255.0.0.0 summary-only" command and reseting the bgp session), i have come to this explanation:

*Mar  1 02:28:52.107: BGP(0): nettable_walker 1.1.1.0/25 route sourced locally
*Mar  1 02:28:52.111: BGP(0): Aggregate processing for IPv4 Unicast
*Mar  1 02:28:52.111: BGP(0): For aggregate 1.0.0.0/8
*Mar  1 02:28:52.111: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): sub-prefix : 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): Needs to be re-aggregated
*Mar  1 02:28:52.115: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): 1.0.0.0/8 aggregate has 1.1.1.0/25 more-specific
*Mar  1 02:28:52.115: BGP(0): 1.0.0.0/8 aggregate created, attributes updated
*Mar  1 02:28:52.115: BGP(0): created aggregate route for 1.0.0.0/8
*Mar  1 02:28:52.115: BGP(0): 1.0.0.0/8 subtree has an entry 1.0.0.0/8
*Mar  1 02:28:52.115: BGP(0): 1.0.0.0/8 subtree has another entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed
*Mar  1 02:28:52.115: BGP(0): For aggregate 1.1.0.0/16
*Mar  1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): sub-prefix : 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): Needs to be re-aggregated
*Mar  1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): 1.1.0.0/16 aggregate has 1.1.1.0/25 more-specific
*Mar  1 02:28:52.115: BGP(0): 1.1.0.0/16 aggregate created, attributes updated
*Mar  1 02:28:52.115: BGP(0): created aggregate route for 1.1.0.0/16
*Mar  1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16
*Mar  1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed
*Mar  1 02:28:52.115: BGP(0): For aggregate 1.1.1.0/24
*Mar  1 02:28:52.115: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): sub-prefix : 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): Needs to be re-aggregated
*Mar  1 02:28:52.115: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): 1.1.1.0/24 aggregate has 1.1.1.0/25 more-specific
*Mar  1 02:28:52.115: BGP(0): 1.1.1.0/24 aggregate created, attributes updated
*Mar  1 02:28:52.115: BGP(0): created aggregate route for 1.1.1.0/24
*Mar  1 02:28:52.115: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25
*Mar  1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed
*Mar  1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/24:
*Mar  1 02:28:52.115: BGP(0): Revise route installing 1 of 1 route for 1.0.0.0/8 -> 0.0.0.0 to main IP table
*Mar  1 02:28:52.119: RT: network 1.0.0.0 is now variably masked
*Mar  1 02:28:52.119: RT: add 1.0.0.0/8 via 0.0.0.0, bgp metric [200/0]
*Mar  1 02:28:52.119: RT: NET-RED 1.0.0.0/8
*Mar  1 02:28:52.119: BGP(0): Revise route installing 1 of 1 route for 1.1.0.0/16 -> 0.0.0.0 to main IP table
*Mar  1 02:28:52.119: RT: add 1.1.0.0/16 via 0.0.0.0, bgp metric [200/0]
*Mar  1 02:28:52.119: RT: NET-RED 1.1.0.0/16
*Mar  1 02:28:52.119: BGP(0): nettable_walker 1.1.1.0/25 route sourced locally
*Mar  1 02:28:52.119: BGP(0): Revise route installing 1 of 1 route for 1.1.1.0/24 -> 0.0.0.0 to main IP table
*Mar  1 02:28:52.119: RT: add 1.1.1.0/24 via 0.0.0.0, bgp metric [200/0]
*Mar  1 02:28:52.119: RT: NET-RED 1.1.1.0/24

During the initial scanning, the aggregate processing algorithm of BGP doesn't even check the locally aggregated addresses (is recursive scanning too difficult/dangerous to implement?), because they aren't in the BGP routing table at the time of scanning (i guess if the scanning was happening from more-specific to less-specific, it would find them). So it checks only the networks that are injected into BGP through the 3 known ways (network command, redistribution, other ASs). In our case, every configured aggregate-address is aggregating and suppressing only the locally configured more-specific network. Specifically, the more-specific local network is aggregated & suppressed 3 times, one for each aggregate-address definition.

The result?

R1#sh ip bgp
BGP table version is 6, local router ID is 1.1.1.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
*> 1.0.0.0          0.0.0.0                            32768 i
*> 1.1.0.0/16       0.0.0.0                            32768 i
s> 1.1.1.0/25       0.0.0.0                  0         32768 i
*> 1.1.1.0/24       0.0.0.0                            32768 i

If we add the less-specific aggregate after the BGP has already started, we get different debug logs:

*Mar  1 00:05:26.995: BGP(0): Aggregate processing for IPv4 Unicast
*Mar  1 00:05:26.995: BGP(0): For aggregate 1.0.0.0/8
*Mar  1 00:05:26.995: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.0.0/16
*Mar  1 00:05:26.999: BGP(0): sub-prefix : 1.1.0.0/16
*Mar  1 00:05:26.999: BGP(0): Needs to be re-aggregated
*Mar  1 00:05:26.999: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.0.0/16
*Mar  1 00:05:27.003: BGP(0): 1.0.0.0/8 aggregate has 1.1.1.0/25 more-specific
*Mar  1 00:05:27.007: BGP(0): 1.0.0.0/8 aggregate created, attributes updated
*Mar  1 00:05:27.007: BGP(0): created aggregate route for 1.0.0.0/8
*Mar  1 00:05:27.011: BGP(0): 1.0.0.0/8 subtree has an entry 1.0.0.0/8
*Mar  1 00:05:27.011: BGP(0): 1.0.0.0/8 subtree has another entry 1.1.0.0/16
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.0.0/16: not suppressed
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/24: not suppressed
*Mar  1 00:05:27.011: BGP(0): For aggregate 1.1.0.0/16
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): sub-prefix : 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): Needs to be re-aggregated
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 aggregate has 1.1.1.0/25 more-specific
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 aggregate updated
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16
*Mar  1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/24: not suppressed
*Mar  1 00:05:27.011: BGP(0): For aggregate 1.1.1.0/24
*Mar  1 00:05:27.011: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): sub-prefix : 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): Needs to be re-aggregated
*Mar  1 00:05:27.011: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): 1.1.1.0/24 aggregate has 1.1.1.0/25 more-specific
*Mar  1 00:05:27.011: BGP(0): 1.1.1.0/24 aggregate updated
*Mar  1 00:05:27.011: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed
*Mar  1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/24:
*Mar  1 00:05:27.011: BGP(0): Revise route installing 1 of 1 route for 1.0.0.0/8 -> 0.0.0.0 to main IP table
*Mar  1 00:05:27.011: RT: add 1.0.0.0/8 via 0.0.0.0, bgp metric [200/0]
*Mar  1 00:05:27.011: RT: NET-RED 1.0.0.0/8

This time, all the existing more-specific aggregates are scanned, but they are clearly not suppressed.

According to RFC 4271:

3.2.  Routing Information Base

   The Routing Information Base (RIB) within a BGP speaker consists of
   three distinct parts:

      a) Adj-RIBs-In: The Adj-RIBs-In stores routing information learned
         from inbound UPDATE messages that were received from other BGP
         speakers.  Their contents represent routes that are available
         as input to the Decision Process.

      b) Loc-RIB: The Loc-RIB contains the local routing information the
         BGP speaker selected by applying its local policies to the
         routing information contained in its Adj-RIBs-In.  These are
         the routes that will be used by the local BGP speaker.  The
         next hop for each of these routes MUST be resolvable via the
         local BGP speaker's Routing Table.

      c) Adj-RIBs-Out: The Adj-RIBs-Out stores information the local BGP
         speaker selected for advertisement to its peers.  The routing
         information stored in the Adj-RIBs-Out will be carried in the
         local BGP speaker's UPDATE messages and advertised to its
         peers.

...
   The Decision Process takes place in three distinct phases, each
   triggered by a different event:

      a) Phase 1 is responsible for calculating the degree of preference
         for each route received from a peer.

      b) Phase 2 is invoked on completion of phase 1.  It is responsible
         for choosing the best route out of all those available for each
         distinct destination, and for installing each chosen route into
         the Loc-RIB.

      c) Phase 3 is invoked after the Loc-RIB has been modified.  It is
         responsible for disseminating routes in the Loc-RIB to each
         peer, according to the policies contained in the PIB.  Route
         aggregation and information reduction can optionally be
         performed within this phase.

...
9.2.2.2.  Aggregating Routing Information

   Aggregation is the process of combining the characteristics of
   several different routes in such a way that a single route can be
   advertised.  Aggregation can occur as part of the Decision Process to
   reduce the amount of routing information that will be placed in the
   Adj-RIBs-Out.

If someone else can provide a better (preferred technical) explanation for both cases, i would be very happy to hear it.

Btw, someone must tell Cisco to write more detailed docs :
"Aggregation applies only to routes that exist in the BGP routing table. An aggregated route is forwarded if at least one more specific route of the aggregation exists in the BGP routing table"

Anyhow, you may want to keep that in mind.

1st Mock Lab - 74 %

On past Friday i had my first Mock Lab attempt, which proved easier that expected.

I was expecting IGP redistribution in multiple points, IPv6 BGP/OSPF/RIP routing, DVMRP, etc, but most of the sections where quite "easy". That of course doesn't mean that i passed. I missed 10 whole points in the Bridging & Switching section, which is one of my favorites.

The reason? I was in a hurry to finish the first sections which i have more experience with, in order to have enough time to do the rest. But, many questions were tricky and passing through them in a hurry, proved to be the wrong method. I missed 3 points on a simple task (because i didn't configure a vlan) and another 4 points (in two other questions) because of the first error.

There were only 2 sections that i didn't know at all and i had to improvise (one proved correct with a minor error in an acl entry, the other totally wrong). Also there were another 4 sections that i had to look into the Doc CD. At least i have now learned to use the Doc CD more efficiently. It's surely invaluable in such situations.

Also, when i finished, i had only 30 mins left (according to the actual 8-hour lab, because in the mock lab you're allowed to exceed this time by 3 hours). So instead of looking back all the sections in order to verify them, i decided to reload all routers! What was even more disastrous, was the fact that i reloaded them all at the same time and i didn't look at their logs while booting.

The result? After the reload, something wasn't working as expected. After a quick search i found one router which seemed not to be running OSPF. I checked its configuration (thank god i had saved all my session locally) and i found that there were two "neighbor" commands missing! I added them and reloaded again. This time i watched the logs and there was an error message saying that this particular command is not supported on this kind of topologies (a bug? command is accepted while configuring, but it's rejected after reloading). So i saved my configuration and warned (through email) the proctor about this behavior.

The answer from the support department the next day was to post my "problem" on the forum and i'll get an answer there. Of course, after a week there's still no answer there. And after a quick search on their forum, i found out that many questions remain unanswered. Too bad, because i have heard a lot of good words about InternetworkExpert's training material. I wanted to test their Mock Labs and maybe buy their Workbooks, but this kind of support made me rethink it. If i have one question in the Mock lab (and gets unanswered), i 'll probably have tens in the Workbook labs. Anyway, i still have one Mock Lab from them. If they keep the same -high- price and/or wrong "attitude", i'll have to look at a different vendor.

Let's hope this Friday, i'll have something tougher. The goal still remains for something >50%.