BFD for Cisco 7600

BFD Scale Improvement on ES+ Line Card for 7600

Bidirectional Forwarding Detection (BFD) scale improvement feature provides the functionality to offload a BFD session to an ES+ line card. BFD is a forwarding path failure detection protocol and reduces the overall network convergence time by sending rapid failure detection packets (messages) to the routing protocols for recalculating the routing table. Before Release 15.1(2)S, a BFD session was run as a software component on the Route Processor (RP). Hence, the performance of BFD was restricted to the capabilities of CPU and IOS on the RP on the Cisco 7600 Router. Effective failure detection requires BFD to run at high frequencies (using aggressive timers as low as 50ms), which was not possible because of CPU and IOS restrictions. Effective with Cisco IOS Release 15.1(2) S, apart from running a BFD session on the RP, you can also offload a BFD session to the ES+ line card based on specific conditions listed in the "Restrictions for BFD Scale Improvement" section. 

Restrictions for BFD Scale Improvement

The following restrictionsapply for BFD scale improvement:

•A BFD session is supported on only RSP 720 and Supervisor 720 (SUP720), it is not supported on SUP32.

•Only BFD version 1 is supported.

•The BFD session can be offloaded only to an ES+ line card interface.

•Ensure that the ES+ Line Card interface configured with the BFD session is on global routing table. Effective from Cisco IOS Release 15.1(3)S and 15.1(2)S1, the interface with a BFD session can be on any Virtual Routing and Forwarding (VRF).

•Each network processor supports a total of 250 sessions distributed across its ports.

•BFD hardware offload is supported for IPv4 sessions with non-echo mode only.

•You can configure IPv4 and IPv6 sessions to co-exist on the router as well as the same interface.

•Only the single hop BFD hardware offload is supported for both the IPv4 and IPv6 sessions. BFD hardware offload supports either of these combinations for IPv4 and IPv6 sessions:

–1000 IPv6 BFD sessions and no IPv4 sessions.

–2000 IPv4 BFD sessions and no IPv6 sessions.

–500 IPv4 BFD sessions and 500 IPv6 sessions.

•BFD offload is supported only for the ethernet interface.

•Timer values for Tx and Rx should only be in multiples of 50 and should range between 50 and 950ms for both the local and remote BFD peer router.

•If the Failure in MPLS core does not converge before XC BFD timer expires, then the BFD session flaps.

•BFD Tx jitter defined in RFC 5880 is not supported.

•You cannot swap a BFD session between ES+ line card and IOS by changing the parameters when the BFD session is up and running. To swap a BFD session, you need to unconfigure and reconfigure the BFD session with the changed parameters.

•BFD offload is not supported on port-channel or SVI interfaces.

•In case of prolonged network instability and BFD session flaps, the session state may get stuck in the DOWN, INIT, or UP state. Unconfigure and reconfigure BFD to resolve this issue.

•During line card OIR, the show bfd neighbor detail command may show discrepancy in the statistics counter. The statistics counter provide information about Rx or Tx counts for a particular session.

•BFD supports 2000 sessions with OSPF as client on RSP. Example scenarios:

–All subinterfaces are configured as point to point.

–Four instances of OSPF are running with each instance supporting 500 BFD session.

•Configure the symmetric slow timers to less than or equal to five seconds on both the ends to bring up the HW offloaded BFD sessions.

•BFD supports a maximum of 10 IPv6 static route sessions on an interface. 

Configuring Layer 1 and Layer 2 Features 

L2VPN Interworking

xconnect Command Syntax  - Binds the attachment circuit to a pseudowire VC.

xconnect peer-ip-address vcid pw-class pseudowire-name

 
pseudowire-class pseudowire-name





 encapsulation mpls




 interworking ethernet

L2VPN Interworking Modes



L2VPN Interworking works in either Ethernet ("bridged") mode or IP ("routed") mode. You specify the mode by issuing the interworking {ethernet | ip} command in pseudowire-class configuration mode.



The interworking command causes the attachment circuits to be terminated locally. The two keywords perform the following functions:



•The ethernet keyword
 causes Ethernet frames to be extracted from the attachment circuit and 
sent over the pseudowire. Ethernet end-to-end transmission is assumed. 
Attachment circuit frames that are not Ethernet are dropped. In the case
 of VLAN, the VLAN tag is removed, leaving an untagged Ethernet frame.



•The ip keyword
 causes IP packets to be extracted from the attachment circuit and sent 
over the pseudowire. Attachment circuit frames that do not contain IPv4 
packets are dropped. 



 

Layer 2 Virtual Private Network Interworking 

L2VPN Interworking 

Cisco IOS Multiprotocol Label Switching Command Reference 

Configuring 802.1q tunnels over Vlan-based EoMPLS & MUX-UNI 

Site of Origin BGP Community Attribute

Site of Origin BGP Community Attribute

The site-of-origin (SoO) extended community is a BGP extended community attribute that is used to identify routes that have originated from a site so that the readvertisement of that prefix back to the source site can be prevented. The SoO extended community uniquely identifies the site from which a router has learned a route. BGP can use the SoO value associated with a route to prevent routing loops.

BGP per Neighbor Site of Origin Configuration

There are three ways to configure an SoO value for a BGP neighbor:

•BGP peer policy template—A peer policy template is created, and an SoO value is configured as part of the peer policy. Under address family IPv4 VRF, a neighbor is identified and is configured to inherit the peer policy that contains the SoO value.

•BGP neighbor command—Under address family IPv4 VRF, a neighbor is identified, and an SoO value is configured for the neighbor.

•BGP peer group—Under address family IPv4 VRF, a BGP peer group is configured, an SoO value is configured for the peer group, a neighbor is identified, and the neighbor is configured as a member of the peer group. 

BGP per Neighbor SoO Configuration 

Case Study 10: BGP Site of Origin 

http://www.shafagh.net/2009/10/ccie-sp-bgp-as-pe-ce.html 

PPS BPS calculator

pps = packet per second
bps = bit per second
byte = 8 * bit
pps * average packet size (byte) = bps

Here is a handy tool: Bits per second to packets per second converter

Often vendors such as our favorite Cisco specify device performance as packets per second, so we don't need to bother about packet size mentioning because pps is rather a characteristic of device's (processor, bus, ASICs) computing power. Packets per second more or less still the same with different packets size. But it is not very convinient to deal with pps in a real life because we have to know "real" device performance in our network. So we have to do two things:

1) Determine the average packet size which is specific for our network. For example traffic profile for our network could be 30% ftp-data (large packet at 1500 bytes) and 70% VoIP-data (a lot of small packets at 64 bytes) so our average packet size is about 800 bytes.

2) Calculate with simple formula how much there will be Megabits per second (Mbps) if our average packet size is 800 bytes and device performance is, lets say, 100 kpps (one hundred thousand of packets per second)

From: Bits per second to packets per second converter

How to upgrade Debian from Lenny to Squeeze

How to upgrade Debian from Lenny to Squeeze

How to upgrade Debian from Lenny to Squeeze 

http://en.wikipedia.org/wiki/Debian 

SSM needs IGMPv3

Source-specific multicast (SSM) is a method of delivering multicast packets in which the only packets that are delivered to a receiver are those originating from a specific source address requested by the receiver. By so limiting the source, SSM reduces demands on the network and improves security.
SSM requires that the receiver specify the source address and explicitly excludes the use of the (*,G) join for all multicast groups in RFC 3376, which is possible only in IPv4's IGMPv3 and IPv6's MLDv2.
Source-specific multicast is best understood in contrast to any-source multicast (ASM). In the ASM service model a receiver expresses interest in traffic to a multicast address. The multicast network must

1. discover all multicast sources sending to that address, and
2. route data from all sources to all interested receivers.

This behavior is particularly well suited to groupware applications where

1. all participants in the group want to be aware of all other participants, and
2. the list of participants is not known in advance.

The source discovery burden on the network can become significant when the number of sources is large.
In the SSM service model, in addition to the receiver expressing interest in traffic to a multicast address, the receiver expresses interest in receiving traffic from only one specific source sending to that multicast address. This relieves the network of discovering many multicast sources and reduces the amount of multicast routing information that the network must maintain.
SSM requires support in last-hop routers and in the receiver's operating system. SSM support is not required in other network components, including routers and even the sending host. Interest in multicast traffic from a specific source is conveyed from hosts to routers using IGMPv3 as specified in RFC 4607.
SSM destination addresses must be in the ranges 232.0.0.0/8 for IPv4 or FF3x::/96 for IPv6.


Source Specific Multicast (SSM) requires Internet Group Management Protocol Version 3 (IGMPv3) 

PIM-SSM is the routing protocol that supports the implementation of SSM and is derived from PIM sparse mode (PIM-SM). IGMP is the Internet Engineering Task Force (IETF) standards track protocol used for hosts to signal multicast group membership to routers. Version 3 of this protocol supports source filtering, which is required for SSM.

Ref: 
Source-specific multicast 
Source Specific Multicast with IGMPv3, IGMP v3lite, and URD 
Using IGMPv3 For Source-Specific Multicast 

Load Balancing in BGP Networks

Good reference: Load Balancing in BGP Networks

Below are the copy from the link:

Fact #1: Load-balancing is always unidirectional
Fact #2: Not all Load-Balancing Mechanisms are Equal

External BGP Load Balancing
The true BGP-only EBGP load balancing is configured with the maximum-paths router configuration command and allows a BGP router with multiple EBGP sessions to load balance the traffic toward destinations received in EBGP updates.


IBGP Load Balancing
Option #1: Use next-hop-self
Option #2: External OSPF routes

Route Reflectors killed Load Balancing
Each BGP router selects a single best route (even though it might use more than one for packet forwarding) and propagates it to its BGP neighbors. A route reflector might thus use multiple IBGP routes and load balance between them, but its clients would only receive a single route.