2008 November

Nov 30 2008

Configuring Traffic Engineering

Consider the toplogy below.

We will enable traffic engineering on the serial link between PE1 and P1 and between P1 and PE2.

The first step is to enable traffic engineering globally on all three routers using the command below.

mpls traffic-eng tunnels

Once you have enabled traffic engineering globally, you then need to enable traffic engineering on all the infrastructure links using the command below.

interface Serial1/0.1 point-to-point mpls traffic-eng tunnels

Once you have enabled traffic engineering on the interface you need to decide how much bandwidth per interface you will allow the traffic engineering tunnels to reserve. This can be done with the commands below.

interface Serial1/0.1 point-to-point ip rsvp bandwidth 512

The rsvp value configured here is advertised by IS-IS sub-TLV 10 which is encoded within TLV22. Sub-TLV 9 which is also encoded within TLV22 advertises the Maximum bandwidth of the interface which can be seen as below.

Serial1/0.1 is up, line protocol is up Hardware is M8T-X.21 Internet address is 10.0.0.2/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY Keepalive set (10 sec) Last clearing of "show interface" counters never

We can now view the Traffic Engineering Topology which is constructed using the TE extensions.

if we examine P1s topology we can see two links. It is also worth noting that each link has a TE metric as well as an IGP metric. Also you will notice there are 8 bandwidth entries for each link. We will examine these later, for now its enough to now that they are linked to the priorities of the reservations.

Also worth noting is that currently there are no bandwidth reservations as we havent set up any TE tunnels.

PE1#show mpls traffic-eng topology 2.2.2.2

IGP Id: 0000.0000.0002.00, MPLS TE Id:2.2.2.2 Router Node (isis level-2) id 2 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:1, gen:2 frag_id 0, Intf Address:10.0.0.2, Nbr Intf Address:10.0.0.1 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 1544 (kbps), max_reservable_bw_global: 512 (kbps) max_reservable_bw_sub: 0 (kbps)

Global Pool Sub Pool Total Allocated Reservable Reservable BW (kbps) BW (kbps) BW (kbps) --------------- ----------- ---------- bw[0]: 0 512 0 bw[1]: 0 512 0 bw[2]: 0 512 0 bw[3]: 0 512 0 bw[4]: 0 512 0 bw[5]: 0 512 0 bw[6]: 0 512 0 bw[7]: 0 512 0

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:3, gen:2 frag_id 0, Intf Address:10.0.0.5, Nbr Intf Address:10.0.0.6 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps) max_reservable_bw_sub: 0 (kbps)

Global Pool Sub Pool Total Allocated Reservable Reservable BW (kbps) BW (kbps) BW (kbps) --------------- ----------- ---------- bw[0]: 0 1000 0 bw[1]: 0 1000 0 bw[2]: 0 1000 0 bw[3]: 0 1000 0 bw[4]: 0 1000 0 bw[5]: 0 1000 0 bw[6]: 0 1000 0 bw[7]: 0 1000 0

We will now setup a TE tunnel with a bandwidth reservation of 256Kb with the head end of the tunnel on PE1.

interface Tunnel100 ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 256 tunnel mpls traffic-eng path-option 1 dynamic end

Once the tunnel has came up, let us reexamine the traffic engineering toplogy of node P1.

PE1#show mpls traffic-eng topology 2.2.2.2
IGP Id: 0000.0000.0002.00, MPLS TE Id:2.2.2.2 Router Node (isis level-2) id 2 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:1, gen:4 frag_id 0, Intf Address:10.0.0.2, Nbr Intf Address:10.0.0.1 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 1544 (kbps), max_reservable_bw_global: 512 (kbps) max_reservable_bw_sub: 0 (kbps)

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:3, gen:4 frag_id 0, Intf Address:10.0.0.5, Nbr Intf Address:10.0.0.6 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps) max_reservable_bw_sub: 0 (kbps)

As you can see, a reservation of 256Kb is confirmed on the outgoing and NOT incoming interface on P1.

Also, the reservable bandwidth on link[1] has descreased to 744Kb.

Now lets see what happens if we setup another tunnel between PE1 and PE2, however this time we will give the tunnel a priority value of 5 and we will reserve 256Kb for this new tunnel.

The new tunnel will be configured as follows.

interface Tunnel200 ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 256 tunnel mpls traffic-eng path-option 1 dynamic

Now lets examine the TE topology for node P1.

PE1#show mpls traffic-eng topology 2.2.2.2

IGP Id: 0000.0000.0002.00, MPLS TE Id:2.2.2.2 Router Node (isis level-2) id 2 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:1, gen:6 frag_id 0, Intf Address:10.0.0.2, Nbr Intf Address:10.0.0.1 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 1544 (kbps), max_reservable_bw_global: 512 (kbps) max_reservable_bw_sub: 0 (kbps)

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0003.00, nbr_node_id:3, gen:6 frag_id 0, Intf Address:10.0.0.5, Nbr Intf Address:10.0.0.6 TE metric:10, IGP metric:10, attribute flags:0x0 physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps) max_reservable_bw_sub: 0 (kbps)

As you can see for link[1] there are now 2 reservations, one at priority level 5 and the other at priority level 7.

The other interesting thing to note is the reservable bandwidth values for priority 5 and 7. Priority 7 tunnels now only have 488Kb of reservable bandwidth available whereas priority 5 tunnels have 744Kb of bandwidth available to them. This is due to the fact that priority 5 tunnels have more priority to the bandwidth than priority 7 tunnels. If another priority 5 tunnel requests 744Kb of bandwidth it will receive the bandwidth and the priority 7 tunnel will be “bumbed” ie will have to find another route through the network and if it cannot then it will show as down.

The last thing to do to make the TE tunnel active is to announce the tunnel with the IGP as follows.

interface Tunnel100 tunnel mpls traffic-eng autoroute announce

If we now check the routing table we can see that some routes are visible behind tunnel 100.

PE1#show ip route 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets i L2 2.2.2.2 [115/10] via 10.0.0.2, Serial1/1.1 3.0.0.0/32 is subnetted, 1 subnets i L2 3.3.3.3 [115/20] via 3.3.3.3, Tunnel100 20.0.0.0/30 is subnetted, 1 subnets i L2 20.0.0.0 [115/20] via 10.0.0.2, Serial1/1.1 10.0.0.0/30 is subnetted, 2 subnets C 10.0.0.0 is directly connected, Serial1/1.1 i L2 10.0.0.4 [115/20] via 10.0.0.2, Serial1/1.1

However its worth noting, not all subnets are being routed via tunnel 100. I’ll cover this in another post, its important to know when enabling TE which prefixes will use the tunnels.

By zismail • CCIE SP, Traffic Engineering • 1 • Tags: CCIE SP, IS-IS, TE, Traffic Engineering

Nov 29 2008

Traffic Engineering – IGP extensions (OSPF)

OSPF has been extended using TLV and sub-TLVs in order to be used with Traffic Engineering.

RFC 3630 contains details of the extensions.

The OSPF TLV extension for TE is also referred to as OSPF Opaque LSA 10. This LSA has an area flooding scope.

Opaque LSA 10 contains 2 top level TLVs.

1. Router Address TLV

2. Link TLV

Router Address TLV

If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the OSPF router ID should be the same as the BGP router ID.

Link TLV

The Link TLV describes a single link. It is composed of a set of sub-TLVs. The key sub-TLVs are:-

Sub-TLV 6 – Maximum bandwidth (4 octets)

Sub-TLV 7 – Maximum reservable bandwidth (4 octets)

Sub-TLV 8 – Unreserved bandwidth (32 octets)

By zismail • CCIE SP, OSPF, Traffic Engineering • 0 • Tags: CCIE SP, OSPF, TE, Traffic Engineering

Nov 29 2008

Traffic Engineering – IGP extensions (IS-IS)

Some extensions were added to ISIS to provide resource information to the TE process.

IS-IS Extenstions added to support TE

TLVs have been defined to extend IS-IS functionality to include it amongst the protocols of choice for TE.

Informational RFC 3784 details the TLVs which have been added To IS-IS to support TE. RFC 3874 also introduces the concept of sub-TLVs.

Sub-TLVs have been added to IS-IS. Sub-TLVs are identical to regular TLVs in their structure and layout. They differ however with respect to their location. Sub-TLVs are found within regular TLVs which in turn are found in IS-IS packets.

Sub-TLVs are used to add additional information to the parent TLV.

RFC 3784 extends IS-IS with the following TLVs

1-The Extended IS reachability TLV (TLV type 22). (see section 3 RFC 3784)
2-The Extended IP Reachability TLV (TLV type 135). (see section 4 RFC 3784)
3-The Traffic Engineering Router ID TLV (TLV type 134). (see section 5 RFC 3784)

The Extended IS reachability TLV (TLV type 22)

TLV22 contains many sub-TLVs, the key sub-TLVs required for TE are

Sub-TLV 9: Maximum link bandwidth (section 3.4)
Sub-TLV 10: Maximum reservable link bandwidth (section 3.5)
sub-TLV 11: Unreserved bandwidth (section 3.6)

The Extended IP Reachability TLV (TLV type 135)

TLV135 removes the previous restriction which only allowed a metric range of 0-63. TLV135 provides a 32 bit.

TLV 135 also added one bit(up/down but) to indicate a prefix has been redistributed from level-2 to level-1. This bit is required to prevent routing loops. When a prefix is avertised from level-2 to level-1 the up/down bit is set to 1. Prefixes with the up/down bit set to 1 cannot be advertised to level-2. This is used for loop prevention.

The Traffic Engineering Router ID TLV (TLV type 134)

The router ID TLV contains the 4 octet router ID of the router.

An Important note:- If the loopback address is used as the TE router ID and it is advertised in the IGP as well as BGP then the BGP router ID should be identical to the TE router ID.

By zismail • CCIE SP, IS-IS, Traffic Engineering • 0 • Tags: CCIE SP, IS-IS, TE, Traffic Engineering

Nov 29 2008

Traffic Engineering – Introduction

Informational RFC 3272 provides an overview of Traffic Engineering.

Traffic Engineering(TE) is different to network engineering in that TE is concerned about engineering/manipulating traffic flows across the network.

If you think about a road system, network engineering is similar to that of building the roads themselves. Where as TE is analogous to placing the traffic lights, roundabouts and diversions.

In its inception the focus of TE was managing congested networks. Traditional IP networks utilising a link state protocol such as OSPF do not take into account the congestion or utilisation of a link as part of the SPF calculation. TE was seen as a solution to this paradigm, however as like most technologies, TE has evolved to provide other more usefull services to the Traffic Engineer.

Services such as Fast Reroute, load balancing, auto-bandwidth, QoS MPLS TE to name a few.

Most Service Providers today tend to over engineer their networks and not rely on TE to squeeze every bit out of the current network. A network which is 100% utilised is actually putting customer services at risk. If any device or link fails you need idle capacity to reroute and maintain uptime.

By zismail • CCIE SP, Traffic Engineering • 0 • Tags: CCIE SP, TE, Traffic Engineering

Nov 26 2008

Controlling Label distribution

Unlike label filtering, controlling label distribution actually stops label bindings being advertised.

Consider the toplogy below.

Without controlling label distribution, PE2 will generate a label for all IGP and connected prefixes. PE2s LIB can be seen below.

PE2#show mpls ldp bindings lib entry: 1.1.1.1/32, rev 19 local binding: label: 17 remote binding: lsr: 2.2.2.2:0, label: 17 lib entry: 2.2.2.2/32, rev 20 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 3.3.3.3/32, rev 21 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 10.0.0.0/30, rev 22 local binding: label: 18 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.4/30, rev 23 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: imp-null PE2#

These labels are also propogated to P1 as you can see below.

P1#show mpls ldp bindings neighbor 3.3.3.3 lib entry: 1.1.1.1/32, rev 12 remote binding: lsr: 3.3.3.3:0, label: 17 lib entry: 2.2.2.2/32, rev 5 remote binding: lsr: 3.3.3.3:0, label: 16 lib entry: 3.3.3.3/32, rev 10 remote binding: lsr: 3.3.3.3:0, label: imp-null lib entry: 10.0.0.0/30, rev 7 remote binding: lsr: 3.3.3.3:0, label: 18 lib entry: 10.0.0.4/30, rev 8 remote binding: lsr: 3.3.3.3:0, label: imp-null

If we now add the following command to PE2 you will so no label binding being advertised to P1.

no mpls ldp advertise-labels

Lets take another looks at P1s LIB.

P1#show mpls ldp bindings neighbor 3.3.3.3

P1#

As you can see there are no labels learnt from PE2

In most cases however you will want to advertise at least the loopback address of PE2. This can be done in 3 steps.

Step 1 – on PE2 configure the following ACL.

ip access-list standard LOOPBACK0 permit 3.3.3.3 0.0.0.0

Step 2 – next attach the ACL to the MPLS label distribution configuration as below.

mpls ldp advertise-labels for LOOPBACK0

Step 3 – the third and final step is to stop advertising all the remaining labels using the command below.

no mpls ldp advertise-labels

Verify that you configuration has worked on P1. We should only see a binding for the loopback.

P1#show mpls ldp bindings neighbor 3.3.3.3 lib entry: 3.3.3.3/32, rev 10 remote binding: lsr: 3.3.3.3:0, label: imp-null

By zismail • CCIE SP, MPLS • 0 • Tags: CCIE SP, LDP, MPLS

Nov 25 2008

MPLS Label Filtering

The MPLS label filtering feature is different to the limiting label distribution feature.

The MPLS Label filtering feature allows an administrator to control which Label bindings he learns from his neighboring MPLS nodes. This feature can be used to reduce the amount of memory used to store LDP label bindings advertised by other routers.

LSPs are usually only needed between PE routers. So you can use this feature on all PE routers to only accept label bindings for other PE routers.

Topology as below.

Watch the tutorial here.

We will configure PE1 to only accept LDP bindings for PE2s loopback address.

We will configure PE2 to only accept LDP bindings for PE1s loopback address.

Before we start lets check the LIB on PE1 and PE2.

PE1#show mpls ldp bindings lib entry: 1.1.1.1/32, rev 4 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: 17 lib entry: 2.2.2.2/32, rev 8 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 3.3.3.3/32, rev 18 local binding: label: 21 remote binding: lsr: 2.2.2.2:0, label: 18 lib entry: 10.0.0.0/30, rev 5 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.4/30, rev 12 local binding: label: 18 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 20.0.0.0/30, rev 14 local binding: label: 19 remote binding: lsr: 2.2.2.2:0, label: imp-null

PE2#show mpls ldp bindings lib entry: 1.1.1.1/32, rev 10 local binding: label: 17 remote binding: lsr: 2.2.2.2:0, label: 17 lib entry: 2.2.2.2/32, rev 8 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 3.3.3.3/32, rev 4 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 10.0.0.0/30, rev 12 local binding: label: 18 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.4/30, rev 5 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 20.0.0.0/30, rev 14 local binding: label: 19 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 31.31.31.31/32, rev 6 local binding: label: imp-null PE2#

We apply the following commands to PE1

ip access-list standard MPLS permit 3.3.3.3

mpls ldp neighbor 2.2.2.2 labels accept MPLS

We apply the following commands to PE2

ip access-list standard MPLS permit 1.1.1.1

mpls ldp neighbor 2.2.2.2 labels accept MPLS

After the configuration we can see only a single remote binding on both PEs.

PE1#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 4 local binding: label: imp-null lib entry: 2.2.2.2/32, rev 8 local binding: label: 16 lib entry: 3.3.3.3/32, rev 10 local binding: label: 17 remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 10.0.0.0/30, rev 5 local binding: label: imp-null lib entry: 10.0.0.4/30, rev 12 local binding: label: 18 lib entry: 20.0.0.0/30, rev 14 local binding: label: 19

PE2#show mpls ldp bindings lib entry: 1.1.1.1/32, rev 10 local binding: label: 17 remote binding: lsr: 2.2.2.2:0, label: 17 lib entry: 2.2.2.2/32, rev 8 local binding: label: 16 lib entry: 3.3.3.3/32, rev 4 local binding: label: imp-null lib entry: 10.0.0.0/30, rev 12 local binding: label: 18 lib entry: 10.0.0.4/30, rev 5 local binding: label: imp-null lib entry: 20.0.0.0/30, rev 14 local binding: label: 19 lib entry: 31.31.31.31/32, rev 6 local binding: label: imp-null

Also if we check the LFIB we can see only the remote loopbacks have an outgoing label

PE1#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 16 No Label 2.2.2.2/32 0 Se1/1.1 point2point 17 16 3.3.3.3/32 0 Se1/1.1 point2point 18 No Label 10.0.0.4/30 0 Se1/1.1 point2point 19 No Label 20.0.0.0/30 0 Se1/1.1 point2point 20 No Label 11.0.0.0/30[V] 0 aggregate/CUST 21 Pop Label 11.11.11.11/32[V] 0 aggregate/CUST

PE2#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 16 No Label 2.2.2.2/32 0 Fa2/0 10.0.0.5 17 17 1.1.1.1/32 0 Fa2/0 10.0.0.5 18 No Label 10.0.0.0/30 0 Fa2/0 10.0.0.5 19 No Label 20.0.0.0/30 0 Fa2/0 10.0.0.5 20 No Label 12.0.0.0/30[V] 0 aggregate/CUST 21 Pop Label 12.12.12.12/32[V] 0 aggregate/CUST
PE2#

By zismail • CCIE SP, MPLS • 3 • Tags: CCIE SP, MPLS

Nov 24 2008

CSC – Customer Carrier is an ISP

The basic setup for CSC where the Customer Carrier is an ISP can be seen below.

In this scenario, the Customer Carrier does not run MPLS internally except on the link facing the backbone carrier.

The Customer Carrier extends its IGP coverage to include the serial link connected to the backbone carrier where it terminates in a VRF. There are a lot of trust issues here which you would need to overcome before you did this. ie the backbone carrier could inject IPv4 prefixes into the customer carriers network.

The backbone carrier redistributes the learned IGP prefixes on CSC-PE1 into MP-BGP and thus creates VPNv4 prefixes which it advertises to CSC-PE2 where they are converted back into IPv4 prefix when MP-BGP is redistributred into the IGP.

The IPv4 prefixes advertised between the customer carrier should only contain the loopback information of the customer carrier. This will enable the customer carrier to establish a iBGP sesssion between its POPs.

Once the iBGP session is established across the backbone carrier, we can check the VPN labels generated at each hop in the network.

Lets take the loopback 0 on CSC-CE2 ie 4.4.4.4/32

CSC-CE2

CSC-CE2#show mpls ldp bindings lib entry: 4.4.4.4/32, rev 4 local binding: label: imp-null remote binding: lsr: 12.0.0.1:0, label: 20

There is no VPN label for loopback 0, but rather there is an LDP generated label of imp-null. We can see from the above entry that the remote binding ie from CSC-PE2 a label of 20 is generated.

CSC-PE2

There is an LDP generated label for CSC-CE2s loopback and there is a BGP VPN label. They are both 20 in this case, I dont know if that is just a coincedence or wether BGP retains the LDP when OSP is redistributed into BGP for VPNA.

CSC-PE2#show mpls ldp bindings vrf VPNA lib entry: 4.4.4.4/32, rev 8 local binding: label: 20 remote binding: lsr: 4.4.4.4:0, label: imp-null

CSC-PE2#sh ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 (VPNA) 4.4.4.4/32 12.0.0.2 20/nolabel

CSC-PE1

As you can see CSC-PE1 also generates his own label which is also 20:-).

CSC-PE1#show ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 (VPNA) 4.4.4.4/32 2.2.2.2 20/20

CSC-PE1#show mpls ldp bindings vrf VPNA lib entry: 4.4.4.4/32, rev 8 local binding: label: 20 remote binding: lsr: 11.0.0.2:0, label: 17

As you can see the LDP binding for 4.4.4.4 also contains a label of 20. Whether this is due to the fact BGP is redistributed into the VRF aware OSPF process, I dont know. Maybe someone can shed some light on this.

CSC-CE1

sh mpls ldp bindings 4.4.4.4 32 lib entry: 4.4.4.4/32, rev 8 local binding: label: 17 remote binding: lsr: 11.0.0.1:0, label: 20

From here you can see the remote-binding sent by CSC-PE1 which is 20.

Now lets extend the ISP network and add an actual ISP customer. The Customer wants to take a resilient BGP feed. AS100 has two transit provider who provide the full BGP routing table. We will simulate the full BGP routing table with a single loopback representing each transit provider.

Transit provider 1 = Loopback 10 = 10.10.10.10/32

Transit provider 2 = Loopback 20 = 20.20.20.20/32

Topology is as below.

The loopbacks addresses of AS100 are fully reachable in all POPs.

CSC-CE2#ping 5.5.5.5

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/88/204 ms

Now lets examine how CE2 reaches global routes via the backbone carrier. ie how does CE2 reach 10.10.10.10.

From CE2 traffic is routed via global routing table to CSC-CE2. CSC-CE2 learns the global routing table from CSC-CE1.

CSC-CE2

CSC-CE2#sh ip bgp BGP table version is 8, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path *>i10.10.10.10/32 5.5.5.5 0 100 0 i

CSC-CE2#sh ip cef 5.5.5.5 5.5.5.5/32 nexthop 12.0.0.1 FastEthernet1/0 label 301 CSC-CE2#

As the interface connecting CSC-CE2 to CSC-PE2 is MPLS enabled, an MPLS label of 301 is inserted between ethernet header and IP header and the frame is now forwarded to CSC-PE2.

CSC-PE2

CSC-PE2#show mpls ldp bindings vrf VPNA 5.5.5.5 32 lib entry: 5.5.5.5/32, rev 12 local binding: label: 301 remote binding: lsr: 4.4.4.4:0, label: 19

CSC-PE2 creates a local binding of 301, and also creates a VPN label of 301.

CSC-PE2#show ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 (VPNA) 5.5.5.5/32 1.1.1.1 301/1002

CSC-PE2#show ip cef vrf VPNA 5.5.5.5 5.5.5.5/32 nexthop 10.0.0.1 FastEthernet1/0 label 1002 CSC-PE2#

The MPLS frame which arrived from CSC-CE2 is has the VPN label swapped from 301 to 1002. The next hop for the MPLS frame is 10.0.0.1. As this IP is directly connected the MPLS frame is forwarded across the wire to CSC-PE1 with a single MPLS label.

CSC-PE1

CSC-PE1#show ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 (VPNA) 5.5.5.5/32 11.0.0.2 1002/nolabel

At this point the MPLS header is popped and the IP header is exposed. The destination IP address of the packet is 10.10.10.10. This route does not exist within the VRF on CSC-PE1 so we have to ensure their is a static default pointing to CSC-CE1.

NOTE: The global transit routes are not advertised to CSC-PE1 as this does not scale. If PE1 has hundreds of customers, we cannot expect each VRF to hold the full global routing table.

Using the default route the IP packet is forwarded to CSC-CE1 who then forwards it to net-edge via IP.

CSC-CE2#ping 10.10.10.10

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/110/216 ms CSC-CE2#

One other point, is that the CSC-CE routers are configured as route-reflectors for AS100.

By zismail • BGP, CCIE SP • 0 • Tags: BGP, CCIE SP, CSC

Nov 23 2008

Carrier Supporting Carrier – CSC

Carrier Supporting Carrier architecture is about connecting a single SPs POP sites using another Service Providers network.

In Carrier Supporting Carrier terminology, the service provider who connects another service providers POP sites is known as the backbone carrier.

The service provider whos POPs are connected via the backbone carrier is known as the customer carrier.

You might be thinking, whats the difference between inter-AS MPLS VPN and CSC.

Differences include

CSC connectes another ISPs POPs and not end customer sites. One might argue that the customer carrier whose POPs require connecting is the backbone carries customer and hence Inter is the same as CSC. Even if we made that statement, CSC still differs from Inter-AS in that CSC involves using one backbone carrier. Inter-AS however used 2 distinct “backbones” and the focus is how to connect these backbones. However looking at option 4 of Inter AS where you have a non VPN MPLS transit provider this is very similar to CSC.

Inter-AS MPLS VPN is only about MPLS VPN end customers, where as CSC is used for ISPs as well as VPN service providers.

Inter-AS MPLS VPN does not usually involve running MPLS between either the end customer and SPs or even between SPs themselves. Whereas CSC usually means running MPLS between the customer carrier and backbone carrier.

CSC also involves running an IGP between the backbone carrier and customer carrier. The IGP between the customer carrier and the backbone carrier is within a VRF on the backbone carrier side.

The backbone carrier can support multiple customer carriers.

There are two scenarios which require investigation.

Customer Carrier is VPN service provider
Customer Carrier is an Internet service provider and is not MPLS enabled

In all CSC scenarioes the backbone carrier is MPLS enabled.

By zismail • BGP, CCIE SP, MPLS VPN • 1 • Tags: BGP, CCIE SP, CSC, MPLS, MPLS VPN

Nov 23 2008

CCIE labs changing from UniversCD to Cisco Documentation

Taken from CCO

CCIE labs changing from UniversCD to Cisco Documentation

On Sept 24 2008 CCIE labs will no longer support using the UniversCD documentation for the lab exam.

All labs are migrating to Cisco Documentation only. For those scheduled to take the CCIE lab prior to Sept 24 access will still be available for UniversCD.

The Cisco Documentation pages have the same information that currently resides on UniversCD, please refer to the links on the CCIE web pages to view these pages and become familiar with the new format.

Cisco Documentation: http://www.cisco.com/web/psa/products/index.html

After Sept 24 2008 only the Cisco Documentation web pages will be available for CCIE labs.

————————————————————————–

Thanks for bringing this to my attention Morgan.

By zismail • CCIE, CCIE SP • 0 • Tags: CCIE, CCIE SP

Nov 21 2008

Inter AS MPLS VPN Option B, 2a – Packet Capture

I’ve setup the topology below.

I configured a loopback address with ip address 10.10.10.10 on PE1 and put it inside the VRF for VPN A. One PE1 I could see the VPN label being generated by BGP as below.

sh ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 (CUST) 10.10.10.10/32 0.0.0.0 19/nolabel

As you can see the “In label” is 19. To confirm the label is changed at different points in the LSP path I checked the label for 10.10.10.10 on ASBR1, ASBR2 and PE2, see below for output.

ASBR1

ASBR1#sh ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 10.10.10.10/32 1.1.1.1 17/19

As you can see ASBR1 has generated an “In label” of 17 which it advertises to ASBR2.

ASBR2

ASBR2#sh ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 10.10.10.10/32 192.168.1.1 23/17

ASBR2 generates its own “In label” of 23 and advertises it to PE2, please see below.

PE2

PE2#sh ip cef vrf CUST 10.10.10.10 10.10.10.10/32 nexthop 11.0.0.5 FastEthernet1/0 label 16 23

PE2#sh ip bgp vpnv4 all labels Network Next Hop In label/Out label Route Distinguisher: 65300:1 10.10.10.10/32 4.4.4.4 nolabel/23

I also ran a packet capture on the ASBR2 interface which peers with ASBR1 and sure enough when I ran a ping to 10.10.10.10 I saw a single stacked MPLS frame, with a VPN label of 17.

The reason there is only a single label on the frame between ASBR2 and ASBR1, can be explained due to the next hop changing.

Therefore ASBR2 is the penultimate hop in the LSP and pops the top label and hence you see the VPN label alone on the wire.

By zismail • CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

1 2 3

Categories

Tags