优化Firefox 使其双倍速运行

设置内容如下：

使用其缓存特性减少Firefox内存使用率

1. 在Firefox浏览器地址栏中输入 “about:config” (无引号) .
2. 找到 “browser.sessionhistory.max_total_viewer”
3. 将其属性值改为 “0“;(零)

增加Firefox页面加载速度

1. 在lFirefox浏览器地址栏中输入 “about:config” 并且回车.
(一般情况下一般情况下一个页面仅发送一次请求.当你启用 pipelining it 将会发送多次请求, 这将大大加速Firefox页面加载速度.)

2. 更换以下内容:
设置“network.http.pipelining” 为 “true”
设置 “network.http.proxy.pipelining” 为 “true”
设置“network.http.pipelining.maxrequests” 为请求数量如 10.

这就意味着一次会发出10次请求.

3. 最后, 右键并且选择 New-> Integer. 命名 “nglayout.initialpaint.delay” 并且设置其值为“0“;.(零)

这个值是浏览器对收到信息的反应次数. 如果你是在使用宽带连接这样将加快Firefox页面加载速度.可选设置(可获得更快的加载速度) 如上新建如下变量New– > Interger or String

network.dns.disableIPv6: set “false”
“content.notify.backoffcount”: set “5“; (Five)
“plugin.expose_full_path”: set “true”.
“ui.submenuDelay”: set “0; (zero)

减少Firefox最小化时的内存使用量:

1. 同样在浏览器地址栏中输入about:config 并且回车.
2. 新建如下变量New -> Boolean.
3. 在弹出框中输入“config.trim_on_minimize”. 回车确认.
4. 选中True 并且回车s Enter.
5. 重启 Firefox.

BSCI: IP Multicast - PIM Routing Protocol

• PIM stands for Protocol Independent Multicast.
• The “protocol independent” part of the name refers to the fact that PIM uses the unicast routing protocol table to locate unicast addresses, regardless of how the table learned the addresses.
  • That is, the table could be formed by any unicast routing protocol such as EIGRP, OSPF, etc. and it does not have any bearings about its relationship with PIM.
• Unlike some unicast routing protocols, however, no routing updates are sent between PIM routers.
• Keep in mind that unicast routing protocols use multicast packets (or broadcast in some cases) to send their routing update traffic.

Terminologies

Distribution Trees

• When forwarding multicast packets, multicast-enabled routers use PIM to dynamically create distribution trees that control the path that IP multicast traffic takes through the network to deliver the packets to all receivers
• 2 Types of Distribution Trees
  • Source Tree
    • A source tree is created for each source router sending to each multicast group.
    • The root is at the source and has branches through the network to the receivers.
    • It is also know as source-routed or shortest path trees (SPTs) because the tree uses the most direct and shortest path to the receivers.
  • Shared Tree
    • A shared tree has one path or tree that is shared between all sources for each multicast group.
    • The shared tree uses one single common root called a rendezvous point (RP).
    • Sources would initially send their packets to the RP. From there the data is forwarded through the shared tree to the destination members.

Reverse Path Forwarding (RPF)

• This refers to the forwarding of multicast traffic away from the source, rather than forwarding to the receiver. It is the opposite operation of unicast routing.
• For multicast, the source IP address refers to the known source, and the destination IP address denotes a group of unknown receivers.
• RPF avoids routing loops by using the unicast routing table to determine the upstream (toward the source) and downstream (away from the source) neighbors and ensures that only one interface on the router is considered to be an incoming interface for data from a specific source.

• RPF check procedure:
  • Step 1. Router looks up the source address in the unicast routing table to determine if it has arrived on the interface that is on the reverse path back to the source.
  • Step 2. If packet has arrived on the interface leading back to the source, the RPF check is successful and the packet will be forwarded.
  • Step 3. If the RPF check in 2 fails, the packet is dropped.
• RPF is a fundamental concept in multicast routing that enables routers to correctly forward multicast traffic down the distribution tree. RPF makes use of the existing unicast routing table to determine the upstream and downstream neighbors. A router will only forward a multicast packet if it is received on the upstream interface. This RPF check helps to guarantee that the distribution tree will be loop free.

PIM Modes

• There are 2 main PIM modes:
  • Sparse Mode (PIM-SM)
    • Sparse mode uses a “pull” model to send multicast traffic.
    • Uses shared tree distribution, therefore an RP is required.
    • Sources register with RP.
    • When active receivers actively request to join a specific multicast group, routers along the path of these receivers register to join that group.
      • Using unicast routing table, these routers calculate whether they have a better metric to the RP or to the source itself.
      • Whichever device has a better metric, the join message is forwarded to that device.
  • Dense Mode (PIM-DM)
    • Dense mode uses a “push” model to flood multicast traffic to the entire network.
    • Uses source trees.
    • In this mode, routers that have no need for the data (because they are not connected to receivers that want the data or to other routers that want it) request that the tree is pruned so that they no longer receive the data.
• PIM Sparse-Dense mode is a hybrid of the 2 main PIM modes.

Multicast Distribution Trees

Source Distribution Trees

• Source trees are the simplest form of a multicast distribution tree.
• The root of the tree is at the source.
• It is also called a shortest path tree because it uses the shortest path through a network.

• In the above diagram, it illustrates an example of a shortest path tree (SPT) for group 224.1.1.1.
• The root is the source (Host A).
• Packets are forwarded according to the source and group address pair along the tree.
• The forwarding state associated with the source tree is referred to by the notation (S, G), pronounced “S comma G“.
  • S is the IP address of the source and G is the multicast group address.
  • Using this notation, the SPT for the example above is (192.1.1.1, 224.1.1.1)
• The (S, G) notation implies that a separate SPT exists for each individual source sending to each group.
  • For example, if Host B is also sending traffic to group 224.1.1.1 and Hosts A and C are receivers, the a separate (S, G) SPT would exist.
  • In the case of Host B being the source, the notation is (192.2.2.2, 224.1.1.1)

With source trees, a separate tree is built for every source S sending to group G.

Shared Distribution Trees

• Unlike source trees whose root is at the source, shared trees has a single common root placed at some chosen point in the network.
• This shared root is called a Rendezvous Point (RP).

• In the figure above, the root is located at Router D for multicast group 224.2.2.2.
• Sources send their traffic to the root and the traffic is forwarded down the share tree to reach all receivers.
  • In the example above, multicast traffic from the sources (Hosts A and D) travels to the root (Router D) and then is forwarded down the shared tree to the receivers (Hosts B and C).
• Because all sources in the multicast group use a common shared tree, the forwarding state for the shared tree is identified with the notation (*, G), pronounced “star comma G“.
  • * means all sources, and G represents the multicast group.
  • Therefore, the shared tree in the figure above is notated as (*, 224.2.2.2).

Comparison

• Shortest Path Trees
  • Have the advantage of creating the optimal path between the source and receivers. This will guarantee the minimum amount of network latency for forwarding multicast traffic.
  • However, because routers must maintain path information for each source, they use more memory and processing power.
• Shared Trees
  • Have the advantage of requiring the minimum amount of state in each router. This will lower the overall memory requirements for a network that only allows shared trees.
  • The disadvantage of shared trees is that under certain circumstances the paths between the source and receivers might not be the optimal paths. This could lead to some latency in packet delivery.

PIM Modes

PIM Dense Mode (PIM-DM)

• PIM-DM initially floods multicast traffic to all parts of the network.
• The traffic is sent out of all non-RPF interfaces where there is another PIM-DM neighbor on a directly connected member of the group.
• In figure 1 below:
  • multicast traffic is flooded throughout the entire network.
  • Traffic is received via each router’s RPF interface (interface in the direction of the source).
  • Multicast traffic is sent out each router’s non-RPF interface to all of its PIM-DM neighbors.
  • This flooding also results in some traffic arriving via the non-RPF interfaces as is the case for Routers A, B, C, and D.
  • Packets arriving via the non-PRF interfaces are discarded.

Figure 1: PIM-DM Initial Flooding

• In Figure 2 below:
  • PIM-DM prune messages (in red dotted arrows) are sent to stop unwanted traffic.
  • Prune messages are sent on an RPF interface only when the router has no downstream receivers for multicast traffic from the specific source.
  • In the example below, there is only one receiver, therefore all other paths are pruned.
  • Prune messages are also sent on non-RPF interfaces to shut off the flow of multicast traffic because it is arriving via an interface that is not on the shortest path to the source.

Figure 2: PIM-DM Pruning Unwanted Traffic

• The next illustration shows the result of pruning the unwanted multicast traffic:

Figure 3: PIM-DM Results After Pruning

• Although the flow of multicast traffic is no longer reaching most of the routers in the network, the (S, G) state still remains in all of them and will remain there until the source stops sending.
• In PIM-DM, all prune messages expire in 3 minutes.
  • After that, the multicast traffic is flooded again to all the routers.

PIM-Sparse Mode (PIM-SM)

• PIM-SM is described in RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM).
• Uses shared distribution trees, but it may also switch to use source distribution trees.
• Based on a pull model, traffic is forwarded only to those parts of the network that need it.
• PIM-SM uses an RP to coordinate forwarding of multicast traffic from a source to receivers.
• Senders register with the RP and send a single copy of multicast data through the RP to the registered receivers.
• Group members are joined to the shared tree by their local designated router (DR).
• A shared tree that is built this way is always rooted at the RP.
• It is preferred over PIM-DM for all production networks regardless of size and membership density.

• In the above diagram, an active receiver wants to join multicast group G.
• The last hop router (router attached to the Receiver) knows the IP address of the RP router for group G.
  • It sends a (*, G) join for this group toward the RP.
  • The (*, G) join travels hop-by-hop toward the RP building a branch of the shared tree that extends from the RP to the last-hop router directly connected to the receiver.
  • At this point, group G traffic may flow down the shared tree to the receiver.

CCIE ROUTING AND SWITCHING TRACK -- Lab Exam Blueprint

Please review the Lab Exam Overview for general information about the CCIE Routing and Switching lab exam. The blueprint is a detailed outline of the topics likely to appear on the lab exam. Knowledge of troubleshooting is an important skill and candidates are expected to diagnose and solve issues as part of the CCIE lab exam. The topics listed are guidelines and other relevant or related topics may also appear. In general, new product features become eligible for testing on CCIE lab exams six months after general release.

1. Bridging and Switching
   1. Frame relay
   2. Catalyst configuration: VLANs, VTP, STP, MSTP, RSTP, Trunk, Etherchannel, management, features, advanced configuration, Layer 3
   3. Tunneling
   
   
2. IP IGP Routing
   1. OSPF
   2. EIGRP
   3. RIPv2
   4. IPv6: Addressing, RIPng, OSPFv3
   5. GRE
   6. ODR
   7. Filtering, redistribution, summarization and other advanced features
   
   
3. BGP
   1. IBGP
   2. EBGP
   3. Filtering, redistribution, summarization, synchronization, attributes and other advanced features
   
   
4. IP and IOS Features
   1. IP addressing
   2. DHCP
   3. HSRP
   4. IP services
   5. IOS user interfaces
   6. System management
   7. NAT
   8. NTP
   9. SNMP
   10. RMON
   11. Accounting
   12. SLA
   
   
5. IP Multicast
   1. PIM-SM, bi-directional PIM
   2. MSDP
   3. Multicast tools, source specific multicast
   4. DVMRP
   5. Anycast
   
   
6. QoS
   1. Quality of service solutions
   2. Classification
   3. Congestion management, congestion avoidance
   4. Policing and shaping
   5. Signaling
   6. Link efficiency mechanisms
   7. Modular QoS command line
   
   
7. Security
   1. AAA
   2. Security server protocols
   3. Traffic filtering and firewalls
   4. Access lists
   5. Routing protocols security, catalyst security
   6. CBAC
   7. Other security features

I should get to know some basic knowledge about SI. Who can help me on that or show me some resources I can study from?

Another working day. Just heard that Obama is the president now and hope he can do as good as what he said. Allow I am not American, the ...

Tutorial: BGP Route Aggregation Part 1 - Using an Advertise-Map to control aggregation

BGP Route Aggregation is not only an important topic to learn for the CCIE exam, its what keeps the internet routing tables manageable. The basic idea is simple, instead of BGP advertising lots of different prefixes, we can summarize individual prefixes as an aggregate. In this series of articles we will be looking at BGP Route Aggregation using various methods that you should be familiar with before attempting the CCIE lab in case one of those evil proctors decides to limit the use of one or the other.

In this article we will be introducing the aggregate-address command to create route aggregates. We will be using the following topology for this tutorial:

Dynagen .net Configuration File:

ghostios = True
sparsemem = True
model = 3640

[localhost]

   [[3640]]
       image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
       # On Linux / Unix use forward slashes:
       # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
       ram = 128

       [[router R1]]
               model = 3640
               console = 2000
               e1/0 = LAN 12

       [[router R2]]
               model = 3640
               console = 2001
               e1/0 = LAN 12
               e1/1 = LAN 23
               e1/2 = LAN 24

       [[router R3]]
               model = 3640
               console = 2002
               e1/0 = LAN 23

       [[router R4]]
               model = 3640
               console = 2003
               e1/0 = LAN 24

You can download the pre-configured .net dynagen configuration file for this tutorial here.

Basic Configuration

Let’s take a look at the basic configuration for this topology:

R1

hostname R1
!
interface Loopback0
ip address 10.0.0.1 255.255.255.0
!
interface Loopback1
ip address 10.0.1.1 255.255.255.0
!
interface Ethernet1/0
ip address 192.168.12.1 255.255.255.0
full-duplex
no shut
!
router bgp 1
no synchronization
bgp router-id 1.1.1.1
network 10.0.0.0 mask 255.255.255.0
network 10.0.1.0 mask 255.255.255.0
neighbor 192.168.12.2 remote-as 2
no auto-summary

R2

hostname R2
!
interface Ethernet1/0
ip address 192.168.12.2 255.255.255.0
full-duplex
no shut
!
interface Ethernet1/1
ip address 192.168.23.2 255.255.255.0
full-duplex
no shut
!
interface Ethernet1/2
ip address 192.168.24.2 255.255.255.0
full-duplex
no shut
!
router bgp 2
no synchronization
bgp router-id 2.2.2.2
neighbor 192.168.12.1 remote-as 1
neighbor 192.168.23.3 remote-as 3
neighbor 192.168.24.4 remote-as 4
no auto-summary

R3

hostname R3
!
interface Loopback0
ip address 10.0.2.1 255.255.255.0
!
interface Loopback1
ip address 10.0.3.1 255.255.255.0
!
interface Ethernet1/0
ip address 192.168.23.3 255.255.255.0
full-duplex
no shut
!
router bgp 3
no synchronization
bgp router-id 3.3.3.3
network 10.0.2.0 mask 255.255.255.0
network 10.0.3.0 mask 255.255.255.0
neighbor 192.168.23.2 remote-as 2
no auto-summary

R4

hostname R4
!
interface Ethernet1/0
ip address 192.168.24.4 255.255.255.0
full-duplex
no shut
!
router bgp 4
no synchronization
bgp router-id 4.4.4.4
bgp log-neighbor-changes
neighbor 192.168.24.2 remote-as 2
no auto-summary

You can see in the configuration above we have three routers: R1, R2, R3 and R4 each in their own AS. R1 has two loopbacks defined which it is advertising into BGP. R3 also has two loopbacks defined which it is also advertising into BGP. Lets verify these advertised BGP prefixes:

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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

R2#sh ip bgp
BGP table version is 5, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

R3#sh ip bgp
BGP table version is 5, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R4#sh ip bgp
BGP table version is 5, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

You can see clearly above that the networks have been advertised into BGP. Let’s verify connectivity.

R1#ping 10.0.2.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/213/296 ms

Looks like we have connectivity from the networks that R1 is advertising (10.0.0.0/24 and 10.0.1.0/24) and the networks that R3 is advertising (10.0.2.0/24 and 10.0.3.0/24). We haven’t run an IGP here as we don’t usually have an IGP running between AS’s (thats the whole purpose of BGP!). When we did the ping, we have to source the address from R1’s loopback for connectivity. If we didn’t do that the source address of the ping packet would be 192.168.12.1, which R3 does not have a route for. We can run an IGP protocol here, but it is not needed for these examples.

Basic BGP Aggregation using the aggregate-address command

Lets do some aggregation! We will be using the aggregate-address command to create a summary.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 10.0.0.0 255.255.252.0

We have created an aggregrate address on R2 here that summarizes the 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 and 10.0.3.0/24 networks. If you look at the four networks in binary we get:

10.0.0.0/24 = 00001010.00000000.00000000.00000000
10.0.1.0/24 = 00001010.00000000.00000001.00000000
10.0.2.0/24 = 00001010.00000000.00000010.00000000
10.0.3.0/24 = 00001010.00000000.00000011.00000000

The first 22 bits of these are common, hence an aggregate of 10.0.0.0/22.

One of the first things we need to remember is that we cannot aggregate an address unless at least one of the more specific routes we are trying to aggregate exists in the routing table already. If all the prefixes that we are summarizing in our aggregate go down, the router will remove the aggregate from the BGP table.

Let’s verify the aggregate:

R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

R2#sh ip route | b Gateway
Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
    10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:10:57
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:10:57
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:10:57
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:10:57, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:10:57
C    192.168.23.0/24 is directly connected, Ethernet1/1

Looking at the routing table above we can see that we have an entry in the routing table to Null0 on R2.

Null0 - The road to nowhere

Why does an aggregate create an entry to Null0? Good question lets think about this. Say we had this scenario:

On R3 lets say we created 4 more loopbacks that we advertise into BGP: 150.0.0.0/24, 150.0.1.0/24, 150.0.2.0/24, 150.0.3.0/24.

R3

R3(config)#int lo10
R3(config-if)#ip add 150.0.0.1 255.255.255.0
R3(config-if)#int lo11
R3(config-if)#ip add 150.0.1.1 255.255.255.0
R3(config-if)#int lo12
R3(config-if)#ip add 150.0.2.1 255.255.255.0
R3(config-if)#int lo13
R3(config-if)#ip add 150.0.3.1 255.255.255.0
R3(config-if)#router bgp 3
R3(config-router)#network 150.0.0.0 mask 255.255.255.0
R3(config-router)#network 150.0.1.0 mask 255.255.255.0
R3(config-router)#network 150.0.2.0 mask 255.255.255.0
R3(config-router)#network 150.0.3.0 mask 255.255.255.0

R2

R2#sh ip bgp
BGP table version is 10, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i
*> 150.0.0.0/24     192.168.23.3             0             0 3 i
*> 150.0.1.0/24     192.168.23.3             0             0 3 i
*> 150.0.2.0/24     192.168.23.3             0             0 3 i
*> 150.0.3.0/24     192.168.23.3             0             0 3 i

R2 then aggregates this as 150.0.0.0/22 and creates a Null0 route in its routing table.

R2

R2(config)#router bgp 2
R2(config-router)#aggregate-address 150.0.0.0  255.255.252.0 

R2#sh ip route | b Gateway
Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
    10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:48:15
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:48:15
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:48:15
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:30:07, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:48:15
C    192.168.23.0/24 is directly connected, Ethernet1/1
    150.0.0.0/16 is variably subnetted, 5 subnets, 2 masks
B       150.0.2.0/24 [20/0] via 192.168.23.3, 00:12:54
B       150.0.3.0/24 [20/0] via 192.168.23.3, 00:12:54
B       150.0.0.0/24 [20/0] via 192.168.23.3, 00:13:24
B       150.0.0.0/22 [200/0] via 0.0.0.0, 00:12:01, Null0
B       150.0.1.0/24 [20/0] via 192.168.23.3, 00:01:31

This aggregate is then passed it on to R1. Lets also say that R2 has a default gateway set to R1.

R2

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.1

R2#sh ip route | b Gateway
Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
    10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:50:08
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:50:08
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:50:08
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:32:00, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:50:08
C    192.168.23.0/24 is directly connected, Ethernet1/1
    150.0.0.0/16 is variably subnetted, 5 subnets, 2 masks
B       150.0.2.0/24 [20/0] via 192.168.23.3, 00:14:46
B       150.0.3.0/24 [20/0] via 192.168.23.3, 00:14:46
B       150.0.0.0/24 [20/0] via 192.168.23.3, 00:15:17
B       150.0.0.0/22 [200/0] via 0.0.0.0, 00:13:53, Null0
B       150.0.1.0/24 [20/0] via 192.168.23.3, 00:03:24
S*   0.0.0.0/0 [1/0] via 192.168.12.1

What would happen if the network 150.0.1.0/24 went down on R3 and we didn’t have that Null0 route on R2?
R3

R3(config)#int lo11
R3(config-if)#shut

R2

R2#sh ip bgp
BGP table version is 14, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i
*> 150.0.0.0/24     192.168.23.3             0             0 3 i
*> 150.0.0.0/22     0.0.0.0                            32768 i
*> 150.0.2.0/24     192.168.23.3             0             0 3 i
*> 150.0.3.0/24     192.168.23.3             0             0 3 i

R2#sh ip route | b Gateway
Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
    10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:51:18
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:51:18
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:51:18
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:33:10, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:51:18
C    192.168.23.0/24 is directly connected, Ethernet1/1
    150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
B       150.0.2.0/24 [20/0] via 192.168.23.3, 00:15:57
B       150.0.3.0/24 [20/0] via 192.168.23.3, 00:15:57
B       150.0.0.0/24 [20/0] via 192.168.23.3, 00:16:27
S*   0.0.0.0/0 [1/0] via 192.168.12.1

Well R1 pings 150.0.1.1, the Aggregate will be matched on R1’s routing table. It will be received on R2. The route for 150.0.1.0/24 is missing. Remember there is no Null0 route here, so what will R2 match? The default gateway! So it will send it back to R1. R1 will then send to R2. Ladies and Gentleman we have a routing loop! This is one of the reasons we create a Null0 route on R2 when an aggregate is generated.

Let’s clean up and get back to our aggregate for 10.0.0.0/22 on R2 and take a look at the atomic-aggregate attribute.

R3

R3(config)#no int lo10
R3(config)#no int lo11

R3(config)#no int lo12
R3(config)#no int lo13
R3(config)#router bgp 3
R3(config-router)#no network 150.0.0.0 mask 255.255.255.0
R3(config-router)#no network 150.0.1.0 mask 255.255.255.0
R3(config-router)#no network 150.0.2.0 mask 255.255.255.0
R3(config-router)#no network 150.0.3.0 mask 255.255.255.0

R2

R2(config)#router bgp 2
R2(config-router)#no aggregate-address 150.0.0.0 255.255.252.0

Atomic-Aggregate

I gotta admit, Atomic-Aggregate sounds kinda cool. Like an Aggregate with superpowers or something :). But what the hell is it and what does it have to do with BGP aggregation? Take a look at the output below:

R2#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
 Advertised to update-groups:
    1
 Local, (aggregated by 2 2.2.2.2)
   0.0.0.0 from 0.0.0.0 (2.2.2.2)
     Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

You can see above that R2 has now originated an entry in BGP for the 10.0.0.0/22 aggregate. You can see also that the aggregate has the atomic-aggregate attribute set. What this means is that the AS path information about the aggregate has been lost. What do I mean by that?

Lets take a look at the BGP tables on R1.

R1#sh ip bgp
BGP table version is 18, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.0.0/22      192.168.12.2             0             0 2 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

Look at the output above we can see that the path information for the 10.0.0.0/22 prefix only contains AS 2!

R1#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
 Not advertised to any peer
 2, (aggregated by 2 2.2.2.2)
   192.168.12.2 from 192.168.12.2 (2.2.2.2)
     Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

You can see that R1 thinks the 10.0.0.0/22 network originated in AS 2. The networks in that aggregate however originated in AS 1, and AS 3. By aggregating on R2 we have lost that information. So all an atomic-aggregate attribute on an aggregate route says is “I’ve lost all the as-path information for the routes that I am aggregating”.

Lets look a bit closer at the BGP table on R2:

R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

You can see there that the 10.0.0.0/22 route has lost the as-path information. The atomic-aggregate attribute has been set so we don’t see the complete as-path for the prefixes contained within that aggregate.

This situation can also be seen on R3 and R4:

R3#sh ip bgp
BGP table version is 6, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.0.0/22      192.168.23.2             0             0 2 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R4#sh ip bgp
BGP table version is 6, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.0.0/22      192.168.24.2             0             0 2 i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

How can we retain the as-path information?

Using the as-set keyword

The as-path paramter for the aggregate-address command allows us to create an BGP aggregate without setting the atomic-aggregate attribute. This allows us to see the as-path of the routes we are aggregating.

Let’s take a look at the configuration:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 10.0.0.0 255.255.252.0 as-set

Simple configuration huh? Just add the as-set keyword to the aggregate-address command. Let’s verify this and take a look at the effects this has on our BGP tables.

R2#sh ip bgp 10.0.0.0 255.255.252.0
BGP routing table entry for 10.0.0.0/22, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
 Advertised to update-groups:
    1
 {1,3}, (aggregated by 2 2.2.2.2)
   0.0.0.0 from 0.0.0.0 (2.2.2.2)
     Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best

You can see above we have that the route is originated on R2 but it has a {1,3} in the as-path information. This means that 10.0.0.0/22 is an aggregate of prefixes that went through AS 1 and AS 3. Also notice, that the atomic-aggregate attribute is no longer set as no AS information for the aggregate has been lost.

What will this do to our BGP routing tables? Lets take a look at the routing table on R1:

R1#sh ip bgp
BGP table version is 7, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

Take a look carefully at the output above. Hey wait a minute, we don’t have the aggregate anymore. Did we stuff up our configuration? Is R2 even advertising the prefixes?

R2#sh ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 7, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 {1,3} i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

Total number of prefixes 5 

R2#sh ip bgp neighbors 192.168.23.3 advertised-routes
BGP table version is 7, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 {1,3} i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

Total number of prefixes 5 

R2 is advertising the prefixes but R1 and R3 are not accepting them! What gives? Actually, this is expected behaviour. What the rule with BGP when a router sees its own AS number in the AS-PATH? It doesn’t accept the route!

R2#sh ip bgp
BGP table version is 7, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 {1,3} i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

On R2, we can clearly see that the AS path of the aggregate now contains all the AS’s of the routes that it is summarizing.

R3#sh ip bgp
BGP table version is 7, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R3 doesn’t accept the route because it sees its own AS 3 in the path for 10.0.0.0/22.

R4#sh ip bgp
BGP table version is 7, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.0.0/22      192.168.24.2             0             0 2 {1,3} i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

R4 however accepts the route as it does not see its own AS in the aggregate. Cool huh?

Controlling the BGP aggregrate using advertise-map

Using the advertise-map option on the aggregate-address command allows us to control which routes make up the summary address. We can use this to say which prefixes make up the aggregate address.

Lets take a look at an example:
R2

router bgp 2
no synchronization
bgp router-id 2.2.2.2
 aggregate-address 10.0.0.0 255.255.252.0 as-set advertise-map AS_3_PREFIXES
neighbor 192.168.12.1 remote-as 1
neighbor 192.168.23.3 remote-as 3
neighbor 192.168.24.4 remote-as 4
no auto-summary
!
access-list 1 permit 10.0.2.0 0.0.0.255
access-list 1 permit 10.0.3.0 0.0.0.255
!
route-map AS_3_PREFIXES permit 10
match ip address 1

We have created an access list that matches the 10.0.2.0/24, and 10.0.3.0/24 prefixes. Both of these prefixes are originated in AS 3. This access list is then associated with the route-map AS_3_PREFIXES. We call this route-map in the aggregate-address advertise-map command.

Notice we also have the as-set command so the atomic-aggregate will be set.

Lets take a look at the summary address that this creates.

R2#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
    1
  3, (aggregated by 2 2.2.2.2)
   0.0.0.0 from 0.0.0.0 (2.2.2.2)
     Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

Notice that the AS-PATH information only has AS 3 in the path list. This is because when we created the aggregate address we told the router that “this aggregate is a summary of 10.0.2.0/24 and 10.0.3.0/24″. These prefixes only originate in AS 3 so thats all that goes in the path list! Also notice that the atomic-aggregate attribute is set. This is because information for the aggregate has been lost (ie. we don’t include AS 1’s prefixes).

R1#sh ip bgp
BGP table version is 8, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.0.0/22      192.168.12.2             0             0 2 3 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

You can see above that R1 now accepts this aggregate as it no longer sees its own AS in the path.

R2#sh ip bgp
BGP table version is 8, local router ID is 2.2.2.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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 3 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

R3#sh ip bgp
BGP table version is 7, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R3 does not accept the path. Why? Because it saw its own AS in the update.

R4#sh ip bgp
BGP table version is 17, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.0.0/22      192.168.24.2             0             0 2 3 i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

R4 happily accepts the update. Notice the AS path looks like it originated from AS 3.

Why might this stuff come in handy? Well imagine those evil CCIE proctors as you to filter BGP updates but you are not allowed to use the traditional means (filter-lists etc). This just gives you another tool that you can add to your belt!

In our next article we will be looking at suppress-maps and attribute-maps as well as few other cool little things with BGP aggregation. Stay tuned!

HTH. Now back to labs!

Summary:

• BGP can summaries prefixes with the aggregate-address command
• When an aggregate is created, a Null0 route is entered into the routing table to stop routing loops.
• By default, the aggregate will be originated from the AS creating the aggregate. All AS-PATH information about prefixes contained within the aggregate is lost.
• When AS-PATH information is lost, the atomic-aggregate attribute is set on the aggregate.
• We can control what prefixes make up the aggregate using the advertise-map parameter on the aggregate-address command.

On Windows, it is too slow. Linux version is much better. But linux version can't use manual mode on line connection.

Restart to using GNS3. The latest version is 0.6 now. But I forget why the C3640 IOS can't configure console port.

Start to use pidgin plugin for twitter.

I like pidgin :D

Looking for a timing track tool which is online or cross platform.

Start again to use it as my daily log