Dec 3, 2008

How to calculate fragment size or fragment delay (FRF.12 or MLPPP)?

Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps])

在QoS中我們可以利用LLQ(Low Latency Queueing)來提供VoIP封包低延遲(delay)及減少抖動(jitter)發生的情況。雖然VoIP封包總是傳送到software queue的前端,serialization delay(Layer 2 Frame encoded into Layer 1 Bits)的問題仍無可避免。一個大型封包可能正在hardware queue中使用FIFO。當VoIP封包被傳送至software queue的前端,在hardware transmit queue中的大型封包進行serialization時會導致VoIP封包必須等待一段較長的時間之後才能被傳送出去。


當你在某鏈結上要設置適合的fragment size(切割尺寸)時,比較常見的目標是使得最大serialization delay維持在10~15ms之間。

假設實體連接埠線路速度為512Kpbs,所需要的serialization delay不應該超過10ms(記住,fragment size是根據實體連接埠線路速度而計算出來的!),fragment size(切割尺寸)必須設定為:
512000(bps)/8*0.01(sec)=640 bytes

Router(config-if)# ppp multilink fragment 640
Router(config-map-class)# frame-relay fragment 640

如果在Cisco IOS CLI上如果今天要使用的是fragment delay數值(milliseconds),那就必須再乘上所使用的interface頻寬(假設MLPPP virtual-template上的頻寬為384Kbps)。

因此,我們使用virtual-template interface上的頻寬(384Kpbs)並且調整delay來確保fragment size 符合實體介面速度(512Kpbs)。在此例中,有效延遲數值應該被設定為:
640*8/384 = 13ms (Fragment_Size/CIR*8)

Router(config-if)# ppp multilink fragment delay 13
Router(config-map-class)# frame-relay fragment delay 13

IP RTP Priority

在還沒有發明LLQ(Low Latency Queue)之前,我們要在interface上調整Voice RTP的保留頻寬,只能使用

Router(config-if)# ip rtp priority starting-rtp-port-number port-number-range bandwidth


Router# show queue interface-type interface-number


Feature Overview
The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.

The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of User Datagram Protocol (UDP)/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first—that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.

The IP RTP Priority feature does not require that you know the port of a voice call. Rather, the feature gives you the ability to identify a range of ports whose traffic is put into the priority queue. Moreover, you can specify the entire voice port range—16384 to 32767—to ensure that all voice traffic is given strict priority service. IP RTP Priority is especially useful on slow-speed links whose speed is less than 1.544 Mbps.

This feature can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
  • When used in conjunction with WFQ, the ip rtp priority command provides strict priority to voice, and WFQ scheduling is applied to the remaining queues.
  • When used in conjunction with CBWFQ, the ip rtp priority command provides strict priority to voice. CBWFQ can be used to set up classes for other types of traffic (such as Systems Network Architecture [SNA]) that needs dedicated bandwidth and needs to be treated better than best effort and not as strict priority; the nonvoice traffic is serviced fairly based on the weights assigned to the enqueued packets. CBWFQ can also support flow-based WFQ within the default CBWFQ class if so configured.

Because voice packets are small in size and the interface also can have large packets going out, the Link Fragmentation and Interleaving (LFI) feature should also be configured on lower speed interfaces. When you enable LFI, the large data packets are broken up so that the small voice packets can be interleaved between the data fragments that make up a large data packet. LFI prevents a voice packet from needing to wait until a large packet is sent. Instead, the voice packet can be sent in a shorter amount of time.

How IP RTP Priority Works
If you want to understand its behavior and properly use the IP RTP Priority feature, it is important to consider its admission control and policing characteristics. When you use the ip rtp priority command to configure the priority queue for voice, you specify a strict bandwidth limitation. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP Priority feature with CBWFQ or WFQ.)

IP RTP Priority closely polices use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. In fact, IP RTP Priority polices the flow every second. IP RTP Priority prohibits transmission of additional packets once the allocated bandwidth is consumed. If it discovers that the configured amount of bandwidth is exceeded, IP RTP Priority drops packets, an event that is poorly tolerated by voice traffic. (Enable debugging to watch for this condition.) Close policing allows for fair treatment of other data packets enqueued in other CBWFQ or WFQ queues. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of codec used and interface characteristics. IP RTP Priority will not allow traffic beyond the allocated amount.

It is always safest to allocate to the priority queue slightly more than the known required amount of bandwidth. For example, suppose you allocated 24 kbps bandwidth, the standard amount required for voice transmission, to the priority queue. This allocation seems safe because transmission of voice packets occurs at a constant bit rate. However, because the network and the router or switch can use some of the bandwidth and introduce jitter and delay, allocating slightly more than the required amount of bandwidth (such as 25 kbps) ensures constancy and availability.

The IP RTP Priority admission control policy takes RTP header compression into account. Therefore, while configuring the bandwidth parameter of the ip rtp priority command you only need to configure for the bandwidth of the compressed call. For example, if a G.729 voice call requires 24 kbps uncompressed bandwidth (not including Layer 2 payload) but only 12 kbps compressed bandwidth, you only need to configure a bandwidth of 12 kbps. You need to allocate enough bandwidth for all calls if there will be more than one call.

The sum of all bandwidth allocation for voice and data flows on the interface cannot exceed 75 percent of the total available bandwidth. Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25 percent bandwidth for other overhead is conservative and safe. On a PPP link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount of configurable bandwidth for IP RTP Priority can be changed using the max-reserved-bandwidth command on the interface.

If you know how much bandwidth is required for additional overhead on a link, under aggressive circumstances in which you want to give voice traffic as much bandwidth as possible, you can override the 75 percent maximum allocation for the bandwidth sum allocated to all classes or flows by using the max-reserved-bandwidth command. If you want to override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead.

As another alternative, if the importance of voice traffic far exceeds that of data, you can allocate most of the 75 percent bandwidth used for flows and classes to the voice priority queue. Unused bandwidth at any given point will be made available to the other flows or classes.

CBWFQ Configuration
The following example first defines a CBWFQ configuration and then reserves a strict priority queue:

! The following commands define a class map:
router(config)# class-map class1
router(config-cmap)# match access-group 101
router(config-cmap)# exit

! The following commands create and attach a policy map:
router(config)# policy-map policy1
router(config-pmap)# class class1
router(config-pmap-c)# bandwidth 3000
router(config-pmap-c)# queue-limit 30
router(config-pmap-c)# random-detect
router(config-pmap-c)# random-detect precedence 0 32 256 100
router(config-pmap-c)# exit
router(config)# interface Serial1
router(config-if)# service-policy output policy1

! The following command reserves a strict priority queue:
router(config-if)# ip rtp priority 16384 16383 40

The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.

Virtual Template Configuration
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.

router(config)# multilink virtual-template 1
router(config)# interface virtual-template 1
router(config-if)# ip address
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 25
router(config-if)# service-policy output policy1
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
router(config-if)# max-reserved-bandwidth 80
router(config-if)# end
router(config)# interface Serial0/1
router(config-if)# bandwidth 64
router(config-if)# ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# ppp multilink
router(config-if)# end

Multilink Bundle Configuration
The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces.

The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.

router(config)# interface multilink 1
router(config-if)# ip address
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 200
router(config-if)# no ip mroute-cache
router(config-if)# fair-queue 64 256 0
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave
router(config-if)# max-reserved-bandwidth 80

The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:

router(config)# interface multilink 2
router(config-if)# ip address
router(config-if)# no ip directed-broadcast
router(config-if)# ip rtp priority 16384 16383 100
router(config-if)# no ip mroute-cache
router(config-if)# fair-queue 64 256 0
router(config-if)# ppp multilink
router(config-if)# ppp multilink fragment-delay 20
router(config-if)# ppp multilink interleave

In the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1.

router(config)# interface serial 2/0
router(config-if)# bandwidth 256
router(config-if)# no ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# no ip mroute-cache
router(config-if)# no fair-queue
router(config-if)# clockrate 256000
router(config-if)# ppp multilink
router(config-if)# multilink-group 1

Next, serial interface 2/1 is configured to be part of multilink bundle 2.

router(config)# interface serial 2/1
router(config-if)# bandwidth 128
router(config-if)# no ip address
router(config-if)# no ip directed-broadcast
router(config-if)# encapsulation ppp
router(config-if)# no ip mroute-cache
router(config-if)# no fair-queue
router(config-if)# clockrate 128000
router(config-if)# ppp multilink
router(config-if)# multilink-group 2

Dec 2, 2008

Cisco Introduces New CCIE Wireless Certification, CCIE Voice Lab Exam Enhancements


Cisco Introduces New CCIE Wireless Certification, CCIE Voice Lab Exam Enhancements

The demand for expert-level professionals proficient in the ability to design, install, deploy, and troubleshoot complex converged networks is growing exponentially. According to a commissioned study conducted by Forrester Consulting on behalf of Cisco.

  • 36 percent of the global companies surveyed reported that they have dedicated wireless specialists in their IT organizations, a number that will almost double in the next five years.
  • 69 percent of the companies surveyed expect to have a dedicated voice specialist in their organizations within five years up from 40 percent currently.

In an effort to meet this demand, Cisco has made two significant additions to its CCIE certification program:

Cisco CCIE Wireless Certification

The Cisco CCIE Wireless certification assesses and validates wireless expertise. Candidates who pass the CCIE Wireless certification exams demonstrate broad theoretical knowledge of wireless networking and a solid understanding of wireless local area networking (WLAN) technologies from Cisco, the market leader in WLAN technology.

Benefits of CCIE Certified Wireless Certification

  • Greater opportunity for salary increase and job advancement in wireless networking industry
  • Validates expertise in major aspects of WLAN technology
  • Provides next step for individuals interested in a career in managing or working with Cisco wireless technologies

The written exam for CCIE Wireless will be made available through Pearson VUE on February 17th, 2009. The lab exam for CCIE Wireless will be made available in April 2009. To find out more about the CCIE Wireless Certification and access the latest blueprints and study materials, visit the Cisco Learning Network.

CCIE Voice Lab Exam Enhancements

In addition to the release of the new Cisco CCIE Wireless certification, Cisco has refreshed the lab exam for its popular CCIE Voice certification. The refreshed CCIE Voice Lab Exam v3.0 addresses critical skills that voice professionals must have, including the ability to define integrated network services and mitigate future performance problems. Successful candidates demonstrate the skills to help companies increase productivity, and speed innovation.

To find out more about the exam for CCIE Voice certification and access to the latest blueprints and study materials, visit the Cisco Learning Network.

Subscribe to Cisco

Unsubscribe from Cisco

Privacy Statement

Subscribe to receive emails and newsletters from Cisco.
Or modify your profile, subscriptions, and preferences if you're already a Cisco customer.

To no longer receive these messages from Cisco. Please allow 7-10 business days for changes to take effect.

Read more about our privacy statement.

Please do not reply to this email for support. To view answers to commonly asked questions regarding the Cisco Certification Program or to request assistance related to this email, visit the Certification Online Support tool at

Copyright (C) 2008, Cisco Systems, Inc. All rights reserved. Cisco, the Cisco logo, and Cisco Systems are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
Cisco Systems, Inc. 170 West Tasman Drive, San Jose, California 95134 ATTN: Corporate Marketing (SJC08/3/4)

Nov 30, 2008

[轉載]Understanding 4-Byte Autonomous System Numbers

一般BGP網管大都知道BGP AS號碼範圍從0~65535,Public AS Range: 0~64511,Priavte AS Range: 64512~65535,所以很多人會誤解以為AS Number的位元只有16 bits。

事實上AS Number總共有32 bits(4 bytes),前面16 bits以往都是用0,所以會造成這樣的錯覺。根據Jeff Doyle blog上面提到的內容,在不久的將來所有新申請的AS Number format將會是0.XX。以下是完整4-bytes ASN的介紹請參考!

Understanding 4-Byte Autonomous System Numbers
By jdoyle on Fri, 11/28/2008 - 4:40pm.

For all the harping I do on this blog about IPv4 address depletion and the need to prepare yourselves for IPv6, there is another number resource that is also being quickly depleted, and that I haven’t written about before: the 2-byte autonomous system numbers (ASNs).

A 16-bit number space gives you 65,536 possible numbers (AS numbers 0 – 65535). Out of these, the IANA reserves 1,026 of them: 64512 – 65534 for private, reusable ASNs (similar to private RFC1918 IPv4 addresses) and a few others such as 0 and 65535 and one that is important to this article, 23456. Presently 49,150 ASNs have been allocated out of the public pool, so there are 15,360 available ASNs remaining: About 23.8 percent of the public pool.

An analysis of the allocation rate of 2-byte ASNs shows that the available pool will run out in mid-2011. Eerily close to the date that we will run out of IPv4 addresses.

Fortunately there is much less cause for concern about ASN depletion than about IPv4 depletion, for two reasons:

Unlike IP addresses, which are necessary for anyone that wants to connect to an IP network, autonomous system numbers matter only to networks that are running BGP.

Just as IPv6 was created to solve the IPv4 problem by offering an address size four times as large, 4-byte ASNs have been created to solve the 2-byte ASN depletion problem. But where transition to IPv6 can be complicated because of lack of interoperability between IPv4 and IPv6, the transition to 4-byte ASNs is far simpler.
This post describes the format of the 4-byte ASN, how it interoperates with 2-byte ASNs, and what you need to do (if anything) to prepare your network for them.

The 4-Byte ASN Format

4-byte ASNs provide 232 or 4,294,967,296 autonomous system numbers ranging from 0 to 4294967295. The first thing to notice about these numbers is that they include all of the older 2-byte ASNs, 0 through 65535. That greatly helps with interoperability between autonomous systems using 2-byte ASNs and those using 4-byte ASNs. (An oft-heard complaint about IPv6 is that interoperability with IPv4 could have been more easily supported if 4.3 billion IPv6 addresses had been reserved as representative of the existing IPv4 addresses, but that’s another story.)

A 4-byte ASN between 0 and 65535 is called a mappable ASN, because it can be represented in just 2 bytes; the first 16 bits are in every case all zeroes.

Stemming from a concern that 32-bit ASNs might be difficult to write and manage, there are three ways of representing 4-byte ASNs:

· asplain is a simple decimal representation of the ASN, from 0 to 4294967295.

· asdot+ breaks the number up into low-order and high-order 16-bit values, separated by a dot. All of the older 2-byte ASNs can be represented in the low-order value, with the high-order value set to 0. So for example, 65535 is 0.65535. One more than that, 65536, is outside the value that can be represented in the low-order range alone, and is therefore represented as 1.0. 65537 would be 1.1, 65680 is 1.144, and so on. You can figure the low- and high-order values by subtracting multiples of 65,536 from the asplain representation of the ASN, with the high-order value representing the multiples of 65536. The ASN 327700, then, is 5.20: Five times 65536 plus 20 more. The largest ASN, 4294967295, is 65535.65535: 65,535 times 65535, plus 65535 more.

· asdot is a mixture of asplain and asdot+. Any ASN in the 2-byte range of 0 – 65535 is written in asplain (so 65535 is written “65535”) and any ASN above that range is written in asdot+ (so 65536 is written “1.0”).

Asplain is obviously the most straightforward method of understanding the new ASNs, although the larger numbers might become unwieldy to write and therefore prone to typographical mistakes in written documentation or router configurations.

Asdot+ is much simpler to write, but harder to calculate from its simple decimal equivalent. If you work in this format regularly, it’s probably worth your time to write a simple script that does the conversions for you to prevent calculation errors.

Asdot might appear to have limited usefulness. After all, it’s not any harder to write “0.3657” than to write “3657”, and the need to do some calculations come in when you go above 65535; asdot does nothing to help you there. There is, however, a subtlety to this. The regional number assignment authorities – the Regional Internet Registries, or RIRs – differentiate a 16-bit number that is an older 2-byte ASN and a mappable 4-byte ASN (again, the set of 32-bit ASNs in which the first 16 bits are all 0). So “3657” is a 2-byte ASN, and “0.3657” is a 4-byte ASN.

This, of course, leads us to look briefly at just what the RIRs’ policies are for assigning 4-byte ASNs.

ASN Allocation Policies

All five of the RIRs (AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC) have the same assignment policies for 4-byte ASNs:

· 4-byte ASNs have been available since 1 January 2007. The default assignment, if you request an ASN, is to give you a 2-byte ASN and only assign a 4-byte ASN if you specifically request it.

· Beginning on 1 January 2009 (yes, about a month from now!) that policy reverses: A 4-byte ASN will be the default. You can still get a 2-byte ASN, but only if you specifically request it.

· A year later, on 1 January 2010, all ASN assignments will be 4-byte. The ASN you receive might be of the form 0.XX (where the high-order 16 bits are all 0 and the low-order 16 bits are not), but the RIRs will make no distinction between those numbers and any other 4-byte ASN. And although it won't effect your network in any way, the 16-bit ASN you've had maybe for years will, in the eyes of the RIRs, be a mapable 32-bit ASN. For instance, Level3 Communications' AS3356 becomes in the eyes of the RIRs, at the beginning of 2010, 0.3356.

These policies raise several questions:

· If you plan to request a new ASN assignment starting in 2009, what do you need to do to prepare for it?

· How do the new 4-byte ASNs interoperate with older autonomous systems using 2-byte ASNs?

· If you have an existing 2-byte ASN, does anything change?

The ASN’s Role in BGP

A brief review of how BGP uses autonomous system numbers will help in understanding how the new format might impact BGP networks. Most of you already know the basics of BGP; if you do, feel free to skip ahead.

The purpose of BGP, unlike any IGP (OSPF, IS-IS, EIGRP and RIP), is to route between domains under separate administrative control – that is, systems that are autonomous from each other. If you’re going to route between (and among) these autonomous routing domains, you need some way of identifying individual ASs. That identifier is the autonomous system number.

The ASN has two essential functions in BGP:

First, it helps BGP determine the shortest path to a destination. When BGP advertises a route to a neighbor in an Update message, it attaches several path attributes to the route. When a router learns more than one BGP route to the same destination, the BGP decision process evaluates the routes’ path attributes in a prioritized order to decide which of the routes is most preferable. (BGP path attributes can be added, removed, or changed in all sorts of ways to influence the BGP decision process. This is the basis for BGP routing policies.) One of these attributes, attached to every BGP route, is called AS_PATH. When a router advertises a destination within its own AS to a neighbor in another AS, it puts its local ASN in the AS_PATH. As the route is advertised to subsequent autonomous systems, each AS border router adds its own ASN to the attribute. The AS_PATH, then, becomes a list of ASNs that describes the path back to the destination. A router can choose a shortest path by choosing the route with the fewest ASNs listed in its AS_PATH.

The second ASN function is a very simple loop avoidance mechanism. Because a router adds its ASN to the AS_PATH before advertising a route to a neighbor in another AS, a route that loops – that is, exits an AS and is subsequently advertised back to the same AS – is easily detected by examining the AS_PATH. If a router sees its own ASN listed in the AS_PATH of a route advertised to it by a neighbor, it drops the route.

The ASN also appears in a path attribute called the AGGREGATOR. When a number of routes are summarized (aggregated), route details can be lost. The AGGREGATOR attribute can be added to an aggregate route to indicate the Router ID and ASN of the router performing the aggregation. This attribute does not influence the BGP decision process, but it can be useful for tracing back problems with aggregate routes.

A third attribute that uses the ASN is COMMUNITIES. This optional attribute helps you manage routing polices when they apply to a large number of routes; using a number of methods you can assign one or more COMMUNITIES attributes to prefixes, and then apply a routing policy to a community rather than individual routes. For example, you might define a COMMUNITES attribute named Cust_Routes and then add that attribute to all routes advertised into your AS by all your customers. Then anywhere in your network that you need to apply a policy to all of your customer routes, you can apply the policy to routes having the Customer_Routes attribute rather than having to identify each prefix (and possibly change all your prefix lists any time a customer route is added or removed).

The COMMUNITES attribute is a 32-bit value in which the first 16 bits are an ASN and the last 16 bits are arbitrarily assigned by you to have whatever meaning you want.

The important point here is not so much the functions of AGGREGATOR or COMMUNITES, however, but that they, like AS_PATH, are formatted to carry 2-byte ASNs; the formats of these attributes must therefore be adapted to carry the larger 32-bit ASNs.

In addition to these three path attributes the BGP Open message also references the ASN, in a 16-bit field called My Autonomous System. BGP runs on top of a TCP session between neighbors; after the TCP session is established, the neighbors use Open messages to negotiate the BGP session. Each neighbor indicates its Router ID, ASN, the BGP version it is running (always version 4 in modern networks), its hold time (the time it expects to wait for a Keepalive from the neighbor before closing the session) and possibly some optional parameters.

There is alot more to BGP than what has been described here. What is important for this discussion is that there are four BGP data entities that carry ASNs:

· The AS_PATH attribute;

· The AGGREGATOR attribute;

· The COMUNITES attribute; and

· The Open message

Consideration must be given to each of these entities not only in terms of adapting them to 4-byte ASNs but also making the adaptations interoperable with older BGP implementations that only understand 2-byte ASNs.

Neighbor Interoperability

For simplicity, we’ll call BGP implementations supporting 4-byte ASNs New_BGP, and legacy BGP implementations that only support 2-byte ASNs Old_BGP.

The first requirement for a New_BGP implementation is to discover whether a neighbor is New_BGP or Old_BGP. It does this by using the BGP Capability Advertisement when opening a BGP session. In addition to advertising itself as New_BGP, it includes its 4-byte ASN in the Capability advertisement.

If a neighbor responds that it also is a NEW_BGP speaker, the neighbor includes its 4-byte ASN in its own Capability advertisement. Thus two New_BGP neighbors can inform each other of their 4-byte ASNs without using the 2-byte My Autonomous System field in the Open message. (If the neighbors are NEW_BGP but have 2-byte ASNs or mappable 4-byte ASNs, they can still put the ASN in the My Autonomous System field in addition to the Capability advertisement.)

If a neighbor is Old-BGP, it either responds that it does not support the 4-byte ASN capability or does not respond to the Capability advertisement at all. In this case, the New_BGP neighbor can still bring up a session with the Old-BGP neighbor, but cannot advertise its 4-byte ASN. The neighbor wouldn’t understand it. Instead, New_BGP uses a reserved 2-byte ASN, 23456, called AS_TRANS (AS_TRANS is easily remembered because of its 2-3-4-5-6 sequence). This AS number is added to the My Autonomous System field of the Open message. Because AS_TRANS is reserved, no Old_BGP speaker can use it as its own ASN; only New_BGP speakers can use it.

Interoperable peering, then, is achieved because the New_BGP speaker “knows” its neighbor is an Old_BGP speaker and adapts to it; the Old-BGP speaker simply continues using legacy BGP rules.

Path Attribute Interoperability

Because the New_BGP speaker knows whether its neighbor is New_BGP or Old_BGP, it knows what rules to follow when advertising routes to the neighbor.

When advertising routes to a New_BGP neighbor, the AS_PATH attribute is simply modified to carry 4-byte ASNs. But when advertising routes to an Old-BGP neighbor, the AS_PATH must be kept in its legacy format, as a list of 2-byte ASNs; an Old_BGP neighbor would not otherwise know how to interpret the list. Rather than adding its own 4-byte ASN to the AS_PATH, the New_BGP speaker adds the AS_TRANS (again, AS23456) to the AS_PATH as a placeholder for its own and any other 4-byte ASNs appearing on the path. The router also adds a new attribute, AS4_PATH, to the route. This attribute carries the list of real ASNs, both 4-byte and 2-byte. Unlike AS_PATH, which is a mandatory attribute for all routes, AS4_PATH is optional transitive: “Optional” meaning it is only used when needed (and in fact a New_BGP speaker will not use this attribute if the AS_PATH is all 2-byte ASNs), and “transitive” meaning any BGP speaker passes the attribute along to other neighbors even if it doesn’t understand the attribute. Thus, the real autonomous system path can be passed transparently through one or more Old_BGP speakers.

When an Old_BGP speaker advertises a route with both AS_PATH and AS4_PATH attributes to a New_BGP speaker, the New_BGP speaker uses both attributes to reconstruct the path: AS4_PATH to find 4-byte ASNs on the path, and AS_PATH to find any 2-byte ASNs Old_BGP speakers will have added since the path last passed through a New_BGP speaker.

By adding AS_TRANS to the AS_PATH as a placeholder for any 4-byte ASNs along the route, the AS_PATH continues to accurately indicate the number of AS hops along the path, and therefore preserves its role in the BGP decision process. And although the AS_TRANS might wind up appearing multiple times in the AS_PATH, that ASN only has meaning to a New_BGP speaker – which will also use the AS4_PATH to reconstruct the path – so the loop avoidance function is also preserved: If a loop occurs, the New_BGP speaker using a 4-byte ASN will find its ASN in the AS4_PATH and drop the route.

The AGGREGATOR attribute, when it is needed, is modified similarly. A New_BGP speaker advertising a route to a New_BGP neighbor simply uses a modified version of the attribute that can carry a 4-byte ASN. If a New_BGP speaker advertises a route with the attribute to an Old_BGP speaker, and if the attribute contains a 4-byte ASN, the New_BGP speaker replaces the ASN with AS_TRANS and puts the real ASN in a new optional transitive attribute called AS4_AGREGATOR.

A New_BGP speaker receiving a route with AGGREGATOR and AS4_AGGREGATOR attributes from an Old_BGP neighbor replaces the AS_TRANS in the AGGREGATOR with the real 4-byte ASN in the AS4_AGGREGATOR.

BGP communities are supported in 4-byte ASN environments by using a new Extended Community attribute called the 4-Octet AS Specific BGP Extended Community (EXT_COMM). This Extended Community consists of a 4-byte ASN and a 2-byte arbitrary number; that is, the format is the same as the legacy COMMUNITIES attribute except the ASN part is 4 bytes instead of 2 bytes.

Preparing Your Network (Or Not)

All this interoperability that I’ve spent so many paragraphs describing to you means that New_BGP is backwards compatible with Old_BGP. This is good news if you currently run a network with a 2-byte ASN: You don’t need to do very much, at least in the near term, to get ready for 4-byte ASNs. Your AS will continue running just fine, even when New_BGP neighbors start peering with it.

If you will be acquiring a new ASN any time after the end of 2008 – and especially after the end of 2009 – there are a few things you will need to do to get your network ready for 4-byte ASNs.

First, of course, you need to insure that your router operating system supports New_BGP. Right now (the end of November 2008) the best information I can find is that the following OSs have New_BGP:

· Cisco Systems IOS-XR 3.4 and later (CRS only)

· Cisco Systems IOS-NX (“Nexus”)

· Cisco Systems IOS 12.2SRD for 7200 and 7600

· Cisco Systems IOS 12.5T for 1800/2800/3800, 7200, 7300

· Cisco Systems 12.2SB-Rel6 for 7200, 7300, 10000

· Cisco Systems 12.2SX for 6500

· Force 10 Networks FTOS and later

· Juniper Networks’ JUNOS 9.1 and later

· Juniper Networks’ JUNOSe 4.1.0 and later

· OpenBGPD 3.9 and later

· Quagga 0.99.6 and later

· Redback SEOS (all versions)

Finding specifics of feature support on most any vendor’s website is like a hunt for buried treasure but seldom with a reward at the end, so if you know of other operating systems supporting New_BGP – or have corrections to my list here – please do post a comment. If unsure about your own network, check with your vendor representative.

The biggest challenge with upgrading to New_BGP is that by far the largest installed base of router operating systems is Cisco IOS, and as you can see from the list above the current IOS support is all in early technology (T) or service provider (S) releases, and restricted to certain platforms. Hopefully New_BGP finds its way into mainstream IOS code in early 2009.

Other aspects of your network operations that should be assessed for support of the new ASNs are:

· Any address management applications that reference the ASN

· Any BGP analysis or traffic engineering applications

· Potential effects on MPLS-based VPNs that use Route Distinguishers

· Applications that use Internet Route Registries (IRRs) to set or publish policies

· Routing policies that reference ASNs such as AS path filters and community lists

Do Autonomous Systems with 2-Byte ASNs Need to Do Anything?

As I said, if you currently run a network with a 2-byte ASN your network will continue running with no problems. But there is one thing you should do in the short term to prepare: You will see more and more instances of AS_TRANS making their appearance in AS_PATHs, and if you are a service provider multiple customers might begin peering with you using AS_TRANS. You need to be sure that your operators and troubleshooters know what this special ASN is, and that multiple instances of it in a single AS_PATH or multiple customers peering to you using it are not indicative of a problem.

For the longer term, it is a good idea to put New_BGP capability on your list of requirements as you plan for router operating system upgrades. You can upgrade to New_BGP router by router without effecting your network. Once all of your routers support 4-byte ASNs, you should convert your 2-byte ASN to the 4-byte 0.XX format.

Taking these steps will save you some future headaches by eliminating potential confusions caused by AS_TRANS, giving you clearer visibility to newer peers and across AS paths, improving your routing policy capabilities, and preventing roadblocks when you need to exchange EXT_COMM attributes with New_BGP peers.

Like IPv6, 4-byte ASNs are the future of the Internet. Although all 2-byte ASNs allocated before 2010 will continue to exist, they will eventually be just a part of the new 32-bit format rather than a separate type of autonomous system number.

Everyone should give some thought now to what you need to do to be prepared for this.