Nov 16, 2007

Gatekeeper-Routed Call Signaling(GKRCS) vs Direct Endpoint Signaling

There are two types of gatekeeper call signaling methods:

Direct Endpoint Signaling
—This method directs call setup messages to the terminating gateway or endpoint.

Gatekeeper-Routed Call Signaling (GKRCS)
This method directs the call setup messages through the gatekeeper.

Note: Cisco IOS gatekeepers are Direct Endpoint signaling based and do not support GKRCS.

These diagrams illustrate the differences between these two methods:



Back-to-back user agent(B2BUA)

From Wikipedia, the free encyclopedia

The Back-to-Back User Agent (B2BUA) acts as a user agent to both ends of a Session Initiation Protocol (SIP) call. The B2BUA is responsible for handling all SIP signalling between both ends of the call, from call establishment to termination. Each call is tracked from beginning to end, allowing the operators of the B2BUA to offer value-added features to the call.

To SIP clients, the B2BUA acts as a User Agent server on one side and as a User Agent client on the other (back-to-back) side. The basic implementation of a B2BUA is defined in RFC 3261. The B2BUA may provide the following functionalities:

  • call management (billing, automatic call disconnection, call transfer, etc.)
  • network interworking (perhaps with protocol adaptation)
  • hiding of network internals (private addresses, network topology, etc.)
  • codec translation between two call legs

Because it maintains call state for all SIP calls it handles, failure of a B2BUA affects all these calls. Often, B2BUAs also terminate and bridge the media streams to have full control over the whole session.

A Signaling gateway, part of a Session Border Controller, or Asterisk PBX are good examples of a B2BUA.

Dejitter

The dejitter buffer size determines the ability of the emulated circuit to tolerate network jitter. The dejitter buffer in CEoIP software is configurable up to 500 milliseconds; the maximum amount of network jitter that CEoIP can tolerate is ±250 milliseconds.

dejitter-buffer size
Example:
Router(config-cem)# dejitter-buffer 80

(Optional) Specifies the size of the dejitter buffer used to compensate for the network filter.
Use the size argument to specify the size of the buffer in milliseconds. Default is 60.

Quality of Service Options on GRE Tunnel Interfaces

The qos pre-classify command

When packets are encapsulated by tunnel or encryption headers, QoS features are unable to examine the original packet headers and correctly classify the packets. Packets traveling across the same tunnel have the same tunnel headers, so the packets are treated identically if the physical interface is congested. With the introduction of the Quality of Service for Virtual Private Networks (VPNs) feature, packets can now be classified before tunneling and encryption occur.

In the following example, tunnel0 is the tunnel name. The qos pre-classify command enables the QoS for VPNs feature on tunnel0:

Router(config)# interface tunnel0
Router(config-if)# qos pre-classify

Characterizing Traffic for QoS Policies

When configuring a service policy, you first may need to characterize the traffic that is traversing the tunnel. Cisco IOS supports Netflow and IP Cisco Express Forwarding (CEF) accounting on logical interfaces like tunnels. See the NetFlow Services Solutions Guide for more information.

Where Do I Apply the Service Policy?

You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.

  • Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header.
  • Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header. In addition, apply the policy to the physical interface when you want to shape or police all traffic belonging to a tunnel, and the physical interface supports several tunnels.
  • Apply the policy to a physical interface and enable qos-preclassify when you want to classify packets based on the pre-tunnel header.

Cisco Security Device Manager(SDM) three categories

The Cisco SDM QoS wizard offers easy and effective optimization of LAN, WAN, and VPN bandwidth and application performance for different business needs (for example, voice and video, enterprise applications, and web). Three predefined categories are:

1. Real-time
2. Business-critical
3. Best-effort


In addition, the Cisco SDM QoS wizard supports NBAR, which provides real-time validation of application usage of WAN bandwidth against predefined service policies as well as QoS policing and traffic monitoring.

Nov 15, 2007

Police vs Shape

Policing can be applied to either the inbound or outbound direction, while shaping can be applied only in the outbound direction. Policing drops nonconforming traffic instead of queuing the traffic like shaping.

Policing also supports marking of traffic. Traffic policing is more efficient in terms of memory utilization than traffic shaping because no additional queuing of packets is needed.

Both traffic policing and shaping ensure that traffic does not exceed a bandwidth limit, but each mechanism has different impacts on the traffic:

1. Policing drops packets more often, generally causing more retransmissions of connection-oriented protocols, such as TCP.

2. Shaping adds variable delay to traffic, possibly causing jitter. Shaping queues excess traffic by holding packets in a shaping queue.

Traffic shaping is used to shape the outbound traffic flow when the outbound traffic rate is higher than a configured rate. Traffic shaping smoothes traffic by storing traffic above the configured rate in a shaping queue. Therefore, shaping increases buffer utilization on a router and causes unpredictable packet delays. Traffic shaping can also interact with a Frame Relay network, adapting to indications of Layer 2 congestion in the WAN. For example, if the backward explicit congestion notification (BECN) bit is received, the router can lower the rate limit to help reduce congestion in the Frame Relay network.

Processing vs Queuing vs Serialization vs Propagation vs End-to-End delay

1. Processing delay:
The time that it takes for a router (or Layer 3 switch) to take the packet from an input interface and put it into the output queue of the output interface. The processing delay depends on various factors:
  • CPU speed
  • CPU utilization
  • IP switching mode
  • Router architecture
  • Configured features on both the input and output interfaces

2. Queuing delay:
The time that a packet resides in the output queue of a router. Queuing delay depends on the number of packets already in the queue and their sizes. Queuing delay also depends on the bandwidth of the interface and the queuing mechanism.

3. Serialization delay:
The time that it takes to place a frame on the physical medium for
transport. This delay is typically inversely proportional to the link bandwidth.

4. Propagation delay:
The time that it takes for the packet to cross the link from one end to the other. This time usually depends on the type of media. (For example, satellite links produce the longest propagation delay because of the high altitudes of communications
satellites.)

5. End-to-end delay:
Equals the sum of all propagation, processing, serialization, and queuing delays in the path.

Convert Digital Signals to Analog Signals Steps

Step 1 Decompression:
If the voice signal was compressed by the sender, it is first decompressed.

Step 2 Decoding:
The received, binary formatted voice samples are decoded to the amplitude value of the samples. This information is used to rebuild a PAM signal of the original amplitude.

Step 3 Reconstruction of the analog signal:
The PAM signal is passed through a properly designed filter that reconstructs the original analog wave form from its digitally coded counterpart. The whole process is simply the reverse of the analog-to-digital conversion. Like analog-to-digital conversion, digital-to-analog conversion is performed by DSPs, which are located on the voice interface cards. The conversion is needed for calls being received from a packet network or digital interfaces, which are then transmitted out an analog voice interface.

FXS vs FXO vs E&M

Gateways use different types of interfaces to connect to analog devices, such as phones,
fax machines, or PBX or public switched telephone network (PSTN) switches. Analog
interfaces used at the gateways include these three types:

FXS:
The FXS interface connects to analog end systems, such as analog phones or
analog faxes, which on their side use the FXO interface. The router FXS interface
behaves like a PSTN or a PBX, serving phones, answering machines, or fax machines
with line power, ring voltage, and dial tones. If a PBX uses an FXO interface, it can also
connect to a router FXS interface. In this case, the PBX acts like a phone.

FXO:
The FXO interface connects to analog systems, such as a PSTN or a PBX, which
on their side use the FXS interface. The router FXO interface behaves like a phone,
getting line power, ring voltage, and dial tones from the other side. As mentioned, a PBX
can also use an FXO interface toward the router (which will then use an FXS interface),
if the PBX takes the role of the phone.

E&M:
The E&M interface provides signaling for analog trunks. Analog trunks
interconnect two PBX-style devices, such as any combination of a gateway (acting as a
PBX), a PBX, and a PSTN switch. E&M is often defined to as "ear and mouth," but it
derives from the term "earth and magneto." "Earth" represents the electrical ground, and
"magneto" represents the electromagnet used to generate tones.

Convert Analog Signals to Digital Signals Steps

Step 1 Sampling:
The analog signal is sampled periodically. The output of the sampling is a pulse amplitude modulation (PAM) signal.

Step 2 Quantization:
The PAM signal is matched to a segmented scale. This scale measures the amplitude (height) of the PAM signal.

Step 3 Encoding:
The matched scale value is represented in binary format.

Step 4 Compression:
Optionally, voice samples can be compressed to reduce bandwidth requirements. Analog-to-digital conversion is done by digital signal processors (DSPs), which are located on the voice interface cards. The conversion is needed for calls received on analog lines, which are then sent out to a packet network or to a digital voice interface.

Service-Provider CCIE Written 補充資料整理完結

經過了兩三個月的時間,我儘了最大的努力找出所有SP CCIE Written可能相關"主題"的文章摘要,並且用紅色字體標註"重點",希望對各位了解題意有幫助,順便可以知道原來的文章出處及更詳盡的內容意義。

今天已經完成了第一階段的SP CCIE Written考試,接下來就是要準備第二階段SP CCIE Lab的部份了,我會邊作Lab邊將個人心得紀錄在這個blog中,希望我的經歷可以讓各位更輕鬆地準備SP CCIE!

祝各位CCIE Candiates好運! 一起克服大魔王!

Why Are Some OSPF Routes in the Database but Not in the Routing Table?

Introduction
A common problem when using Open Shortest Path First (OSPF) is routes in the database don't appear in the routing table. In most cases OSPF finds a discrepancy in the database so it doesn't install the route in the routing table. Often, you can see the Adv Router is not-reachable message (which means that the router advertising the LSA is not reachable through OSPF) on top of the link-state advertisement (LSA) in the database when this problem occurs. Here is an example:

Adv Router is not-reachable
LS age: 418
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.32.2
Advertising Router: 172.16.32.2
LS Seq Number: 80000002
Checksum: 0xFA63
Length: 60

Number of Links: 3

There are several reasons for this problem, most of which deal with mis-configuration or a broken topology. When the configuration is corrected the OSPF database discrepancy goes away and the routes appear in the routing table. This document explains some of the more common reasons that can cause the discrepancy in the database.

Some of the commands used throughout this document for verification of OSPF behavior include the show ip ospf interface, ip ospf database router, show ip ospf neighbor and the show ip ospf database external . If you have the output of any of these commands from your Cisco device, you can use Output Interpreter to display potential issues and fixes. To use Output Interpreter , you must be a registered customer, be logged in, and have JavaScript enabled.

Reason 1: Network Type Mismatch
Let's use the following network diagram as an example:



R4-4K
interface Loopback0
ip address 172.16.33.1 255.255.255.255

interface Serial2
ip address 172.16.32.1 255.255.255.0
ip ospf network broadcast

router ospf 20
network 172.16.0.0 0.0.255.255 area 0

R1-7010
interface Loopback0
ip address 172.16.30.1 255.255.255.255
!
interface Serial1/0
ip address 172.16.32.2 255.255.255.0
clockrate 64000

router ospf 20
network 172.16.0.0 0.0.255.255 area 0

R4-4K(4)# show ip ospf interface serial 2
Serial2 is up, line protocol is up
Internet Address 172.16.32.1/24, Area 0
Process ID 20, Router ID 172.16.33.1, Network Type BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 172.16.33.1, Interface address 172.16.32.1
Backup Designated router (ID) 172.16.32.2, Interface address 172.16.32.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:08
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.32.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)

R1-7010(5)# show ip ospf interface serial 1/0
Serial1/0 is up, line protocol is up
Internet Address 172.16.32.2/24, Area 0
Process ID 20, Router ID 172.16.32.2, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.33.1
Suppress hello for 0 neighbor(s)
As you can see above, Router R4-4K is configured for broadcast, and Router R1-7010 is configured for point-to-point. This kind of network type mismatch makes the advertising router unreachable.

R4-4K(4)# show ip ospf database router 172.16.32.2

Adv Router is not-reachable
LS age: 418
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.32.2
Advertising Router: 172.16.32.2
LS Seq Number: 80000002
Checksum: 0xFA63
Length: 60
Number of Links: 3

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 172.16.33.1
(Link Data) Router Interface address: 172.16.32.2
Number of TOS metrics: 0
TOS 0 Metrics: 64

Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.32.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 64

R1-7010(5)# show ip ospf database router 172.16.33.1

Adv Router is not-reachable
LS age: 357
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.33.1
Advertising Router: 172.16.33.1
LS Seq Number: 8000000A
Checksum: 0xD4AA
Length: 48
Number of Links: 2

Link connected to: a Transit Network
(Link ID) Designated Router address: 172.16.32.1
(Link Data) Router Interface address: 172.16.32.1
Number of TOS metrics: 0
TOS 0 Metrics: 64


You can see that for subnet 172.16.32.0/24, Router R1-7010 is generating a point-to-point link and Router R4-4K is generating a transit link. This creates a discrepancy in the link-state database, which means no routes are installed in the routing table.

R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
C 172.16.30.1/32 is directly connected, Loopback0


Solution
To solve this problem, configure both routers for the same network type. You can either change the network type of Router R1-7010 to broadcast, or change Router R4-4K's serial interface to point-to-point.

Note: If you have a situation where one side is a multipoint interface and the other side is a sub-interface then change the network type to broadcast on both sides.

In this example we have removed the "network-type broadcast" statement on R4-4K because both sides are point-to-point High-Level Data Link Control (HDLC) encapsulated interfaces.

R4-4K(4)# configure terminal
R4-4K(4)(config)# interface serial 2
R4-4K(4)(config-if)# no ip ospf network broadcast
R4-4K(4)(config-if)# end

R4-4K(4)# show ip ospf interface serial 2
Serial2 is up, line protocol is up
Internet Address 172.16.32.1/24, Area 0
Process ID 20, Router ID 172.16.33.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.32.2
Suppress hello for 0 neighbor(s)


Reason 2: Wrong Address Assignment in DUAL Serial Link Setup
Consider this network diagram as an example:



R4-4K
interface loopback 0
ip address 172.16.35.1 255.255.255.255

interface Serial2
ip address 172.16.29.1 255.255.255.0
!
interface Serial3
ip address 172.16.32.1 255.255.255.0

router ospf 20
network 172.16.0.0 0.0.255.255 area 0

R1-7010
interface loopback 0
ip address 172.16.30.1 255.255.255.255

interface Serial1/0
ip address 172.16.32.2 255.255.255.0
clockrate 64000
!
interface Serial1/1
ip address 172.16.29.2 255.255.255.0
clockrate 38400

router ospf 20
network 172.16.0.0 0.0.255.255 area 0


You can see that the IP addresses are flipped in the above configurations, which causes a discrepancy in the OSPF database. However, the routers still form neighbors in Cisco IOS version earlier than 12.1 because on a point-to-point link, OSPF routers don't verify that the neighboring router is on the same subnet.

R4-4K(4)# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.16.32.2 1 FULL/ - 00:00:37 172.16.32.2 Serial2
172.16.32.2 1 FULL/ - 00:00:31 172.16.29.2 Serial3


From the above output, you can see that Serial2 is forming neighbors with IP address 172.16.32.2, which isn't in the same subnet. Although neighbors are formed, no routes are installed in the routing table:

R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
C 172.16.29.0/24 is directly connected, Serial1/1
C 172.16.30.1/32 is directly connected, Loopback0


Solution
To solve this problem, either correctly assign the IP addresses or switch the serial cables. Here we have corrected the IP addresses:

R4-4K
interface loopback 0
ip address 172.16.35.1 255.255.255.255

interface Serial2
ip address 172.16.32.1 255.255.255.0
!
interface Serial3
ip address 172.16.29.1 255.255.255.0

router ospf 20
network 172.16.0.0 0.0.255.255 area 0

R1-7010
interface loopback 0
ip address 172.16.30.1 255.255.255.255

interface Serial1/0
ip address 172.16.32.2 255.255.255.0
clockrate 64000
!
interface Serial1/1
ip address 172.16.29.2 255.255.255.0
clockrate 38400

router ospf 20
network 172.16.0.0 0.0.255.255 area 0


R4-4K(4)# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.16.32.2 1 FULL/ - 00:00:36 172.16.32.2 Serial2
172.16.32.2 1 FULL/ - 00:00:39 172.16.29.2 Serial3


Now it shows the correct neighbor address on the Serial 2 interface. The routes are also in the routing table:

R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
O 172.16.35.1/32 [110/65] via 172.16.32.1, 00:03:12, Serial1/0
[110/65] via 172.16.29.1, 00:03:12, Serial1/1
C 172.16.29.0/24 is directly connected, Serial1/1
C 172.16.30.1/32 is directly connected, Loopback0

Reason 3: One Side of Point-to-Point Link Included in Wrong Majornet or Subnet
Consider this network diagram as an example:



This situation creates exactly the same behavior as the Wrong Address Assignment in DUAL Serial Link Setup. To solve the problem, assign IP addresses in the same subnet on both routers.

Reason 4: One Side Is Unnumbered and the Other Side Is Numbered
Consider the following network diagram as an example:



R4-4K
interface Loopback0
ip address 172.16.35.1 255.255.255.255

interface Serial2
ip unnumbered Loopback0
router ospf 20
network 172.16.0.0 0.0.255.255 area 0


R1-7010
interface Loopback0
ip address 172.16.30.1 255.255.255.255
!
interface Serial1/0
ip address 172.16.32.2 255.255.255.0
clockrate 64000

router ospf 20
network 172.16.0.0 0.0.255.255 area 0

R4-4K(4)# show interface serial 2
Serial2 is up, line protocol is up
Hardware is cxBus Serial
Interface is unnumbered. Using address of Loopback0 (172.16.35.1)

R1-7010(5)# show interface serial 1/0
Serial1/0 is up, line protocol is up
Hardware is cxBus Serial
Internet address is 172.16.32.2/24


The output above shows that R4-4K's Serial 2 interface is unnumbered to Loopback0, whereas R1-7010's Serial 1/0 is a numbered interface.

R4-4K(4)# show ip ospf interface serial 2
Serial2 is up, line protocol is up
Internet Address 0.0.0.0/24, Area 0
Process ID 20, Router ID 172.16.35.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.32.2
Suppress hello for 0 neighbor(s)


R1-7010(5)# show ip ospf interface serial 1/0
Serial1/0 is up, line protocol is up
Internet Address 172.16.32.2/24, Area 0
Process ID 20, Router ID 172.16.32.2, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.33.1

Suppress hello for 0 neighbor(s)

As you can see above, the network-type in both cases is point-to-point. The problem is that one side is unnumbered and the other side isn't, which creates a discrepancy in the database as shown below.

R4-4K(4)# show ip ospf database router 172.16.30.1

OSPF Router with ID (172.16.35.1) (Process ID 20)
Router Link States (Area 0)
LS age: 202
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.30.1
Advertising Router: 172.16.30.1
LS Seq Number: 80000002
Checksum: 0xC899
Length: 60
Number of Links: 3
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 172.16.35.1
(Link Data) Router Interface address: 172.16.32.2
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.32.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.30.1
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

R4-4k(4)#

R1-7010(5)# show ip ospf database router 172.16.35.1

OSPF Router with ID (172.16.30.1) (Process ID 20)
Router Link States (Area 0)
Adv Router is not-reachable
LS age: 396
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.35.1
Advertising Router: 172.16.35.1
LS Seq Number: 80000003
Checksum: 0xBEA1
Length: 48
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 172.16.30.1
(Link Data) Router Interface address: 0.0.0.3


!--- In case of an unnumbered link we use MIB
!--- II IfIndex value which usually starts with 0.


Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.35.1
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

R1-7010(5)#

You can see that R1-7010 is generating an LSA for this point-to-point link with the Link Data field containing its interface address, while R4-4K is generating the LSA for the same link with the Link Data field containing the MIBII IfIndex value. This creates a discrepancy in the link-state database, which means no routes are installed in the routing table.

R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
C 172.16.30.1/32 is directly connected, Loopback0


Solution
To solve this problem, configure both routers' serial interfaces as either numbered or unnumbered. In this example we have numbered the serial 2 interface of router R4-4K.

R4-4K(4)# configure terminal
R4-4K(4)(config)# interface serial 2
R4-4K(4)(config-if)# no ip unnumbered loopback 0
R4-4K(4)(config-if)# ip address 172.16.32.1 255.255.255.0

R4-4K(4))# show ip ospf interface serial 2
Serial2 is up, line protocol is up
Internet Address 172.16.32.1/24, Area 0
Process ID 20, Router ID 172.16.33.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.32.2
Suppress hello for 0 neighbor(s)

R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
O 172.16.33.1/32 [110/65] via 172.16.32.1, 00:03:08, Serial1/0
C 172.16.30.1/32 is directly connected, Loopback0

Reason 5: Broken PVC in Fully Meshed Frame Relay Environment
Consider this network diagram as an example:



R9-2500
interface Loopback0
ip address 50.50.50.50 255.255.255.255
!
interface Serial0
ip address 10.10.10.5 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
frame-relay map ip 10.10.10.6 102 broadcast
frame-relay map ip 10.10.10.7 101 broadcast

router ospf 10
network 10.10.10.0 0.0.0.255 area 0
network 50.50.50.0 0.0.0.255 area 0

R4-4K
interface Loopback0
ip address 70.70.70.70 255.255.255.255
!
interface Serial0
ip address 10.10.10.7 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
frame-relay map ip 10.10.10.5 101 broadcast
frame-relay map ip 10.10.10.6 100 broadcast

router ospf 10
network 10.10.10.0 0.0.0.255 area 0
network 70.70.70.0 0.0.0.255 area 0

R3-4K
interface Loopback0
ip address 60.60.60.60 255.255.255.255
!
interface Serial0
no ip address
encapsulation frame-relay
!
interface Serial0.1 multipoint
ip address 10.10.10.6 255.255.255.0
ip ospf network broadcast
frame-relay map ip 10.10.10.5 102 broadcast
frame-relay map ip 10.10.10.7 100 broadcast
!
router ospf 10
network 10.10.10.0 0.0.0.255 area 0
network 60.60.60.0 0.0.0.255 area 0


The broadcast model over Frame Relay works properly as long as the Frame Relay cloud is fully meshed. If any permanent virtual circuits (PVCs) are broken, it can create problems in the OSPF database, which in turn produces the Adv router not reachable message.

In this example, the PVC between R9-2500 and R4-4K is broken, and R9-2500 link to the designated router (DR) is broken. As a result, R9-2500 declares all LSAs from R3-4K (which is not a DR), as unreachable. As you can see, R9-2500 isn't generating a transit link for the serial interface attached to R3-4K; it is generating a stub link instead because as far as R9-2500 is concerned there is no DR on this link.

R9-2500(3)# show ip ospf database router

OSPF Router with ID (50.50.50.50) (Process ID 10)
Router Link States (Area 0)
LS age: 148
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 50.50.50.50
Advertising Router: 50.50.50.50
LS Seq Number: 8000000B
Checksum: 0x55A
Length: 48
Number of Links: 2

Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.10.10.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 64

Link connected to: a Stub Network
(Link ID) Network/subnet number: 50.50.50.50
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

Adv Router is not-reachable
LS age: 1081
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 60.60.60.60
Advertising Router: 60.60.60.60
LS Seq Number: 80000006
Checksum: 0x4F72
Length: 48
Number of Links: 2

Link connected to: a Stub Network
(Link ID) Network/subnet number: 60.60.60.60
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.10.7
(Link Data) Router Interface address: 10.10.10.6
Number of TOS metrics: 0
TOS 0 Metrics: 64


Adv Router is not-reachable
LS age: 306
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 70.70.70.70
Advertising Router: 70.70.70.70
LS Seq Number: 80000007
Checksum: 0xC185
Length: 48
Number of Links: 2

Link connected to: a Stub Network
(Link ID) Network/subnet number: 70.70.70.70
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.10.7
(Link Data) Router Interface address: 10.10.10.7
Number of TOS metrics: 0
TOS 0 Metrics: 64


Refer to Problems with Running OSPF in NBMA Mode over Frame Relay for more detailed information about this problem.

Reason 6: Forwarding Address Known via an External Route
Consider this network diagram as an example:



R2507
interface Serial0
ip address 1.1.1.1 255.255.255.0

interface Serial1
ip address 7.7.7.1 255.255.255.0

router ospf 1
network 1.1.1.1 0.0.0.0 area 0
default- information originate metric 20

ip route 0.0.0.0 0.0.0.0 Serial1


R2504
interface Serial0
ip address 1.1.1.2 255.255.255.0

interface TokenRing0
ip address 3.3.4.2 255.255.255.0

router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 3.0.0.0 0.255.255.255 area 1
area 1 range 3.0.0.0 255.0.0.0


R2515
interface Serial1
ip address 4.4.4.3 255.255.255.0

interface TokenRing0
ip address 3.3.4.3 255.255.255.0

interface ethernet 0
ip address 3.44.66.3 255.255.255.0

interface ethernet 1
ip address 3.22.88.3 255.255.255.0

router ospf 1
redistribute rip metric 20 subnets
network 0.0.0.0 255.255.255.255 area 1

router rip
network 3.0.0.0


R2513
interface TokenRing0
ip address 3.3.4.4 255.255.255.0

interface ethernet 0
ip address 200.1.1.4 255.255.255.0

router rip
network 3.0.0.0
network 200.1.1.0

R2507# show ip ospf data external 200.1.1.0
OSPF Router with ID (7.7.7.1) (Process ID 1)
Type- 5 AS External Link States
LS age: 72
Options: (No TOS- capability, DC)
LS Type: AS External Link
Link State ID: 200.1.1.0 (External Network Number )
Advertising Router: 3.44.66.3
LS Seq Number: 80000001
Checksum: 0xF161
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 3.3.4.4
External Route Tag: 0


R2507 has 200.1.1.0/24 in its database but it hasn't installed it in the routing table because 3.3.4.4 is learned via an OSPF external route.

R2507# show ip route 3.3.4.4
Routing entry for 3.3.4.0/ 24
Known via "ospf 1", distance 110, metric 20,type extern 2, forward metric 70
Redistributing via ospf 1
Last update from 1.1.1.2 on Serial0, 00: 00: 40 ago
Routing Descriptor Blocks:
* 1.1.1.2, from 3.44.66.3, 00: 00: 40 ago, via Serial0
Route metric is 20, traffic share count is 1


Note: With the fix of Cisco bug ID CSCdp72526 ( registered customers only) , OSPF does not generate a type-5 link-state advertisement (LSA) of an overlapped external network; therefore, R2507 will only have a summary intra-area route of 3.0.0.0/8. Then, R2507 will install 200.1.1.0/24 as the forwarding address and it will be reachable via intra-area route 3.0.0.0/8, thus in compliance with RFC 2328 .

After the fix of above mentioned bug, output will look like the following:

R2507# show ip route 3.3.4.4
Routing entry for 3.0.0.0/8
Known via "ospf 1", distance 110, metric 74, type inter area
Last update from 1.1.1.2 on Serial0, 00:19:20 ago
Routing Descriptor Blocks:
* 1.1.1.2, from 3.3.4.2, 00:19:20 ago, via Serial0

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

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial0
O IA 3.0.0.0/8 [110/74] via 1.1.1.2, 00:30:18, Serial0
O E2 200.1.1.0/24 [110/20] via 1.1.1.2, 00:22:58, Serial0
Route metric is 74, traffic share count is 1

R2507#

If the forwarding address is also known via an external route, OSPF doesn't install that route in the routing table. For more detailed information about this problem, see Common Routing Problem with OSPF Forwarding Address.

Reason 7: Distribute List Is Blocking the Routes
Let's use the following network diagram as an example:



R4-4K
interface Loopback0
ip address 172.16.33.1 255.255.255.255

interface Serial2
ip address 172.16.32.1 255.255.255.0

router ospf 20
network 172.16.0.0 0.0.255.255 area 0

R1-7010
interface Loopback0
ip address 172.16.30.1 255.255.255.255
!
interface Serial1/0
ip address 172.16.32.2 255.255.255.0
clockrate 64000

router ospf 20
network 172.16.0.0 0.0.255.255 area 0
distribute-list 1 in
!
access-list 1 permit 172.16.32.0. 0.0.0.255

As you can see above, R1-7010 has the distribute-list command configured and it's only allowing the 172.16.32.0/24 address range to be installed in the routing table. In link-state protocols you can not really filter an LSA with the distribute-list command. The LSA will still be in the database; however the LSA will not be installed in the routing table.

R1-7010(5)# show ip ospf database router 172.16.33.1

LS age: 357
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.33.1
Advertising Router: 172.16.33.1
LS Seq Number: 8000000A
Checksum: 0xD4AA
Length: 48
Number of Links: 3

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 172.16.32.2
(Link Data) Router Interface address: 172.16.32.1
Number of TOS metrics: 0
TOS 0 Metrics: 64


The distribute-list configuration command on R1-7010 is filtering the 172.16.33.1/32 network from being installed in the routing table.

R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
C 172.16.30.1/32 is directly connected, Loopback0


Solution
To solve this problem, configure R1-7010 and allow 172.16.33.0/24 in the access control list (ACL) so this network gets installed in the routing table.

R1-7010(5)# configure terminal
R1-7010(5)(config)# access-list 1 permit 172.16.33.0 0.0.0.255
R1-7010(5)(config)# end

R1-7010(5)# show ip access-list 1
Standard IP access list 1
permit 172.16.32.0, wildcard bits 0.0.0.255
permit 172.16.33.0, wildcard bits 0.0.0.255


R1-7010(5)# show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.32.0/24 is directly connected, Serial1/0
O 172.16.33.1/32 [110/65] via 172.16.32.1, 00:00:08, Serial1/0
C 172.16.30.1/32 is directly connected, Loopback0

Nov 14, 2007

專家輕鬆駭入XP 微軟高層震攝

CNET新聞專區:Tom Espiner

2007/11/14 13:43

兩位英國電子犯罪專家僅利用幾分鐘的時間就駭入一台未受保護的Windows XP主機,並連結一個不安全的無線網路,讓親眼目睹的微軟公司高層大感「震攝」。

由英國政府和產業界贊助的網路安全活動Get Safe Online,12日邀請了兩位任職於英國重大組織犯罪局(Serious Organized Crime Agency)的專家,示範如何將一台使用Windows XP及Service Pack 1的電腦,連上一個不安全的無線網路。這台主機沒有任何防毒軟體、防火牆或反間諜軟體機制,並有一個內含密碼的檔案,作為示範偷竊的目標。

這兩位SOCA官員希望保持匿名。其中一位自稱"Mick",在示範駭入同事"Andy"未受保護的電腦時,一直待在一面屏幕後。他說:「要連上不安全的無線網路很容易。好比Andy一直在他的臥室裡,而我則在屋外的車內掃瞄網路,如果我訂購或瀏覽了非法的東西,倒楣的人會是Andy。」

Mick用一種他從網路下載的普通、開放原始碼的弱點搜尋工具。SOCA要求記者不要透露該工具的名稱。Mick說:「你可以從網路上下載攻擊工具,而這個甚至連小孩都會用。」

Mick用XP Wireless Network Connection Status(無線網路連線狀態)對話窗找到他自己電腦的IP位址,再用數字推演法,將前後一定範圍的IP位址輸入攻擊工具,尋找其中是否有未受保護的主機。

使用一種不同的攻擊工具,他製作出一份詳細列出該系統弱點的安全報告。Mick決定利用其中一項弱點。他再度用攻擊工具在MS-DOS植入一小段惡意程式,只要一、兩分鐘就能突破那個瑕疵。

連上不安全的無線網路後,刺探網路上其他電腦可能的IP位址,他找到了Andy未受保護的電腦。接著,他掃瞄開放的入口,用攻擊工具建立刺探程式,再以惡意軟體駭入XP系統的command shell,此時只花了6分鐘。

SOCA電子犯罪組副主任Sharon Lemon表示:「如果你是坐在(一家有Wi-Fi網路的咖啡廳裡),你的咖啡甚至還沒變涼呢。」

Mick接著前往「我的文件」資料夾,利用一組極普通的傳輸協定,就把內含密碼的文件轉到他自己的電腦裡。加上這一道程序,整個過程也不過11分鐘。

SOCA的代表說,這場示範「純粹是為了凸顯,如果系統沒有受到保護,要駭入是相對簡單的是。」SOCA並未因此建議中小企業儘快升級Vista,但表示安裝執行Service Pack 2 to XP和所有的修補程式,並使用安全的無線網路,是「合理的作法」。

微軟英國分公司的平台策略首長Nick McGrath目睹了整個示範過程。他說:「在剛才的示範中,看到攻擊一台(Windows)電腦是如此容易,讓人深感啟發和恐懼。但那是一台新的、未經更新也沒有修補過的電腦。」

McGrath表示,安裝反間諜軟體機制不如定時更新軟體來得重要。他說微軟和原始設備製造商(OEM)密切合作,鼓勵他們預先安裝防毒軟體和反間諜軟體機制,供顧客免費試用30天。他表示,XP Service Pack 2有一道防火牆,而Vista的「作業系統元件」也不會讓一般駭客進出自如。(陳智文/譯)

Nov 13, 2007

AOL一週進行2次收購 拿下社交搜索網Yedda

發佈時間:2007.11.13 07:54 來源:賽迪網 作者:天虹

【賽迪網訊】11月13日消息,據外電報道,AOL週一宣佈,它已經收購了以色列社交搜索網站Yedda。這個社交搜索網站主要是把問題與最可能的用戶連接在一起以便得到答案並且開始討論這個話題。這個技術將集成到AOL網站有選擇的節目區域。在這次收購完成之後,Yedda將作為AOL的全資子公司繼續經營。這筆收購交易的金融條款沒有披露。




AOL首席運營官Ron Grant稱,把Yedda獨特的技術結合到AOL能夠使我們把我們傳統的搜索資源與整個社區的人聯繫起來,幫助用戶快速找到答案。




收購Yedda是AOL在一個星期之內進行的第二次收購。此前,AOL以3.40億美元收購了上下文廣告公司Quigo以增強其廣告部門。在ISP服務免費之後,AOL已經把廣告和互聯網作為彌補收入損失的一個途徑。


(責任編輯:胡祥寶)

Traffic Engineering

...(略)
To demonstrate how traffic engineering addresses the problem of underutilized links, we will take an example in Figure 3-18 by first defining the traffic engineer terminology:
  • Head-End—A router on which a TE tunnel is configured (R1)
  • Tail-End—The router on which the TE tunnel terminates (R3)
  • Mid-point—A router through which the TE tunnel passes (R2)
  • LSP—The label-switched path taken by the TE tunnel; here it's R1-R2-R3
  • Downstream router—A router closer to the tunnel tail
  • Upstream router—A router farther from the tunnel tail (so R2 is upstream to R3's downstream, and R1 is upstream from R2's downstream)

Continuing the traffic engineering building block, information distribution is done via a link state protocol, such as IS-IS or OSPF. The link state protocol is required only for traffic engineering, not for the implementation of Layer 3 VPNs. A link state protocol is required to ensure that information gets flooded and to build a topology of the entire network.

Information that is flooded includes link, bandwidth, and attributes. After available bandwidth information is flooded, a router can calculate a path from head to tail. The TE head-end performs a constrained SPF (CSPF) calculation to find the best path. CSPF is just like regular IGP SPF, except that it takes required bandwidth into account and looks for the best path from a head to a single tail, not to all devices.

Note that control capabilities offered by existing Internet Gateway Protocols (IGPs) are adequate for traffic engineering. This makes actualizing effective policies to address network performance problems difficult. IGPs that are based on shortest path algorithms contribute to congestion problems in autonomous systems within the Internet. SPF algorithms generally optimize based on a simple additive metric. These protocols are topology driven so bandwidth availability and traffic characteristics are not factors in routing decisions. (Refer to IETF RFC 2702, "Requirements for Traffic Engineering over MPLS.")

In practice, there has been zero impact from CSPF CPU utilization on even the largest networks. After the path is calculated, you need to signal it across the network.

To reserve any bandwidth so that other LSPs cannot overload the path and to establish an LSP for loop-free forwarding along an arbitrary path, a path setup is done via PATH messages from head to tail and is similar to "call setup." A PATH MESSAGE carries a LABEL_REQUEST, whereas RESV messages are done from tail to head and are analogous to "call ACK." RESV messages transport the LABEL.

Other RSVP message types exist for LSP teardown and error signaling. The principles behind path setup are that you can use MPLS-TE to forward traffic down a path other than that determined by your IGP cost and that you can determine these arbitrary paths per tunnel head-end.

…(略)

Resilient Packet Ring Feature Guide

IEEE 802.17 Resilient Packet Ring Feature Guide

This feature guide describes how to configure the Cisco implementation of the IEEE 802.17 Resilient Packet Ring (RPR) protocol on supported Cisco routers and includes information about the benefits of the feature, supported platforms, related publications, and so on. RPR is similar but not identical to the Spatial Reuse Protocol (SRP), the underlying technology used in the Cisco Dynamic Packet Transfer (DPT) family of products. Throughout this document, this feature is referred to as RPR.

This document covers the use of the RPR feature. It does not include hardware installation and initial configuration information. Refer to the appropriate router installation and configuration note for information on how to configure the hardware and prepare it for use with RPR.

Information About RPR
Resilient Packet Ring (RPR), as described in IEEE 802.17, is a metropolitan area network (MAN) technology supporting data transfer among stations interconnected in a dual-ring configuration. This protocol is very similar to Spatial Reuse Protocol (SRP), which was designed by Cisco and implemented in Dynamic Packet Transport (DPT) products. New DPT interfaces have been designed to include the 802.17 RPR protocol and are available for multiple Cisco router platforms. This guide describes the RPR interface and how to use RPR on compliant Cisco equipment.

RPR is a high-speed MAC-layer protocol that is optimized for packet transmission in resilient ring topologies. RPR employs a ring structure using unidirectional, counter-rotating ringlets. Each ringlet is made up of links with data flow in the same direction. The ringlets are identified as ringlet 0 and ringlet 1, as shown in Figure 1. The use of dual fiber-optic rings provides a high level of packet survivability. If a station fails or fiber is cut, data is transmitted over the alternate ring.

Figure 1 Dual-Ring Structure



As shown in Figure 1, the east interface of Station 1 (S1) transmits to and receives from the west interface of Station 2 (S2). Ringlet 0 always transverses from east to west and ringlet 1 from west to east. The west span is the span on which RPR transmits on ringlet 1 and the east span is the span on which RPR transmits on ringlet 0.

RPR stations dynamically share the ring bandwidth and permit many simultaneous conversations. Spatial bandwidth reuse is possible due to the packet destination-stripping property of RPR. RPR provides efficient use of available bandwidth by allowing the destination station to remove unicast packets after they are read, thereby providing bandwidth reuse for the other stations on the RPR ring.

Figure 2 illustrates the end-to-end MAC architecture of RPR.
Figure 2 End-to-End View of MAC Architecture


While DPT and SRP uses SONET/SDH as the physical medium, IEEE 802.17 RPR has been defined to use both SONET/SDH and the layer used for Gigabit and 10 Gigabit Ethernet.

Comparison of RPR with SRP and DPT Technologies
IEEE 802.17 RPR is very similar to the Cisco-developed SRP technology, which is used in the Cisco DPT product line. Besides their different frame formats, other differences and similarities between IEEE 802.17 RPR and SRP can be summarized as follows:

•Fairness

–IEEE 802.17 RPR has a fairness algorithm that is used in the dynamic SRP-like mode suitable for routing and switching applications.
–A third priority has been added for traffic that requires guaranteed bandwidth, but that is not sensitive to latency and jitter.

•Protection

–SRP supports wrapping.
–IEEE 802.17 RPR supports systems that are capable of steering only protection.
–Cisco-implemented RPR supports both wrapping and steering for protection.
–Wrapping requires two stations to perform protection and suffers the least packet loss.
–Steering requires that every station determines the location of the failure and avoids that particular span. Steering is slower to converge in large topologies versus wrapping.

RPR Features
RPR offers the following main features:

•Addressing. Unicast, multicast, and simple broadcast data transfers are supported.

•Services. Multiple service qualities are supported. Per-service-quality flow-control protocols regulate traffic introduced by clients.

–Class A. The allocated or guaranteed bandwidth has low circumference-independent jitter.
–Class B. The allocated or guaranteed bandwidth has bounded circumference-dependent jitter. This class allows for transmissions of excess information rate (EIR) bandwidths (with class C properties).
–Class C. This class provides best-effort services.

•Efficiency. Design strategies increase effective bandwidths beyond those of a broadcast ring.

–Concurrent transmission. Clockwise and counterclockwise transmissions can be concurrent.
–Bandwidth reallocation. Bandwidths can be reallocated on nonoverlapping segments.
–Bandwidth reclamation. Unused bandwidths can be reclaimed by opportunistic services.
–Spatial bandwidth reuse. Opportunistic bandwidths are reused on nonoverlapping segments.
–Temporal bandwidth reuse. Unused opportunistic bandwidth can be consumed by others.

•Fairness. Fairness ensures proper partitioning of opportunistic traffic.

–Weighted. Weighted fairness allows a weighted fair access to available ring capacity.
–Simple. Simple fairness provides point-of-congestion flow control.
–Detailed. The (optional) multichoke fairness allows the client to selectively throttle its transmissions based on multiple congestion point indications.

•Plug-and-play. Automatic topology discovery and advertisement of station capabilities allow systems to become operational without manual intervention.

•Robustness. Multiple features support robust frame transmissions.

–Responsive. Service restoration time is less than 50 milliseconds after a station or link failure.
–Lossless. Queue and shaper specifications avoid frame loss in normal operation.
–Tolerant. Fully distributed control architecture eliminates single points of failure.
–OAM. Operations, administration, and maintenance support service provider environments.

RFC4170 - Tunneling Multiplexed Compressed RTP (TCRTP)

…(略)
ICRQ ->
Mandatory AVP's:
Message Type
Assigned Session ID
Call Serial Number
…(略)

QoS Requirements of Video

Two main types of video traffic exist: Interactive-Video (videoconferencing) and Streaming-Video (both unicast and multicast). Each type of video is examined separately.

Interactive-Video
When provisioning for Interactive-Video (video conferencing) traffic, the following guidelines are recommended:

  • Interactive-Video traffic should be marked to DSCP AF41; excess videoconferencing traffic can be marked down by a policer to AF42 or AF43.
  • Loss should be no more than 1 percent.
  • One-way latency should be no more than 150 ms.
  • Jitter should be no more than 30 ms.
  • Assign Interactive-Video to either a preferential queue or a second priority queue (when supported); when using Cisco IOS LLQ, overprovision the minimum-priority bandwidth guarantee to the size of the videoconferencing session plus 20 percent. (For example, a 384-kbps videoconferencing session requires 460 kbps of guaranteed priority bandwidth.)

OSPF Sham-Link Support for MPLS VPN

Using OSPF in PE-CE Router Connections

In an MPLS VPN configuration, the OSPF protocol is one way you can connect customer edge (CE) routers to service provider edge (PE) routers in the VPN backbone. OSPF is often used by customers that run OSPF as their intrasite routing protocol, subscribe to a VPN service, and want to exchange routing information between their sites using OSPF (during migration or on a permanent basis) over an MPLS VPN backbone.

Figure 1 shows an example of how VPN client sites that run OSPF can connect over an MPLS VPN backbone.

Figure 1 OSPF Connectivity Between VPN Client Sites and an MPLS VPN Backbone



When OSPF is used to connect PE and CE routers, all routing information learned from a VPN site is placed in the VPN routing and forwarding (VRF) instance associated with the incoming interface. The PE routers that attach to the VPN use the Border Gateway Protocol (BGP) to distribute VPN routes to each other. A CE router can then learn the routes to other sites in the VPN by peering with its attached PE router. The MPLS VPN superbackbone provides an additional level of routing hierarchy to interconnect the VPN sites running OSPF.

When OSPF routes are propagated over the MPLS VPN backbone, additional information about the prefix in the form of BGP extended communities (route type, domain ID extended communities) is appended to the BGP update. This community information is used by the receiving PE router to decide the type of link-state advertisement (LSA) to be generated when the BGP route is redistributed to the OSPF PE-CE process. In this way, internal OSPF routes that belong to the same VPN and are advertised over the VPN backbone are seen as interarea routes on the remote sites.

For basic information about how to configure an MPLS VPN, refer to:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm

Using a Sham-Link to Correct OSPF Backdoor Routing

Although OSPF PE-CE connections assume that the only path between two client sites is across the MPLS VPN backbone, backdoor paths between VPN sites (shown in grey in Figure 2) may exist. If these sites belong to the same OSPF area, the path over a backdoor link will always be selected because OSPF prefers intraarea paths to interarea paths. (PE routers advertise OSPF routes learned over the VPN backbone as interarea paths.) For this reason, OSPF backdoor links between VPN sites must be taken into account so that routing is performed based on policy.

Figure 2 Backdoor Paths Between OSPF Client Sites



For example, Figure 2 shows three client sites, each with backdoor links. Because each site runs OSPF within the same Area 1 configuration, all routing between the three sites follows the intraarea path across the backdoor links, rather than over the MPLS VPN backbone.

The following example shows BGP routing table entries for the prefix 10.3.1.7/32 in the PE-1 router in Figure 2. This prefix is the loopback interface of the Winchester CE router. As shown in bold in this example, the loopback interface is learned via BGP from PE-2 and PE-3. It is also generated through redistribution into BGP on PE-1.

PE-1# show ip bgp vpnv4 all 10.3.1.7

BGP routing table entry for 100:251:10.3.1.7/32, version 58

Paths: (3 available, best #2)

Advertised to non peer-group peers:

10.3.1.2 10.3.1.5

Local

10.3.1.5 (metric 30) from 10.3.1.5 (10.3.1.5)

Origin incomplete, metric 22, localpref 100, valid, internal

Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF

RT:1:2:0 OSPF 2

Local

10.2.1.38 from 0.0.0.0 (10.3.1.6)

Origin incomplete, metric 86, localpref 100, weight 32768,

valid, sourced, best

Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF

RT:1:2:0 OSPF 2

Local

10.3.1.2 (metric 30) from 10.3.1.2 (10.3.1.2)

Origin incomplete, metric 11, localpref 100, valid, internal

Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF

RT:1:2:0 OSPF 2


Within BGP, the locally generated route (10.2.1.38) is considered to be the best route. However, as shown in bold in the next example, the VRF routing table shows that the selected path is learned via OSPF with a next hop of 10.2.1.38, which is the Vienna CE router.

PE-1# show ip route vrf ospf 10.3.1.7

Routing entry for 10.3.1.7/32

Known via "ospf 100", distance 110, metric 86, type intra area

Redistributing via bgp 215

Advertised by bgp 215

Last update from 10.2.1.38 on Serial0/0/0, 00:00:17 ago

Routing Descriptor Blocks:

* 10.2.1.38, from 10.3.1.7, 00:00:17 ago, via Serial0/0/0

Route metric is 86, traffic share count is 1


This path is selected because:

•The OSPF intra-area path is preferred over the interarea path (over the MPLS VPN backbone) generated by the PE-1 router.

•OSPF has a lower administrative distance (AD) than internal BGP (BGP running between routers in the same autonomous system).

If the backdoor links between sites are used only for backup purposes and do not participate in the VPN service, then the default route selection shown in the preceding example is not acceptable. To reestablish the desired path selection over the MPLS VPN backbone, you must create an additional OSPF intra-area (logical) link between ingress and egress VRFs on the relevant PE routers. This link is called a sham-link.

A sham-link is required between any two VPN sites that belong to the same OSPF area and share an OSPF backdoor link. If no backdoor link exists between the sites, no sham-link is required.

Figure 3 shows a sample sham-link between PE-1 and PE-2. A cost is configured with each sham-link and is used to decide whether traffic will be sent over the backdoor path or the sham-link path. When a sham-link is configured between PE routers, the PEs can populate the VRF routing table with the OSPF routes learned over the sham-link.

Figure 3 Using a Sham-Link Between PE Routers to Connect OSPF Client Sites



Because the sham-link is seen as an intra-area link between PE routers, an OSPF adjacency is created and database exchange (for the particular OSPF process) occurs across the link. The PE router can then flood LSAs between sites from across the MPLS VPN backbone. As a result, the desired intra-area connectivity is created.

The section, " Creating a Sham-Link", describes how to configure a sham-link between two PE routers. For more information about how to configure OSPF, refer to:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cospf.htm

Sham-Link Configuration Example

The example in this section is designed to show how a sham-link is used only to affect the OSPF intra-area path selection of the PE and CE routers. The PE router also uses the information received from MP-BGP to set the outgoing label stack of incoming packets, and to decide to which egress PE router to label switch the packets.

Figure 4 shows a sample MPLS VPN topology in which a sham-link configuration is necessary. A VPN client has three sites, each with a backdoor link. Two sham-links have been configured, one between PE-1 and PE-2, and another between PE-2 and PE-3. A sham-link between PE-1 and PE-3 is not necessary in this configuration because the Vienna and Winchester sites do not share a backdoor link.

Figure 4 Sham-Link Example



The following example shows the forwarding that occurs between sites from the standpoint of how PE-1 views the 10.3.1.7/32 prefix, the loopback1 interface of the Winchester CE router in Figure 4.

PE-1# show ip bgp vpnv4 all 10.3.1.7

BGP routing table entry for 100:251:10.3.1.7/32, version 124

Paths: (1 available, best #1)

Local

10.3.1.2 (metric 30) from 10.3.1.2 (10.3.1.2)

Origin incomplete, metric 11, localpref 100, valid, internal,

best

Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF

RT:1:2:0 OSPF 2


PE-1# show ip route vrf ospf 10.3.1.7

Routing entry for 10.3.1.7/32

Known via "ospf 100", distance 110, metric 13, type intra area

Redistributing via bgp 215

Last update from 10.3.1.2 00:12:59 ago

Routing Descriptor Blocks:

10.3.1.2 (Default-IP-Routing-Table), from 10.3.1.7, 00:12:59 ago


The next example shows forwarding information in which the next hop for the route, 10.3.1.2, is the PE-3 router rather than the PE-2 router (which is the best path according to OSPF). The reason the OSPF route is not redistributed to BGP on the PE is because the other end of the sham-link already redistributed the route to BGP and there is no need for duplication. The OSPF sham-link is used only to influence intra-area path selection. When sending traffic to a particular destination, the PE router uses the MP-BGP forwarding information.

PE-1# show ip bgp vpnv4 all tag begin 10.3.1.7

10.3.1.7/32 10.3.1.2 notag/38


PE-1# show tag-switching forwarding 10.3.1.2

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

31 42 10.3.1.2/32 0 PO3/0/0 point2point


PE-1# show ip cef vrf ospf 10.3.1.7

10.3.1.7/32, version 73, epoch 0, cached adjacency to POS3/0/0

0 packets, 0 bytes

tag information set

local tag: VPN-route-head

fast tag rewrite with PO3/0/0, point2point, tags imposed: {42 38}

via 10.3.1.2, 0 dependencies, recursive

next hop 10.1.1.17, POS3/0/0 via 10.3.1.2/32

valid cached adjacency

tag rewrite with PO3/0/0, point2point, tags imposed: {42 38}


If a prefix is learned across the sham-link and the path via the sham-link is selected as the best, the PE router does not generate an MP-BGP update for the prefix. It is not possible to route traffic from one sham-link over another sham-link.

In the following example, PE-2 shows how an MP-BGP update for the prefix is not generated. Although 10.3.1.7/32 has been learned via OSPF across the sham-link as shown in bold, no local generation of a route into BGP is performed. The only entry within the BGP table is the MP-BGP update received from PE-3 (the egress PE router for the 10.3.1.7/32 prefix).

PE-2# show ip route vrf ospf 10.3.1.7

Routing entry for 10.3.1.7/32

Known via "ospf 100", distance 110, metric 12, type intra area

Redistributing via bgp 215

Last update from 10.3.1.2 00:00:10 ago

Routing Descriptor Blocks:

* 10.3.1.2 (Default-IP-Routing-Table), from 10.3.1.7, 00:00:10 ago

Route metric is 12, traffic share count is 1


PE-2# show ip bgp vpnv4 all 10.3.1.7

BGP routing table entry for 100:251:10.3.1.7/32, version 166

Paths: (1 available, best #1)

Not advertised to any peer

Local

10.3.1.2 (metric 30) from 10.3.1.2 (10.3.1.2)

Origin incomplete, metric 11, localpref 100, valid, internal,

best

Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF

RT:1:2:0 OSPF 2


The PE router uses the information received from MP-BGP to set the ongoing label stack of incoming packets, and to decide to which egress PE router to label switch the packets.

...(略)

IP Event Dampening

The IP Event Dampening feature introduces a configurable exponential decay mechanism to suppress the effects of excessive interface flapping events on routing protocols and routing tables in the network. This feature allows the network operator to configure a router to automatically identify and selectively dampen a local interface that is flapping.

Restrictions for IP Event Dampening
Subinterface Restrictions
Only primary interfaces can be configured with this feature. IP Event Dampening does not track the flapping of individual subinterfaces on an interface.

Virtual Templates Not Supported
Copying a dampening configuration from virtual templates to virtual access interfaces is not supported because dampening has limited usefulness to existing applications that use virtual templates. Virtual access interfaces are released when an interface flaps, and new connections and virtual access interfaces are acquired when the interface comes up and is made available to the network. Since dampening states are attached to the interface, the dampening states would not survive an interface flap.

IPX Routing Protocols Not Supported
IPX protocols are not supported by the IP Event Dampening feature. However, IPX variants of these protocols will still receive up and down state event information when this feature is enabled. This should not create any problems or routing issues.

IP Event Dampening Overview
Interface state changes occur when interfaces are administratively brought up or down or if an interface changes state. When an interface changes state or flaps, routing protocols are notified of the status of the routes that are affected by the change in state. Every interface state change requires all affected devices in the network to recalculate best paths, install or remove routes from the routing tables, and then advertise valid routes to peer routers. An unstable interface that flaps excessively can cause other devices in the network to consume substantial amounts of system processing resources and cause routing protocols to lose synchronization with the state of the flapping interface.

The IP Event Dampening feature introduces a configurable exponential decay mechanism to suppress the effects of excessive interface flapping events on routing protocols and routing tables in the network. This feature allows the network operator to configure a router to automatically identify and selectively dampen a local interface that is flapping. Dampening an interface removes the interface from the network until the interface stops flapping and becomes stable. Configuring the IP Event Dampening feature improves convergence times and stability throughout the network by isolating failures so that disturbances are not propagated, which reduces the utilization of system processing resources by other devices in the network and improves overall network stability.

Interface State Change Events
This section describes the interface state change events of the IP Event Dampening features. This feature employs a configurable exponential decay mechanism that is used to suppress the effects of excessive interface flapping or state changes. When the IP Event Dampening feature is enabled, flapping interfaces are dampened from the perspective of the routing protocol by filtering excessive route updates. Flapping interfaces are identified, assigned penalties, suppressed if the necessary, and made available to the network when the interface stabilizes. Figure 1 is a chart that displays interface state events as they are perceived by routing protocols.

Suppress Threshold
The suppress threshold is the value of the accumulated penalty that triggers the router to dampen a flapping interface. The flapping interface is identified by the router and assigned a penalty for each up and down state change, but the interface is not automatically dampened. The router tracks the penalties that a flapping interface accumulates. When the accumulated penalty reaches the default or preconfigured suppress threshold, the interface is placed in a dampened state.

Half-Life Period
The half-life period determines how fast the accumulated penalty can decay exponentially. When an interface is placed in a dampened state, the router monitors the interface for additional up and down state changes. If the interface continues to accumulate penalties and the interface remains in the suppress threshold range, the interface will remain dampened. If the interface stabilizes and stops flapping, the penalty is reduced by half after each half-life period expires. The accumulated penalty will be reduced until the penalty drops to the reuse threshold. The configurable range of the half-life period timer is from 1 to 30 seconds. The default half-life period timer is 5 seconds.

Reuse Threshold
When the accumulated penalty decreases until the penalty drops to the reuse threshold, the route is unsuppressed and made available to the other devices on the network. The range of the reuse value is from 1 to 20000 penalties. The default value is 1000 penalties.

Maximum Suppress Time
The maximum suppress time represents the maximum amount of time an interface can remain dampened when a penalty is assigned to an interface. The maximum suppress time can be configured from 1 to 20000 seconds. The default of the maximum penalty timer is 20 seconds or four times the default half-life period (5 seconds). The maximum value of the accumulated penalty is calculated, based on the maximum suppress time, reuse threshold, and half-life period.

Figure 1 Interface State Change Events Perceived by the Routing Protocols



Affected Components
When an interface is not configured with dampening, or when an interface is configured with dampening but is not suppressed, the routing protocol behavior as a result of interface state transitions is not changed by the IP Event Dampening feature. However, if an interface is suppressed, the routing protocols and routing tables are immune to any further state transitions of the interface until it is unsuppressed.

Route Types
The following interfaces are affected by the configuration of this feature:

•Connected routes:

–The connected routes of dampened interfaces are not installed into the routing table.
–When a dampened interface is unsuppressed, the connected routes will be installed into the routing table if the interface is up.

•Static routes:

–Static routes assigned to a dampened interface are not installed into the routing table.
–When a dampened interface is unsuppressed, the static route will be installed to the routing table if the interface is up.

WHY IS QoS NEEDED?

WHY IS QoS NEEDED?

The primary goal of QoS is to provide priority for traffic flows to and from specific devices. In this context, priority means providing lower latency and higher bandwidth connections with more controlled jitter.

An underlying principle of Fibre Channel switching is that the network guarantees that no frames will be dropped. If this is the case, why do we need QoS at all?

Switches today provide high-performance, non-blocking, non-oversubscribed crossbar switch fabrics. The Cisco MDS 9513 Multilayer Director can switch more than a billion frames per second. Why would users ever need QoS when a switch fabric provides seemingly endless amounts of frame-switching capacity?
The answer is simple: congestion.

Congestion occurs for two basic reasons:
• Congestion will occur if multiple senders are contending with a smaller number of receivers. If the aggregate rate of traffic transmitted by senders exceeds the size of the connection to the receivers, blocking will occur (Figure 1).

• Any time there is a speed mismatch between senders and receivers, buffering will occur. Buffers are a finite resource on switches, typically in the range of 16 buffers (32 KB) to 255 buffers (512 KB) per port. When these buffers are full, blocking occurs (Figure 2).

Figure 1. Congestion Caused by Senders Outnumbering Receivers


Figure 2. Congestion Caused by Speed Mismatch between Senders & Receivers


Many organizations consolidate their SAN infrastructure in order to realize cost savings and increased management efficiencies by pooling disparate storage resources into one single physical storage fabric. Managing contention for resources is an important aspect in realizing the business benefits associated with storage consolidation. If storage resources become congested because noncritical business applications cause time-sensitive mission-critical applications to become slowed down, the cost benefits associated with SAN consolidation quickly disappear.

There is no automatic quick fix to alleviate congestion and blocking. It is possible to add more buffering to a switch, but additional buffers will not remove the congestion; they will simply increase the time it takes for congestion to turn into blocking. Virtual output queuing (VOQ) can be used to prevent one blocked receiver from affecting traffic being sent to other noncongested receivers ("head-of-line blocking"), but it does not do anything for traffic being sent to the congested device.

SAN traffic can be categorized as a large number of devices (hosts) communicating with a smaller number of devices (storage ports). Put another way, SAN designs are almost always over-subscribed, with more host-attached ports than storage-attached ports. What is important is making sure that the oversubscription does not impact the performance of mission-critical time-sensitive applications.

MPLS AToM: Overview

Feature Overview
Any Transport over MPLS (AToM) is a solution for transporting Layer 2 packets over an MPLS backbone. AToM enables service providers to supply connectivity between customer sites with existing data link layer (Layer 2) networks by using a single, integrated, packet-based network infrastructure — a Cisco MPLS network. Instead of separate networks with network management environments, service providers can deliver Layer 2 connections over an MPLS backbone.

With Cisco AToM technology, provisioning and connecting is straightforward. A customer using Ethernet in a building or campus in one location can connect through a service provider offering Ethernet over MPLS to the customer's Ethernet networks in remote locations.

AToM provides a common framework to encapsulate and transport supported Layer 2 traffic types over an MPLS network core. Service providers can use a single MPLS network infrastructure to offer customers connectivity for supported Layer 2 traffic, as well as customers' IP traffic in Layer 3 VPNs.

AToM supports the following transport types:

•ATM AAL5 over MPLS

•ATM Cell Relay over MPLS

•Ethernet VLAN over MPLS

•Frame Relay over MPLS

•PPP over MPLS

•HDLC over MPLS

ATM AAL5 over MPLS
How ATM AAL5 SDUs Move Between PE Routers
ATM AAL5 over MPLS encapsulates ATM AAL5 service data units (SDUs) in MPLS packets and forwards them across the MPLS network. Each AAL5 SDU is transported as a single packet. The following steps outline the process of encapsulating the SDU.

Ingress PE router

1. An ingress provider edge (PE) router receives an ATM AAL5 SDU and removes the header.

2. The PE router copies the control word elements from the header to the corresponding fields in the control word of the SDU. The control word contains:

–Explicit forward congestion indication (EFCI) bit—Used by ATM switches to indicate congestion experienced by forwarded data cells.

–Cell loss priority (CLP) bit—Indicates whether a cell should be dropped if it encounters extreme congestion as it moves through the ATM network.

3. The PE router adds a virtual circuit (VC) label and a label switched path (LSP) tunnel label to the packet for normal MPLS routing through the MPLS backbone. The core routers use the LSP tunnel label to move the packet through the MPLS backbone. A core router does not distinguish ATM AAL5 traffic from other types of traffic. The packet is handled just like other packets in the MPLS backbone.

Egress PE router

1. At the other edge of the MPLS backbone, the egress PE router receives the packet and copies the control word elements from the control word to the header.

2. The PE router removes the VC label and LSP tunnel label if one is present. If no LSP tunnel label is present, it is because the penultimate router removed that label.

3. The PE router adds an AAL5 header and sends the packet out the appropriate customer-facing interface.

Figure 1 illustrates this process.

Figure 1 ATM AAL5 Packets as They Traverse the MPLS Backbone



AAL5 Packets Containing OAM Cells
The Cisco 7200 and 7500 series routers support the transport of F5 end-to-end operational, administrative, and maintenance (OAM) cells. Only Mode 0 is supported. F5 OAM cells are transported over the MPLS backbone with the payload. The OAM cell fits into the payload of a single AAL5 packet.

Notes:

•PVC switching is not supported in OAM encapsulation.

•Both PE routers must be configured with the same VPI/VCI value.

•OAM transparency is not supported on the Cisco 12000 series routers.

OAM Cell Emulation
Supported Platforms:

This functionality is supported on the following platforms:

•Cisco 7200 series routers

•Cisco 7500 series routers

If a PE router does not support the transport of OAM cells across an LSP, you can use OAM cell emulation to locally terminate or loopback the OAM cells. You configure OAM cell emulation on both PE routers, which emulates a VC by forming two unidirectional LSPs. You use the oam-ac emulation-enable command on both PE routers to enable OAM cell emulation.

After OAM cell emulation is enabled on a router, you can configure and manage the ATM VC in the same manner as you would a terminated VC. A VC that has been configured with OAM cell emulation can send loopback cells at configured intervals toward the local CE router. The endpoint can be either of the following:

•End-to-end loopback, which sends OAM cells to the local CE router.

•Segment loopback, which responds to OAM cells to a device along the path between the PE and CE routers.

The OAM cells include the following:

•Alarm indication signal (AIS)

•Remote defect indication (RDI)

These cells identify and report defects along a VC. When a physical link or interface failure occurs, intermediate nodes insert OAM AIS cells into all the downstream devices affected by the failure. When a router receives an AIS cell, it marks the ATM VC down and sends an RDI cell to let the remote end know about the failure.

See the Configure OAM Cell Emulation for ATM AAL5 over MPLS section for information on configuring OAM cell emulation.

...(略)

L2TPv3 Enables Layer 2 Services for IP Networks

White Paper

--------------------------------------------------------------------------------

Layer 2 Tunneling Protocol Version 3
Enables Layer 2 Services for IP Networks
The competitive environment for service providers has changed considerably since the Internet became a global force in the 1990s. Enterprises are no longer signing up for new IP-based services for the novelty or out of fear of being left behind by the competition. The challenge for service providers today is to grow their businesses by expanding their customer base and service revenue in a more cautious spending environment. Most enterprises are taking a more conservative approach to network investments. New IP-based services give enterprises an opportunity to improve their productivity and competitiveness while lowering their existing network expenses. Service providers that offer these services and savings can grow their customer base and service revenue. This white paper focuses on one such opportunity—offering traditional network integration over native IP network cores to lower the costs of maintaining separate traditional networks while adding IP-based services to enterprise customers.

Introduction
Enterprises and governments worldwide use traditional Layer 2 connection services. Services such as ATM, Frame Relay, and leased line provide the point-to-point connectivity upon which private networks are built.

Today's enterprise network managers have many questions and options to consider when implementing and operating the corporate intranet. Do they manage it internally or outsource it to the service provider? Should application-specific service levels be considered? What network security levels are required? What features can ever-shrinking budgets support?

Many enterprise customers use Layer 2 services such as ATM, Ethernet, Frame Relay, and leased line to interconnect the corporate intranet using their service provider. With the build-out of common packet-based infrastructure in the service provider core, these Layer 2 frames that now exist at the edge can be tunneled across the packet-switched network.

Cisco IOS® Software offers Layer 2 Tunneling Protocol (L2TP) Version 3, an Internet Engineering Task Force (IETF) standard track protocol that provides this capability. L2TPv3 helps enable service providers to deliver traditional Layer 2 services entirely from their IP infrastructures. It empowers services providers to:

•Drive down the cost of providing traditional Layer 2 services through superior cost efficiencies of multiservice IP infrastructures

•Extend their existing Layer 2 networks without expanding their legacy networks

•Lower the cost of providing multiple services to a customer site through service bundling

Offering a traditional Layer 2 service such as Frame Relay using an IP network infrastructure can lower the cost of providing the same service compared to offering the same service using a dedicated Layer 2 network. IP network infrastructures support multiple service types, and multiservice networks can spread network investments and operating costs across a larger and more diverse customer base. L2TPv3 also allows a service provider to extend the geographic reach of its traditional Layer 2 service to areas where its Layer 2 networks do not currently exist. Traditional Layer 2 services can now be offered as far as the IP network can reach.

Using L2TPv3, service providers can now enhance their product portfolios to include managed Internet, intranet, and extranet services without adding complexity and expense. Customer equipment investments are protected as customers continue to connect to the service provider through their existing infrastructures.

Cisco Systems® has long been an innovator in internetworking technologies. Advanced hardware platforms running Cisco IOS Software are the primary building blocks for efficient, profitable networks. Cisco is committed to working with customers to develop the equipment, protocols, and support they require, with the technologies of their choice.

Layer 2 Tunneling Protocol Version 3 History
L2TPv3 combines an enhanced L2TPv2 control plane with an optimized 2 field header. L2TPv3 is designed to enable service providers with a native IP-based infrastructure to offer transparent LAN services to their customers (Figure 1). L2TPv3 includes support for multiple Layer 2 encapsulations, including 802.1Q virtual LAN (VLAN), Cisco High-Level Data Link Control (HDLC), Ethernet, Frame Relay, Packet over SONET (POS), and Point-to-Point Protocol (PPP) support. The enhancements allowed service subscribers to essentially connect two similar interfaces back-to-back without any knowledge of the underlying IP network used to deliver their frames.

Figure 1

Example of Transparent LAN Services



The L2TPv3 tunnel provides the transport to allow routers 3 and 4 to appear to be connected back-to-back with POS interfaces (interfaces 1 and 4). The POS interfaces will be completely unaware of the IP transport network being used to form this connection. For a detailed discussion of the protocol capability, see the "Layer 2 Tunneling Protocol Version 3 Overview" section later in this document.

Feature Compatibility
Because L2TPv3 tunnels use IP Version 4 as the delivery protocol, Cisco offers extensive support for popular features such as multicast, NetFlow, and IP-based quality of service (QoS). Using L2TPv3, service providers can use existing compatibility with IP Security (IPSec) for enhanced network security or to allow enterprise customers to manage their own security. Enterprises using multicast and QoS support for differing traffic definitions and priorities are unaffected.

Layer 2 Tunneling Protocol Version 3 Overview
L2TPv3 includes two distinct components or message types. The first is a control connection, a reliable, in-band connection between endpoints responsible for tunnel and session setup, teardown, and maintenance, and is facilitated through "control messages." The second is a forwarding plane, responsible for the encapsulation of Layer 2 data to be forwarded over the IP network through "data messages." Either component can be implemented independently.

When the control connection is implemented between a pair of provider edge routers this is referred to as the L2TP Control Connection Endpoint or LCCE. When the control connection is operational, it can negotiate session IDs and other requirements for circuits subject to Layer 2 transport. These are referred to as attachment circuits. After the session ID has been negotiated, it can be prepended to the Layer 2 datagram that is being transported (Figure 2).

Figure 2

L2TP Version 3 Encapsulation in an IP Version 4 Header



The session ID is a 32-bit locally significant field used to identify the call on the destination or egress tunnel endpoint. The session ID will be negotiated by the control connection or statically defined if using the L2TPv3 data plane only.

The cookie is a variable length (with a maximum of eight bytes), word-aligned optional field. The control connection can negotiate this as an additional level of guarantee beyond the regular session ID lookup to make sure that a data message has been directed to the correct session or that any recently reused session ID will not be misdirected.

For a detailed description of L2TPv3 control channel operation, see the IETF draft for L2TP at

http://www.ietf.org/html.charters/l2tpext-charter.html

How Layer 2 Tunneling Protocol Works
This discussion will focus on the macro processes involved in creating an L2TPv3-based service. Figure 3 depicts the basic protocol operation.

Figure 3

Protocol Operational Overview



1. First, the customer connects to the service provider's edge router via a DS-3 serial interface and sets the encapsulation to High-Level Data Link Control (HDLC). No special configuration is required for the customer's edge router.

2. In the service provider network on the provider-edge router connecting to the customer site, an L2TPv3 tunnel is configured with the destination IP address of the peering provider-edge router where the customer's egress circuit is attached. This is accomplished using the XConnect command-line interface (CLI). The corresponding XConnect configuration is required on the remote provider-edge router.

3. At this point, L2TPv3 will determine if a control connection exists between the destination provider-edge router. If not, the provider-edge router will send out a Start-Control-Connection-Request message to initiate one. After the tunnel has been established, session negotiation can take place for any attachment circuits requiring Layer 2 transport services between the LCCEs.

4. Next, session ID and cookie values can be negotiated between the LCCEs to give each attachment circuit its unique identification for proper demultiplexing at the remote provider edge. This is a bidirectional process and the session ID is unique to the remote peer only. In the absence of the L2TPv3 control connection, static session IDs may be defined.

5. After session IDs have been successfully negotiated, data received on the ingress interface of the provider-edge router will be prepended with the remote provider-edge router's session ID and forwarded through the outer IP header's destination IP address.

6. Finally, the packet is received at the destination provider-edge router, the L2TPv3 header is demultiplexed based on the session ID and validated against the negotiated cookie value. If the header is valid, it is stripped and the original Layer 2 frame is forwarded through the associated physical port and on to the destination customer-edge router.

Layer 2 Tunneling Protocol Version 3 Applications
Virtual Leased Line
Virtual leased lines are a common requirement of the enterprise that wants to connect remote sites over a clear, dedicated bandwidth. Encapsulations typically employed are Cisco HDLC or PPP. Figure 4 illustrates the function of L2TPv3 in providing this service.

Figure 4

Virtual Leased Line


In this case, two DS-3 serial interfaces are connected to the customer's network (Enterprise A). Interface 2 and Interface 3 form the ingress and egress points of the L2TPv3 tunnel. The service provider maintains IP connectivity between provider-edge routers (PE A and PE B) using standard Interior Gateway Protocols (IGPs) such as Intermediate System-to-Intermediate System (IS-IS) Protocol or Open Shortest Path First (OSPF) Protocol. This forms the fabric for the Layer 2 VPN to be established. Any packets sent over the DS3 from the customer-edge router (CE A) would be automatically encapsulated with a L2TPv3 header and forwarded across the IP network to the egress interface on PE B and decapsulated. Then the entire original HDLC frame is forwarded out of the serial interface (Interface 3) and on to the customer-edge router CE B, thus completing the Layer 2 circuit emulation. Here is a typical configuration using the XConnect CLI:

XConnect CLI Example
PE_A:

interface Loopback0

ip address 172.18.255.1 255.255.255.255

!

pseudowire-class L2TPv3_Default

encapsulation l2tpv3

sequencing both

ip local interface Loopback0

!

interface Serial4/0

no ip address

encapsulation hdlc

dsu bandwidth 44210

framing c-bit

cablelength 10

xconnect 172.18.255.3 600 pw-class L2TPv3_Default

!

...

PE_B:

interface Loopback0

ip address 172.18.255.3 255.255.255.255

!

pseudowire-class L2TPv3_Default

encapsulation l2tpv3

sequencing both

ip local interface Loopback0

!

interface Serial4/0

no ip address

encapsulation hdlc

dsu bandwidth 44210

framing c-bit

cablelength 10

xconnect 172.18.255.1 600 pw-class L2TPv3_Default

!

...

Cisco Nonstop Forwarding for BGP: Deployment & Troubleshooting

1.0 Overview
Cisco Nonstop Forwarding with Stateful Switchover (NSF with SSO) is a Cisco innovation for routers with dual route processors. Cisco NSF with SSO allows a router that has experienced hardware or software failure of an active route processor to maintain data link layer connections and continue forwarding packets during the switchover to the standby route processor. This forwarding can continue despite lost routing protocol peering arrangements with other routers. Routing information is recovered dynamically, in the background, while packet forwarding proceeds uninterrupted.

Cisco NSF for BGP is a combination of internal system modifications to the various NSF-capable hardware platforms, and external enhancements to the BGP-4 protocol. The modifications to the BGP protocol (BGP Graceful Restart) have been submitted to the Internet Engineering Task Force (IETF):

http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-06.txt1

This document will detail specific changes to the BGP protocol. In addition, it will explore common deployment scenarios for BGP NSF and the basic troubleshooting techniques available to analyze the functionality of this new technology.

2.0 Benefits of Cisco Nonstop Forwarding
In pursuit of higher revenues and profitability, Service Providers and Enterprises are increasingly putting more mission-critical, time sensitive services on their IP infrastructure. One of the key challenges in this business model is achieving and delivering high network availability. This network availability is measured and billed appropriately via a Service Level Agreement (SLA); therefore, users must address the following issues:

•Increase network and node availability during planned or unplanned software restarts, peer resets, and/or hardware (e.g., Route Processor [RP]) changes. In other words, negatively impacting events must be minimized, and maintenance windows decreased.

•Minimize topology changes seen in the network. Topological changes could cause route flapping, consuming expensive CPU cycles on the router, and producing packet jitter and undesirable traffic patterns through sub-optimal routing.

•Reduce Capital Expenditures (CapEx) and Operational Expenditures (OpEx) in deploying a highly available network.

Cisco NSF addresses these issues by:

•Providing transparent RP switchover during a hardware or software fault on a router

•Masking the impact of any failure by localizing the associated topology changes so they do not cascade throughout the entire network

•Reducing CapEx and OpEx by providing intelligent unattended failover within a single router.

•Maintaining original capital investment by enabling features on existing Cisco platforms and route processors

3.0 Protocol Enhancements
This section provides an examination of how BGP Graceful Restart works. For a more complete discussion, refer to the IETF Internet draft at http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-06.txt.

Cisco routers that support dual RPs and Cisco NSF with SSO can maintain Layer 2 data link connections and sufficient forwarding information to continue processing packets during a RP switchover. The ability to maintain Layer 2 connections during such an event is referred to as Cisco SSO.2 The ability to continue forwarding packets is implemented by using the existing information in the Forwarding Information Base (FIB) and the Cisco Express Forwarding (CEF) tables until the routing protocols can reconverge. This document will refer to a router going through an RP switchover as the Restarting Router.

However, all of these innovations would be for naught if routers that were peered with the router that performs the switchover (hereafter, the Peer Routers) did not continue to forward packets to it. In order for a Peer Router to continue packet forwarding, several conditions must be met:

•The Restarting Router and the Peer Router must each agree to support BGP Graceful Restart

•The Peer Router must not prematurely declare the Restarting Router as unavailable

•The Peer Router must not communicate any state change in the Restarting Router to any of its peers. This avoids the network-wide detrimental effect on performance associated with the sudden failure of a router

•The Peer Router must send BGP updates to help the restarting NSF router reacquire its BGP Routing Information Base (RIB)

• The Peer Router must signal the completion of the initial routing update by sending the End-of-RIB marker (discussed below)

•In the interim (before the Restarting Router has reacquired the routing information), the Peer Router must mark any routes associated with the Restarting Router as "stale", but continue to use those routes for packet forwarding

The protocol modifications begin when the initial BGP connection is established. Both the NSF-capable router and its peer indicate their understanding of the BGP Graceful Restart mechanism by exchanging a new BGP capability (#64) during the initial BGP OPEN that establishes the session.

Note that the Peer Router will send Capability 64, regardless of whether it is capable of restartability. Capability 64 does not alone indicate restartability. It can indicate that the router in question has implemented the BGP enhancements specified in the IETF draft. Thus, a Cisco 7200 Series Router that is BGP graceful-restart configured will still advertise Capability 64 to its peers, even though it does not support dual RPs and cannot restart BGP.

Additionally, the NSF-capable router will provide a list of Address Family Identifiers (AFI) and Subsequent Address Family Identifiers (SAFI) for which it has the capability to maintain forwarding state across a BGP Restart. The AFI and SAFI indicate different types of protocols for which BGP can carry information. This would include protocol support, including IPv4, IPv6, MPLS, and Unicast/Multicast routing.

Figure 1 illustrates the significant fields within the new Capabilities 64 exchange, and provides a brief discussion of their usage. Table 1 offers more detailed information about each field.

Figure 1

Format of BGP Graceful Restart Capability 64



When the NSF-capable router performs a route processor switchover, the TCP connection to the Peer Router is cleared; a Peer Router that does not support BGP restart then clears all routes associated with the Restarting Router and no longer forwards packets to it. With BGP Graceful Restart, the Peer Router marks all routes to the Restarting Router as stale, but continues to use them for packet forwarding, based upon the knowledge that the Restarting Router will re-establish the BGP session shortly and that it maintains the capability to forward packets in the interim.

When the Restarting Router's newly active RP opens the new BGP session, it will again send the Graceful Restart capability (#64). However, this time, the restart bit in the Restart Flags portion of the capability exchange will be set. This notifies the Peer Routers that the restart of the BGP process on the Restarting Router caused the disconnect/reconnect.

While continuing to forward packets, the Peer Router refreshes the Restarting Router with any relevant BGP updates. The Peer Router indicates completion of this process by sending an End-of-RIB (EOR) marker. The EOR marker for IPv4 is a BGP update message that is of the minimum length—23 bytes. The EOR does not contain any routes to be added or withdrawn. Essentially, it is an "empty" update, whose sole purpose is to indicate that all available routes have been sent. The EOR marker helps speed convergence, because it allows the router to begin best-path selection as quickly as possible, without waiting for the timer to expire.3

Once the Restarting Router has received all available routes from each peer, it can conduct best-path selection, and send any updates to its Peer Routers. The Restarting Router will also use the EOR to indicate the completion of this process.

Figure 2 provides a graphical representation of this process.

Figure 2

BGP Graceful Restart Procedures



Consider the step-by-step protocol exchange to clarify the implementation of End of RIB (EOR) and Graceful Restart (GR). The goal is to restart a BGP session without the Restarting Router's peers redirecting traffic around the Restarting Router.

1. The BGP process of Router A (RTR_A) BGP begins, and it establishes a peering relationship with router B (RTR_B). It sends an OPEN message to router B, and the OPEN message includes the Graceful Restart Capability (Code 64) and Address Family of IPv4, Subsequent Address Family of unicast. Because router B also supports GR, it also sends an acknowledgement via its own OPEN Message, which contains GR=64 and AF=IPv4.

2. An RP switchover occurs and Router A's BGP process restarts on the newly active RP. Router A does not have a routing information base on this RP, and must reacquire it from its Peer Routers. Router A will continue to forward IP packets destined for (or through) Router B using the last updated FIB and CEF table.

3. When the Receiving router (Router B) detects that the TCP session between it and Restarting Router is cleared, it immediately marks routes learned from the Restarting Router as STALE. Router B only marks routes learned from Router A as STALE; If B had other peers, then the routes learned from those peers would remain in the UP state. Router B also initializes a Restart-timer for the Restarting Router. The default setting for this timer is 120 seconds. The Restart-Timer is the amount of time that a Receiving router will wait for an OPEN message from the Restarting Router. A Receiving router will remove all STALE routes unless it receives an OPEN message from the Restarting Router within the specified Restart-time. Once router B receives router A's OPEN message, the Restart-timer is reset. During this time, Routers A and B continue to forward traffic using the last updated CEF table.

4. Router A's BGP process has initialized. It will now attempt to re-establish a BGP session with router B. It first establishes a new TCP session, and then it sends an OPEN message (Restart State bit set, Restart Time= n, and Forwarding State= IPv4). By default, Restart time is 120 seconds and it is also configurable. When Router B receives this OPEN message, it resets its own Restart-timer and starts a Stale-path timer. Stale-path, by default, is 360 seconds and is configurable.

5. Both routers successfully re-establish their session. At this point, if Router B recognizes that the Forwarding State in Router A's OPEN message is not set for IPv4, it immediately removes any STALE routes, which it had learned from the Restarting Speaker, and re-computes its routing database. (Normally, the Forwarding State will be set for IPv4)

6. Router B will begin to send UPDATE messages to Router A. These messages contain IP prefix information, and Router A will process them accordingly. Until an EOR indication is received from all peers (or the bgp update-delay timer expires), Router A will not start the BGP Route Selection Process. A new routing information database is available after the Route Selection Process is finished and the CEF information is updated accordingly. Router A starts an update-delay timer and waits up to 120 seconds to receive EOR from all of its NSF-peers.

7. Once Router A has received EOR from all its peers, it will begin the BGP Route Selection Process. Once this process is complete, it will begin to send UPDATE messages, which contain prefix information, to router B. Router A concludes this process by sending an EOR indication to Router B so that B, in turn, can start its Route Selection Process. Once Router B receives an EOR from A, and it has completed its Route Selection Process, then any STALE entries in BGP will be refreshed with newer information or removed from the BGP RIB and FIB. Router B is now converged. While Router B waits for an EOR, it also monitors stalepath-time. If the timer expires, all STALE routes will be removed and "normal" BGP processes will be started.

4.0 Router Preparation and Network Configuration:
In order to ensure a successful migration to a Graceful Restart-capable router, there are a few important principles to consider.

The router must have compatible RPs installed. In addition, care should be taken when mixing RP types:

•Cisco 12000 Series Internet Router: GRP and GRP-B RPs can be used together. If using a PRP on this router, it must be paired with another PRP.

•Cisco 10000 Series Internet Router: two PRE-1s must be used. The original PRE for this router is not supported for purposes of Cisco NSF with SSO.

•Cisco 7500: RSP-2 and RSP-4 can be used in combination. RSP-8 and RSP-16 can also be used in combination. However, an RSP-8 or RSP-16 cannot be mixed with an RSP-2 or an RSP-4.

•For all RP types on all supported platforms, the active and standby RPs must have the same amount of memory

A wide variety of line cards support Cisco NSF with SSO, but—for optimum performance of BGP Graceful Restart—every card in the router chassis should support Cisco SSO. For a list of supported line cards, please visit: http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/1221748

Cisco SSO may not be supported on any line card not specifically listed in the aforementioned document. In this case, that specific line card will operate in RPR+ mode. At the time of the RP switchover, the dCEF table on the card will be cleared. This will cause Cisco NSF to destinations reachable through that card to fail.

Subsequent releases of Cisco IOS Software provide additional hardware support for Cisco SSO on specific line cards. Please check the release notes for later releases of Cisco IOS Software to determine if support for a particular line card may be available.

The referenced document also supplies detailed instructions on enabling SSO on the platforms that support Cisco NSF. Cisco SSO is an absolute requirement for enabling Cisco NSF; it will not work unless both are concurrently enabled.

On the Cisco 12000 Series Internet Router, there is a method to validate whether all line cards within a chassis are supported. Load a software image enabled with Cisco NSF with SSO and then issue the command "show redundancy mode-supported". Each card in the chassis will be listed, and indicate the highest level of system redundancy it supports (RPR, RPR-Plus, Cisco SSO).

To achieve the full benefit of Cisco NSF with SSO, all line cards should support Cisco SSO. Furthermore, depending on platform, Distributed Cisco Express Forwarding (dCEF) must be enabled for the line cards in order for NSF to work.

The correct software image must be loaded on the flash disks of both route processors. Currently, mixing software versions between the active and standby router processors is not supported—even if both software images support Cisco NSF with SSO.

The software boot image in bootflash should also be upgraded and should correspond to the software image being loaded on the RP.

BGP Graceful Restart is configured under the global "router bgp" configuration command. The most basic configuration is "bgp graceful-restart"

Router(config-route)# [no] bgp graceful-restart

Router(config-route)# [no] bgp graceful-restart restart-time n

Router(config-route)# [no] bgp update-delay n

Router(config-route)# [no] bgp graceful-restart stalepath-time n

The "bgp graceful-restart" command must be entered on the Cisco NSF-capable router, and also must be entered on any NSF-aware peer that will be participating in Graceful Restart. Graceful Restart is not enabled by default, and must be explicitly configured on both the Restarting Router and all Peer Routers.

The "bgp graceful-restart restart-time n" is the maximum amount of time that a peer will wait for a reconnection of the TCP session and a new BGP OPEN message following the detection of a failure on the Restarting Router. If the TCP and BGP sessions are not re-established before this timer expires, the BGP session is deemed a failure, and normal BGP recovery procedures take effect. The default value for restart-time is 120 seconds.

The "bgp update-delay n" command may be entered on the Cisco NSF-capable router. The update-delay specifies the time interval- after the first peer has reconnected—during which the restarting router expects to receive all BGP updates and the EOR marker from all of its configured peers. The default value of n is 120 seconds, and n is always measured in seconds. If the restarting router has a large number of peers, each with a large number of updates to be sent, this value may need to be increased from its default value.

The "bgp graceful-restart stalepath-time n" command may be entered on the NSF-aware peer(s) of the restarting router. This timer sets an upper limit on how long the peer will continue to use stale routes for forwarding after it has re-established the BGP session with the restarting router. The default value is 360 seconds. While this should allow an adequate amount of time to allow for complete convergence, on very large networks it may be necessary to increase this value.

5.0 Deployment
There are many different variations on design and deployment of BGP networks. However, to simplify matters, it is easier to think about BGP design in terms of router functionality: What does a particular router need to accomplish given its particular placement within the network? There are three basic types of routers within a BGP network:

•Inter-AS routers run a combination of eBGP and iBGP to connect different autonomous systems. There are many variations to this: edge routers that connect Enterprise customers to the Service Provider network, Internet peering points that connect Service Provider autonomous systems together, edge routers that exist on the boundary of a BGP confederation sub-AS. (see RFC 3065). Yet, the functionality of each of these routers is identical from the Cisco NSF perspective.

•Intra-AS routers exist in the distribution layer or core of an individual AS. These routers run only iBGP and interact only with routers within their own autonomous system. Any knowledge they have of the world outside of their AS is communicated to them via Inter-AS routers

•Route Reflectors (RRs) act as aggregation and distribution points for BGP routing information. Intra-AS routers report BGP routing information to the RRs and receive information from them. RRs increase the scalability of a BGP network by removing the restriction that all iBGP peers must be fully-meshed. The two most common deployment scenarios for RRs are

–Centralized RRs: The Route Reflectors exist at the core of the BGP network, roughly equidistant from all the other routers in the AS. Each router in the AS forms a BGP session with this RR. Frequently, there will be redundant RRs in this configuration

–Distributed RRs: In this design, some subset of routers within an AS will be administratively grouped and have a local RR to which each router will form a BGP session. These RRs subsequently form BGP sessions to other RRs in other regions, or a meshed connection to other RR as well as Intra-AS routers in the core. A typical example of this type of configuration would be a Service Provider that has local RRs in each of its Points of Presence (PoPs). Figure 3 illustrates an eBGP deployment with peers in several different autonomous systems. R1, R2, R3, R4 and R5 are all eBGP peers. Furthermore, the connections R1-to-R4 are multi-homed and are peering to the loopback interface address. R1, R3, and R4 recognize each other as NSF-aware peers because each sends and acknowledges each other's GR capability. On the other hand, the BGP sessions between R1-R2 and R1-R5 are non-NSF, meaning they do not signal or acknowledge the GR capability. The following occurs when R1 goes through a BGP restart:

•R2 detects failure of the TCP/BGP session established over the R1-R2 link and will attempt to route around it. As a result of this re-computation, R2 will take the R2-R3/R3-R1 links to access AS100.

•R1 (the Restarting Router) continues to forward packets destined to AS200 along the R1-to-R2 link, because its CEF table remains intact after switchover. We now have an example of asymmetric routing that can occur when there is a mixture of NSF-aware and non-NSF-aware peers. Although asymmetric routing is not a desirable condition and may result in some packet loss, it is still preferable to the network disruption that would have ensued had R1 completely reinitialized.

•R3 and R4 will not flush routes that they had previously learned from R1. R1 should continue to forward IP packets between R3 and R4, using its last updated CEF Table.

•R3 and R4 should continue to forward IP packets to R1 using their last updated CEF table.

•R5 is non-NSF-aware; as such, it will lose the BGP session to R1 and initialize the BGP session from scratch. R1 will continue to forward packets bound for AS500 through R5, but there is no return path for the traffic. There will be packet loss until R5 successfully reconverges with R1.

•There is an exception to this rule, if R5 has a static default route pointing to R1 as the next-hop. In this case, R5 was only using BGP so it could advertise its routes into the R1 BGP table. The R5 routes are preserved at R1 and R5 only needs a default route, so there should be no packet loss.

Figure 4

NSF—Inter-AS peers



Figure 4 illustrates that R1, RC1 and RC3 are all BGP NSF-aware. Additionally, R1 is NSF-capable—meaning that it supports BGP restartability. Should R1 restart BGP, there should be little-to-no packet loss within AS100. Because R1 is also an Inter-AS router, there may be some packet loss before R2 reconverges to route traffic destined to AS100 via R3. This process was described in the previous section.

Note that there is an important deployment consideration in this scenario. In this topology, it is very common to be running an IGP protocol (i.e.: OSPF or IS-IS) to provide next-hop reachability within AS100. There is interdependence between BGP and the selected IGP protocol. During best-path calculation, BGP knows the IP address of the router advertising certain destination prefixes. However, it relies on the information from the IGP to determine the next-hop to reach that advertising router.

Because BGP Graceful Restart can alter the timing of BGP convergence, situations can potentially occur where BGP is ready to conduct best-path selection, but the IGP has not yet converged. Therefore, some destination prefixes could exist in BGP, but cannot be added to the CEF table because a path to the advertising router has not been calculated by the IGP yet. This could result in packet loss. See section 6.5 of this paper for an example of this situation.

Therefore, it is strongly recommended that NSF for IS-IS or OSPF should be configured in addition to BGP Graceful Restart. To learn more about NSF for both OSPF and IS-IS, review Globally Resilient IP deployment papers: http://www.cisco.com/warp/public/732/Tech/grip/tech.shtml

Figure 5

Cisco NSF—Inter-AS with Route Reflectors



This topology demonstrates that R1, RC1, RC2 and the Route Reflector (RR) are NSF-aware. RR is deployed as a control plane to reduce the requirements for a full iBGP mesh. Thus, it is not in the forwarding path, but forms iBGP peering arrangements with R1, RC1 and RC2. It is also assumed that a flavor of IGP NSF is implemented in this topology.

•When R1 restarts its BGP, it relies on the existing CEF table and continues to forward packets destined to (or through) RC1 and RC2.

•Meanwhile, the only peering arrangement that R1 has is with the Route Reflector. It has no direct peering with RC1 or RC2.

•Because RR is NSF-aware, it masks the fact that R1 has restarted BGP from propagating to RC1 or RC2. RC1 and RC2 continue to forward through R1.

A more interesting variation on this occurs if the Route Reflector is actually NSF-capable and restarted its BGP process.

•When the Route Reflector restarts BGP, all the clients will keep routing information, which was reflected by RR. None of the clients will switch to a backup RR (assuming a backup RR is available).

•Some special considerations must be made when using an NSF-capable Route Reflector

–It is anticipated that a Route Reflector will have more BGP peers and a larger aggregate collection of BGP data than other routers in the AS; due to these conditions, best-path selection may take longer to complete during a switchover.

–Users must balance the requirement to provide uninterrupted packet forwarding and routing stability to the network versus the likelihood of a significant routing change before convergence is complete. During this interim period, Cisco NSF uses the CEF table and not BGP routing information to forward packets.

–Assuming that the decision has been made to use Cisco NSF on the Route Reflector, another configuration adjustment may be required. If it is anticipated that the entire process of reconvergence will exceed 360 seconds, then the default value of the "bgp graceful-restart stalepath-time xxx" may need to be adjusted on all of the peers of the route reflector. The value for stale-path should be adjusted to equal the expected convergence time (in seconds) plus an additional buffer zone of 30-60 seconds to account for variances in convergence time based on changing network conditions.

The decision of whether to use BGP Graceful Restart on a Route Reflector is a complex one and depends largely on network operations. Users must consider the key trade-offs in this decision:

•Is there an alternate availability strategy (i.e.: backup RR); if so, does it provide acceptable failover time?

•How long does it take for the restarting Route Reflector to reconverge, so its Peer Routers can begin to base forwarding decisions on fresh information?

•What is the likelihood that there will be other significant BGP routing changes that occur while the Route Reflector is reconverging?

While these questions are posed in the context of a decision to use Cisco NSF with SSO on a Route Reflector, they are also good general questions that should help in determining where and how to deploy Cisco NSF with SSO.

6.0 Troubleshooting
Because the protocol changes associated with Nonstop Forwarding for BGP are well defined and documented, troubleshooting Cisco NSF with SSO becomes a matter of assuring that the correct protocol exchanges occur at the correct times. The various Cisco IOS Software "show" and "debug" commands have been modified to provide this type of information.

6.1 Validating BGP Graceful Restart
As described in the "Protocol Enhancements" section of this paper, Cisco NSF / BGP begins with, and depends upon, an agreement between the BGP peers that they have implemented the protocol extensions in the IETF Graceful-Restart draft. Examining the output of the show ip bgp neighbor X.X.X.X command can validate this negotiation.

Figure 6

sh ip bgp neighbor



Figure 6 illustrates that the show ip bgp neighbor command now documents the successful negotiation of the Graceful Restart Capability. In order for Cisco NSF to work, the Restarting Router and its peer must each have implemented the BGP protocol enhancements. It is thus vital that the capability be both "advertised and received". This output should be the same, regardless of whether it is queried on the NSF-capable router or its NSF-aware peer. Note that the advertisement of the BGP graceful-restart capability does not specify that a particular router is NSF-capable; it only signifies that the router understands the protocol changes specified in the IETF draft.

The value of the Remote Restart timer is listed. Although the local and remote BGP peers are permitted to have different restart timers, it is wise to be suspicious of a significant variance between the values. The restart timer sets an upper bound on the amount of time it will take to re-establish the TCP connection and renegotiate the graceful-restart capability in a new BGP OPEN message. Setting this value too low on either of the peers makes it unlikely that the OPEN can be re-established in time, and will lead to the failure of the Cisco NSF process.4 BGP will revert to "normal" recovery procedures in this type of case.

Refer to the following line, "Address Families preserved by peer" for information about what Address Families (i.e.: types of traffic) for which the Peer Router can maintain forwarding state during the progression of an RP switchover. IPv4 is currently the only supported Address Family. Future extensions to Cisco NSF will add support for other Address Families (or Subsequent Address Families), including Multicast, IPv6 and MPLS when these protocols are made NSF-capable.

6.2 Validating Stale Routes on an NSF-aware Peer
One of the agreed-upon capabilities of the NSF-aware Peer Router is the use of "stale" routes (the last known good routes before the restart) to continue packet forwarding while the Restarting Router is dynamically reacquiring routing information in the background (see previous section for details). This capability can be queried with the show ip bgp command.

Figure 7

sh ip bgp on NSF-aware peer



In Figure 7, the NSF-aware router has marked the routes for the 170, 180 and 190 networks as "stale" (as signified by the capital "S" beside the route itself). This behavior is expected. Only the routes reachable through the Restarting Router will be "stale". All other routes should appear as normal.

If the specific routes through the Restarting Router are not marked "S", one of several explanations might apply:

•If the route is missing from sh ip bgp, then Cisco NSF has failed for some reason and "normal" BGP reconvergence is taking place. Possible causes:

–The Peer Router is not NSF-aware. See 6.1, above

–The restart timer has expired

–The stale-path timer has expired

•If the route is present, but is not marked "S", then one of the following might apply:

–The Cisco NSF-aware router has not detected the restart on the NSF-capable router yet

–The Cisco NSF process is complete, and the NSF-aware router has replaced the stale route with a fresh one

–If the next-hop is not pointing to the Restarting Router, then Cisco NSF has failed and "normal" BGP recovery procedures have occurred, and the network has reconverged around the Restarting Router

6.3 Debugging Output on the NSF-aware Peer
As with almost all Cisco-supported protocols, BGP NSF supports debugging commands that can monitor the progression of events as a route processor switchover occurs. Table 2 illustrates the output of the commands debug ip bgp events and debug ip bgp updates on the NSF-aware peer of a Restarting Router at the time of a switchover.

...(略)

5.1 Deployment Scenarios
Figure 3
NSF Deployment —Inter-AS Peers