CCIP Notes

IP CEF
#sh ip route (RIB)
# sh ip cashe verbose ( sh fast switching table)
#sh ip cef

(FIB - CEF Table)

#sh adjacency ( L2-L3 adjacency for CEF)

-if)# ip load-share <per packet/per-destination> (default is per destination)

# sh cef int (sh cef load balance type)

# sh ip cef <destination ip > internal ( sh the hash value used for load balance on interfaces)
# sh ip cef exact-route <source> <destination> (show the exact way taken in case of load
balance)

# debug ip cef
# sh ip cef vrf ABC <net id> detail ( show full stack label)

Control plane: Routing protocols, LDP, RIB, LIB

Traffic/Data Plane: FIB, LFIB

MPLS & LDP

FEC = Label + IPv4 prefix
LDP = uses port 646 and multicast 224.0.0.2 (UDP for discovery & TCP for session)
TDP = uses port 711 and BC 255.255.255.255
L DP has four maj or functions:

The discovery of LSRs that are running LDP. ( UDP)

Session establishment and maintenance. (TCP)
Advertising of label mappings.
Housekeeping by means of notification.

NOTE: LDP/TDP only bind labels for routes that are learned/advertized via IGP, it wont label BGP
routes, so in inter-as multihop MBGP we must use the cmd nei x.y.z.a send-label

MPLS cmds
ip cef
mpls label protocol <ldp/tdp>
mpls ldp router-id <Loopback0> <force> (force word is used to imm. Set the LDP RID)
mpls ldp discovery hello interval <sec> ( UDP LDP Discovery Hello ,5 sec by default)
mpls ldp discovery hello holdtime <sec> ( UDP LDP Discovery Holdtime 15 sec by default)
mpls ldp holdtime <sec> (LDP Session keep alive, 2nd step after LDP discovery, 180 by default)
mpls label range <min> <max>

int pos 0/0

mpls ip
mpls label protocol <ldp/tdp> ( new cmd)
mpls ldp discovery transport-address < ip address / interface> ( use LDP ID rather than the RID)
mpls mtu <MTU>

We can change the control vc for ATM Cell mode via the interface cmd
Tag-switching atm control-vc < vpi vci>

sh mpls ldp discovery (sh ldp nei ID + enabled interfaces interface)

sh mpls ldp discovery detail ( sh all nei & timers like UDP discovery & TCP session KA)
sh mpls ldp parameters
Sh mpls int <inetrface>
Sh mpls int <inetrface> details
sh mpls ldp int >>>>not working pn some IOS
sh mpls ldp nei
sh mpls ldp nei detail
sh mpls label range
sh mpls ldp/ip binding (LIB table)
sh mpls forwarding-table (LFIB table)
debug mpls packet (disable mroute-cashe under the interface 1st then enable the debug)
debug ip packet detail (disable route-cashe under the interface 1st then enable the
debug)
debug ldp transport events
Notes:
You must have an entry in the RIB to the LDP nei ID, if not the LDP session wont be up.
So you must advertise the used LDP ID into the backbone IGP
Split Horizon rule doesnt exist with LDP; the neighbor can fwd back the Label binding to the source.
If 2 LDP peers have different LDP Discovery timers configured, the smaller values will be used.
you can debug only process switched packets , so if you need to debug switched/labled/CEF packet s you
have to disable route-cash under the interface

Optional:
Ldp backoff throttling
If the LDP peers agree on the session parameters, they keep the TCP connection between them. If not, they
retry to create the LDP session between them, but at a throttled rate. In Cisco IOS, the LDP backoff
command controls this throttling rate:
mpls ldp backoff initial-backoff maximum-backoff
The initial-backoff parameter is a value between 5 and 2,147,483, with a default of 15 seconds.
The maximum-backoff is a value between 5 and 2,147,483, with a default of 120 seconds.
This command slows down the LDP session setup attempts of two LDP LSRs, when the two
neighboring LDP peers are incompatible in terms of the parameters they exchange. If the session
setup attempt fails, the next attempts are undertaken at an exponentially increased time, until the
maximum backoff time is reached. One example in which the two LDP peers might disagree on
the parameters and not form an LDP session is the case of LC-ATM, where the two peers are using
different ranges of VPI/VCI values for the labels.

Targeted LDP session: (VIP)

R1
Conf t
mpls ldp nei <ip> targeted ldp/tdp
R2
conf t
mpls ldp discovery targeted-hello accept ( to accept targeted hello from non DC nei)
mpls ldp discovery targeted-hello accept from <ACL>
access-list 10 permit x.y.z.10
Authentication (VIP)
conf t
mpls ldp nei <ip> password <password>
mpls ldp vrf <> nei <ip> password <password> (For CsC)
Controlling LDP Advertisement
Conf t
no mpls ldp advertise-labels (VIP)
mpls ldp advertise-labels for <ACL for networks> to <ACL for ldp nei>
mpls ldp advertise-labels for <ACL permit all > to <ACL for all other nei >
Controlling LDP Inbound filters (VIP)
Conf t
mpls ldp nei <nei ip> labels accept <ACL for labeled networks to be accepted>

L2 technologies:
CE ATM towards PE
CE# conf t
int atm 2/0.1 point-to-point
ip add
pvc 0/36
OR
int atm 2/0
ip add
pvc 0/36
broadcast ( if using Iarp)
protocol ip <remote IP> broadcast ! IP
protocol clns_is broadcast
protocol clns 00 broadcast

! ISIS
! ISIS

Backbone connections
conf t
int atm2/0.1 mpls/ tag-switching ( Cell mode)
ip add 1.1.1.1
mpls ip / tag-switching ip
mpls/tag-switching atm control-vc 1 32
mpls/tag-switching atm vpi x vci-range y-z
mpls label protocol both
OR
conf t
int atm2/0.1 point-to-point ( Frame mode over ATM)
ip add 1.1.1.1
pvc 0/35
encapsulation aal5snap
mpls ip

ATM LSR Tips

Conf ig)# mpls ldp maxhops <#> ( Default 254, for loop elimination )
Conf ig)# mpls ldp loop-detection ( Enable loop detection )
Conf ig)# mpls ldp address-message ( for vendors requiring ATM LSR IP address to be
sent)
Conf ig)# mpls ldp request-labels for <ACL>( stop sending Label requests to LDP
nei, in ATM Mode the LSR request label its the DOD mode, but in Frame mode its the
Unsolicited mode, where Labels are sent asa LDP is enabled, so the cmd on FR mode is
mpls ldp advertise-labels )

MPLS L3 VPNs
MPLS VRF RT & RD
RD: to make the route unique inside the VPNv4 BGP table.
The RD:IPv4 route = VPNv4
RT: is an extended community
1- To let the VPNv4 PE routers know if it will import the route in its VPNv4 table as
one of its VRFs is importing this RT, or shall it drop it.
2- The RT import & export are extended communities; they are used by the VRF to
know if it will import/export routes from/to the VPNv4 BGP table.
MPLS labels:
IGP label: between all backbone routers (PE & P), these labels are for reachability
between the backbones next-hop routers over backbone ISIS/OSPF IGP.
VPN label: between the iBGP PE peers inside the backbone, to label the routes that are
received from the CEs, this label contains the MPLS label + VPNv4 (RD: IPv4 route)
MPLS traffic packet coming out of PE = IGP-label + VPN label + IPv4 packet
To advertise the routes between PE ibgp Backbone routers, we must use M-BGP so we
can add the extended communities inside the update like RD & RT.
VPNv4 iBGP neighbors We will add the bgp neighbors inside global BGP + create a
vpnv4 address family adding same neighbors again.
VPNv4 route = RD: IPv4 route
Note: watch it again min 34 Config-router) # no bgp default ipv4-unicast

Note: By default the PE iBGP backbone routers will not accept routers that are having
an RT which isnt configured on the router. So VPNv4 speakers (iBGP PEs) only accept
VPNv4 routes with an RT that is matching a local VRF. If there isnt it wont insert it in
the VPNv4 BGP table. (Its like the VTP pruning)
To disable this default behavior use the cmd no bgp default route-target filter
This cmd is useful when using RRs & Inter-AS ASBRs , as RR doesnt have VRFs
configured on it.

To see the VPN label use the cmd: sh ip bgp vpnv4 all labels | i <ipv4 route >
To see the IGP label use the cmd: sh mpls forwarding-table <ipv4 next-hop ip >
To see the whole label stack use the cmd: sh ip cef vrf ABC <net id> detail

To see the routes installed from a specific VRF/VPN to the BGP VPNv4 use the cmd:
sh ip bgp vpnv4 rd

<RD of the vrf>

OR sh ip bgp vpnv4 vrf <ipv4 route>

VERY IMPORTANT
Config)# mpls ldp session protection
Configure the MPLS nei to adapt & recover quickly, so that if the link between
these neighbors goes down and comes back the LDP session between them
does not need to be reestablished and LDP bindings do not need to be
relearned.

MPLS & IGP

RIPv2
Simplest of all dynamic protocols for PE-CE routing
VRF configuration done under the address family for the VRF (identical to BGP)
Commands applied to the global RIP process can be inherited by the VRFs
version
passive-interface default
But the address family sub config can override it.
MP-BGP carries by default the RIP metric between VPN sites by setting the MED equal
to the RIP hop count to Avoids sub-optional routing and/or routing loops, you can reflect
the BGP MED back to the RIP metric during redistribution using this command.
redistribute bgp <AS #> metric transparent
PE(config)#router rip
PE(config-router)# version 2
PE(config-router)# address-family ipv4 vrf CUST
PE(config-router-af)#network 172.16.0.0
PE(config-router-af)# no auto-summary
PE(config-router-af)# redistribute bgp # metric <#>/<transparent>
(dont use transparent word when using inter-as option 1 VRF-VRF, it doesnt work between ASBRs)

PE(config)#router bgp 1
PE(config-router)#address-family ipv4 vrf VRF-RIP
PE(config-router-af)#redistribute rip

EIGRP
Configuration identical to RIP and BGP for VRFs
The autonomous system number can be manually set using the autonomous-system <as
number> command under the EIGRP VRF routing process
Commonly the same AS number is used between PE-CE routers for same VRF
Internal EIGRP routes from one VPN site will be learned as internal routes in other
VPN sites
External EIGRP routes do not change between VPN sites
Different ASs can be used between the PE-CE routers for same VRF
Internal EIGRP routes from one VPN site will be learned as External EIGRP routes
External EIGRP routes do not change between VPN sites
BGP MEDs and extended communities are used to carry the AS number, route type,
and EIGRP metric values, this automatically done by the PE routers
Sub-optional routing and/or routing loops can occur due to the fact the EIGRP metric is
not altered when sent from PE to PE via MP-BGP To overcome this issue the BGP cost
community is used to compare EIGRP learned routes with MP-iBGP routes based on
their metric and not the AD between iBGP and EIGRP (that happens on the PE for the
vrf table), The BGP cost community is advertised to iBGP and confederation peers
automatically so No configuration is required
EIGRP Site of Origin
Speeds up routing convergence when backdoor links are used along with mutual
redistribution on the PE routers
Prevents EIGRP routes from being learned from one VPN site to a PE, onto another
VPN site , and finally back to another PE
SoO feature must be supported by all PE and CE routers
If the SoO value in an EIGRP update is the same the value configured under for the
VRF site map on the receiving interface the update is dropped
Configuration is applied inbound on the PE routers interfaces and the CE/C routers
backdoor link interfaces

Eigrp Configuration:

PE1-AS1(config)#router eigrp 1
PE1-AS1(config-router)#address-family ipv4 vrf ABC
PE1-AS1(config-router-af)# network 172.16.0.0 < CE-PE Net interface>
PE1-AS1(config-router-af)# no auto-summary
PE1-AS1(config-router-af)# autonomous-system 201 <CE-PE AS>
PE1-AS1(config-router-af)# redistribute bgp 1 metric 1 1 1 1 1
PE1-AS1(config-router-af)# exit-address-family
PE1-AS1(config-router)# end

PE1-AS1(config)#router bgp 1
PE1-AS1(config-router)#address-family ipv4 vrf ABC
PE1-AS1(config-router-af)#redistribute eigrp 201 <CE-PE AS>
PE1-AS1(config-router-af)# End

SOO
interface Ethernet0/0 (backdoor link) OR Int ATM0/1 (PE link)
ip vrf sitemap Soo-B
exit
!
route-map Soo-B permit 10
set extcommunity Soo 3:3
end

OSPF PE-CE Routing

Running OSPF as PE-CE implies redistribution of OSPF and BGP
Traditional OSPF to IPv4 Unicast BGP redistribution does not preserve OSPF route
information
OSPF to MP-BGP redistribution defines preserving OSPF info into 3 BGP extended
Communities.
In the MPLS VPN super backbone, the 3 BGP extended attributes are carried for OSPF:

OSPF Route Type Propagates OSPF route type information across the MPiBGP backbone, including Area ID, LSA types.
OSPF router ID identifies the ospf router ID of the PE in the relevant VRF
instance of OSPF. This address is not part of the provider's address space and is
unique in the OSPF network.
OSPF domain ID identifies the domain of a specific OSPF prefix in the MPLS
VPN backbone. By default, this value is equal to the value of the PE OSPF
process ID and can be overwritten by the cmd domain id <ip-address> under the
OSPF process. If the domain ID of the route does not match the domain ID on the
receiving PE, the route is translated to the external OSPF route (LSA Type 5)
with metric-type E2.

How Domain ID affects the LSA type:

The receiving PE router redistributes the MP-BGP routes back into OSPF, verifies the
domain ID, and if the domain ID of the route matches its domain ID, it uses the original
LSA type and the MED attribute to generate an inter-area summary Type 3 LSA.
It reconstructs the original update and adds the metric of the outgoing interface to the
original metric then propagates the LSA as an inter-area route to the CE.
If the domain ID of the route does not match the domain ID on the receiving PE, the
route is translated as an external OSPF route (LSA Type 5) with metric-type OE2.
Manually configuring the OSPF domain ID changes the behavior of routes for Layer 3
VPNs connecting multiple OSPF domains. Configuring domain IDs helps control LSA
translation (for Type 3 and Type 5 LSAs) between the OSPF domains and backdoor
paths.
The default domain ID is 0.0.0.0. Each VPN routing table on a PE router `associated with
an OSPF routing instance is configured with the same OSPF domain ID.
Domain IDs are, hence, used to identify whether the routes originated from the OSPF
domain or from external routing protocols. The OSPF domain ID helps identify which
OSPF domain a route originated from, which allows classification of routes as Type 3
LSAs or Type 5 LSAs, cuz it is difficult to identify which routes received on CE
originated within OSPF or from external routing domains.
By manually configuring the domain ID to be the same on all PEs for each VRF instance
we can correctly identify which routes are external and which are internal.
Note: By default when redistributing from OSPF to MP-BGP, the external routes wont
be redistributed, only internal routes.
PE(config)#router bgp 1
PE(config-router)#address-family ipv4 vrf Cust
PE(config-router-af)#redistribute ospf 101 vrf Cust match internal external 1 external 2
PE(config)#router ospf 100 vrf Cust
PE(config-router)#router-id <ip address>
PE(config-router)#domain id <ip address>
PE(config-router)#network x.x.x.x 0.0.0.255 area 0
PE(config-router)#redistribute bgp 1 subnets

OSPF Sham Links

Even if domain-ID matches and area is the same on both sides routes are seen as LSA 3
between VPN sites
If a backdoor link running OSPF exists between VPN sites it will always be preferred,
as O is preferred than OIA..ect
This situation can be avoided by using a sham-link. A sham-link is a logical link that
belongs to the area (intra-area) but is carried by the BGP-based superbackbone. The two
PE routers will be the endpoints of the sham-link. They will form an OSPF adjacency
across it and flood intra-area LSAs via this link. The two sites that belong to Area 0 can
have a sham-link between them and then receive intra-area OSPF routes via the backdoor
link or the sham-link. When the sham-link is up, it is regarded as an unnumbered pointto-point OSPF link in the area belonging to the VPN sites. The sham-link is treated as a
demand circuit (DC) by the OSPF in order to reduce the traffic flow over the sham-link.
This implies that the regular LSA will flood over the sham-link but the periodic refresh
traffic is avoided.
OSPF Sham Link can be used as a virtual-link over the MPLS network, Routes learned
via MP-BGP redistribution can be seen as (O) intra-area routes
NOTE: The endpoint address information should not be advertised via OSPF itself. The
loopback interface should not be included in the OSPF 101 VRF process. It would cause
a problem when a backdoor path exists between the two VPN sites. In such a scenario,
the PE router that includes the endpoint address in the OSPF VRF process would
exchange the endpoint address information via OSPF to the CE routers in LSA Type 1 or
2. The LSA would then propagate to the other side of PE router over the backdoor path.
Although the other side of the PE would also receive the endpoint address information
via MP-BGP, it will prefer the OSPF route rather than the BGP-learned route because of
the administrative distance value. The sham-link will fail to be up because the endpoint
address information is not learned via BGP.
Configuring Sham Links
Create a new interface in the VRF on the PE, advertising it into MP-BGP.
interface Loopback1
ip vrf forwarding VPN_A
ip address 10.1.3.3 255.255.255.255
router bgp 100
address-family ipv4 vrf VPN_A
network <loopback> mask 255.255.255.255 / Redistribute connected
router ospf 1 vrf VPN_A
area 0 sham-link <source ip> <destination ip>
# sh ip ospf sham-links
# sh ip ospf nei / sh ip ospf / sh ip ospf int ( verify auth , ispf, timers, network type)

OSPF MPLS VPN looping free (backdoor link exist)

Routing loops can accrue when having a backdoor link/Dual homed in an OSPF site, the
routes that was redistributed from MBGP to OSPF can go across the site, and get back to
the MPLS VPN.
ospf use the Down Bit & Domain Tag to avoid having loops.
Down bit:
1. CE sends a Type 1 router or Type 2 network LSA to the Local PE.
2. The PE router receives OSPF route from CE and redistributes it into MP-BGP.
3. The receiving Remote PE router redistributes the MP-BGP route back into
OSPF as an inter-area summary route, LSA Type 3, with the OSPF down bit
set.
4. The summary route with the down bit set is propagated across backdoor link/Dual
homed in the OSPF site, and received by a third PE.
5. When the third PE router receives the summary LSA with the down bit set, it
does not redistribute the route back into MP-BGP.
Domain Tag:
The down bit helps prevent routing loops between MP-BGP and OSPF, but not when
external routes are announced, As LSA Type 5 does not support the down bit, so if the
OSPF route is being redistributed into the MPLS network as LSA-type5 it will be
redistributed back without the down-bit set, which may cause routing loops for backdoor
link/Dual homed OSPF sites.
The routing loops introduced by route redistribution between OSPF domains can be
solved with the help of the tag field, using standard BGP-OSPF redistribution rules.
A non-OSPF route is redistributed as an external OSPF route by a PE router. By default,
the tag field is set to the BGP-AS number. The redistributed route is propagated across
the OSPF domain without the down bit but with the tag field set. When the route is
redistributed into another OSPF domain, the tag field is also propagated. Another PE
router receives the external OSPF route and filters the route based on the tag field. The
tag field matches the AS number so the route is not redistributed into MP-BGP.

vrf lite is a vrf configured on the CE , without RT ( ip vrf name RD + ip vrf forwarding
cmd under the interface)
# sh ip route vrf * ( show all routing tables including the global one)
For EIGRP I must specify the AS for each VRF inside the address family.
# sh ip bgp vpnv4 all sum ( show all nei including VRF nei)
# sh ip bgp vpnv4 all <NET ID> ( show all entries in all VRFs for this network )
# sh ip bgp vpnv4 RD <RD> ( show entries of BGP table for a specific RD, which is a specific VRF )
# sh ip bgp vpnv4 vrf <VRF>( show entries of BGP table for a specific VRF )
# sh ip bgp vpnv4 vrf <VRF> labels ( show BGP VPN LABEL for a specific VRF )

If you removed the global EIGRP process, all VRFs will be deleted.
If you removed the VRF, it will remove all the VRF config on all interfaces & routing.

ISIS
On Cisco routers, the System ID of the NET must be six octets.
While the type of router (L1-only, L2-only, or L1/L2) influences the type of adjacency
that is formed, so do the area IDs configured on the two neighbors in question. The
following rules apply:
Two L1-only routers form an L1 adjacency only if their AIDs match.
Two L2-only routers form an L2 adjacency, even if their AIDs are different.
An L1-only router forms an L1 adjacency with an L1/L2 router only if their AIDs match.
An L2-only router forms an L2 adjacency with an L1/L2 router even if their AIDs are
different.
Two L1/L2 routers form both L1 and L2 adjacencies if their AIDs match.
Two L1/L2 routers form only an L2 adjacency if their AIDs do not match.
Designated Routers only for BC networks (no DIS/DR in point-to-point)

The IS-IS Designated Router election process is quite simple. Every IS-IS router
interface is assigned both an L1 priority and an L2 priority
in the range of 0 to 127. Cisco router interfaces have a default priority of 64 for both
levels, and this value can be changed with the
command isis priority.
The router advertises its priority in the Hellos sent from each interface the L1 priority is
advertised in L1 Hellos, and the L2 priority is
advertised in L2 Hellos. Unlike OSPF, in which a priority of 0 makes the router
ineligible to become the DR, an IS-IS router with a priority of 0 is merely the lowest
priority, but can still become the DR.
Interfaces to nonbroadcast networks, on which a DR is not elected, always
have a priority of 0 (notice the priority of the serial interface in Example 10-1). The
router with the highest priority becomes the DR. In a tie,
the router whose attached interface has the numerically highest MAC address becomes
the DR.
If the IS-IS DR fails, a new DR is elected. Second, the IS-IS DR is not as stable as the
OSPF DR. If an OSPF router becomes active on a network with an existing DR, the new
router will not become the DR even if its priority
or Router ID is higher. As a result, the OSPF DR usually is the router that has been active
on the network for the longest time. In contrast
to the OSPF rules, a new IS-IS router with a higher priority than the existing DR, or an
equal priority and a higher MAC address, will become the new DR. Each time the DR is
changed, a new set of LSPs must be flooded.
However, given that adding a new router to a broadcast link is a relatively uncommon
occurrence in the operational day of a network, and that DR election happens very
quickly in modern routers on the order of microseconds the lack of a BDR and the fact
that a DR can be preempted should not be a cause for concern.

ISIS-configuration
Conf t
Router isis
net 47.0001.0000.0000.0001.00 (Area.systemID.00)
metric-style wide ( if enabled, must be on all isis routers, used with redistribution & MPSL TE)
is-type <level-1 | level-2-only | level-1-2> (default L1-L2)
domain password <> (authenticate all level 2LSPs with the clear-text password)
passive-interface loopback0 (Advertise interface without using ip router isis + making it passive)
(you must type the whole word loopback0, if used loop0 it wont work with ISIS)

redistribute isis ip level-2 into level-1 <distribute-list 100>

by default L1-2 routers send a default route to L1 routers, If we need the full routing/explicit/exact match
+ default route to be sent to/appear inside the L1 routers we can make redistribution inside ISIS)

distance 19 ip (set AD to be lower than ebgp, remember the word ip)

no hello padding (By default the IS-IS Hello PDUs are padded to the full MTU size, possibly having
a negative impact on time-sensitive traffic that travels across low-bandwidth interfaces or on interface
Memory buffer resources, also used for faster convergence)
ispf <level-1/level-2/level-1-2> <sec> ( Re-computing only a portion of the tree rather than the entire
tree results in OSPF/ISIS faster convergence and saves CPU resources. Note that if the change to a Type
1 or Type 2 LSA occurs in the calculating router itself, then the full SPT is performed.

interface <>
ip router isis #
isis priority # <level-1 | level-2>
isis circuit-type <level-1 | level-2-only | level-1-2>
frame-relay map clns <local DLCI> broadcast (NBMA FR)
protocol clns_is broadcast (NBMA ATM)
isis network point-to-point (disable the DR/DIS existing, Reducing Failure Detection Times/fast
convergence & prevents flooding from using CSNPs on fast Ethernet by default its BC network with DIS Election)
no isis hello padding
isis metric <#> (adds metric value to all incoming routes, NOT outgoing)
no isis csnp-interval <level-1/level-2> ( valid for BC networks only, )
isis hello-interval <# > <level-1 | level-2> ( default is 10)
isis hello-multiplier <#> (sets the hold-down timer default is 3 , 10 x 3 = 30 sec )
isis hello-interval minimal <level-1 | level-2> (results the hold time to be 1 sec, so hells are sent in
milliseconds, number of hellos per second is the configured by the command hello-multiplier, Reducing
Failure Detection Times/fast convergence)

sh isis nei
sh clns int (sh specific config . like padding)
debug isis adj-packet
sh clns is-nei
show isis database detail
show isis topology,
ISIS authentication:
key chain ISIS
key 1
key-string CISCO
!
interface <>

isis authentication mode md5

isis authentication key-chain ISIS
OR
router isis

authentication mode <md5/txt> <level-1/-2>

authentication key-chain <key-chain> <level-1/-2>

ISIS redistribution from level-2 into level-1 & filtering the default route
Router isis
Net 47.0009.0000.0000.000x.00
Redistribute isis ip level-2 into level-1 distribute 101
Set attached-bit route-map NO-Default
exit
!
Route-map NO-Default permit 10
Match clns address NO-Default
Exit
!
Clns filter-set NO-Default deny 47.3009 (47.3009 is the level-2 process)
!
access-list 101 permit ip any any (default will appear @ nei, must use clns filter)
access-list permit ip host x.x.x.x host y.y.y.y ( y.y.y.y is subnet mask, default will appear @ nei,
must use clns filter)

no isis csnp-interval 10 <level-1/level-2>

This command applies only for the designated router (DR) for a specified interface. Only DRs send CSNP
packets in order to maintain database synchronization. The CSNP interval can be configured independently
for Level 1 and Level 2. Configuring the CSNP interval does not apply to serial point-to-point interfaces. It
does apply to WAN connections if the WAN is viewed as a multiaccess meshed network.

BGP
PE-CE
PE1-AS1(config)#router bgp 1
PE1-AS1(config-router)#address-family ipv4 vrf Cust_B
PE1-AS1(config-router-af)#neighbor 192.168.1.2 remote-as 65001
PE1-AS1(config-router-af)#neighbor 192.168.1.2 as-override
PE1-AS1(config-router-af)#neighbor 192.168.1.2 activate

PE-PE

(ipv4 & vpnv4)

PE1-AS1(config)#router bgp 1
PE1-AS1(config-router)# neighbor 2.2.2.2 remote-as 1
PE1-AS1(config-router)# neighbor 2.2.2.2 update-source loopback0
PE1-AS1(config-router)#address-family vpnv4
PE1-AS1(config-router-af)#neighbor 2.2.2.2 activate
PE1-AS1(config-router-af)# neighbor 2.2.2.2 send-community extend
PE1-AS1(config-router-af)# neighbor 2.2.2.2 next-hop-self

PE RR

(VPNv4 only )

Routing information for address family IPv4 is advertised by default when you
configure a BGP routing session using the neighbor remote-as command unless you
execute the no bgp default ipv4-unicast command.
PE side
PE1-AS1(config)#router bgp 1
PE1-AS1(config-router)#no bgp default ipv4-unicast
PE1-AS1(config-router)# neighbor 2.2.2.2 remote-as 1
PE1-AS1(config-router)# neighbor 2.2.2.2 update-source loopback0
OR
PE1-AS1(config-router)# address-family ipv4
PE1-AS1(config-router-af)#no neighbor 1.1.1.1 activate

PE1-AS1(config-router)#address-family vpnv4
PE1-AS1(config-router-af)#neighbor 2.2.2.2 activate
PE1-AS1(config-router-af)# neighbor 2.2.2.2 send-community extend
PE1-AS1(config-router-af)# neighbor 2.2.2.2 next-hop-self

RR side
RR -AS1(config)#router bgp 1
RR-AS1(config-router)#no bgp default ipv4-unicast
RR -AS1(config-router)# no bgp default route-target filter
OR
RR-AS1(config-router)# address-family ipv4
RR1-AS1(config-router-af)#no neighbor 1.1.1.1 activate
RR -AS1(config-router)# neighbor 1.1.1.1 remote-as 1
RR -AS1(config-router)# neighbor 1.1.1.1 update-source loopback0
RR -AS1(config-router)#address-family vpnv4
RR -AS1(config-router-af)#neighbor 1.1.1.1 activate
RR -AS1(config-router-af)# neighbor 1.1.1.1 send-community extend
RR -AS1(config-router-af)# neighbor 1.1.1.1 next-hop-self (take effect on only the
Ebgp routes, ibgp client routes next-hop never change )
RR -AS1(config-router-af)# neighbor 1.1.1.1 route-reflector-client (remember)

Partitioned RR
1-Standared community filters
The disadvantage with outbound filters is that the service providers may incur additional
operational burden due to constant maintenance required for these filters on all PE
routers, so it really doesnt scale well.
PE1-AS1(config)# ip bgp-community new-format
RR -AS1(config)#router bgp 1
PE1-AS1(config-router)#address-family vpnv4
PE1-AS1(config-router-af)# neighbor 2.2.2.2 send-community both
PE1-AS1(config-router-af)# neighbor 2.2.2.2 route-map VPN-Comm out
Exit
route-map VPN-Comm permit
set community x:y
RR -AS1(config)# ip bgp-community new-format
RR -AS1(config)# ip community-list 101 permit x:y
!
RR -AS1(config)#router bgp 1
RR -AS1(config-router)#address-family vpnv4
RR-AS1(config-router)#nei 2.2.2.2 route-map VPN in
exit
!
RR -AS1(config)#rout-map VPN permit
RR -AS1(config)#match community 101

2-BGP RR groups (using extended community)

Configure the inbound route-target filter on the BGP RR by using the bgp rr-group
command. This command performs the same function as a route-map. However, it is
configured under the BGP routing process and applies to all BGP neighbors. Also,
another important operational detail is that the extended community access-list
maintained on the RR can be downloaded as an outbound filter to the PE routers through
the ORF functionality.
The route-map based input filter cannot be downloaded via ORF functionality.
RR -AS1(config)# ip extcommunity-list VPN permit rt x:y
!
RR -AS1(config)#router bgp 1
RR-AS1(config-router)#bgp rr-group VPN

Peer Groups
router bgp 1
neighbor group1 peer-group
neighbor group1 remote-as 1
neighbor group1 update-source Loopback0
!
neighbor 10.10.10.101 peer-group group1
neighbor 10.10.10.102 peer-group group1
!
!
address-family vpnv4
neighbor group1 activate
neighbor group1 send-community extended
neighbor group1 next-hop-self
neighbor group1 route-reflector-client >>>>>>> IF needed RR
neighbor 10.10.10.101 peer-group group1
neighbor 10.10.10.102 peer-group group1
neighbor 10.10.10.101 activate ( You MUST ACTIVATE PEERS UNDER VPNV4)
neighbor 10.10.10.102 activate

Confederation
(Remember ebgp-multihop for EBGP confederation nei)
PE1-AS1(config)#router bgp 101
PE1-AS1(config-router)# bgp confederation identifier 1 (real AS number)
PE1-AS1(config-router)# bgp confederation peers 100 102 (Ebgp nei)

BGP SoO ( MUST USE WITH DUAL HOMED)

Basic theory similar to EIGRP SoO
Used to prevent routing loops when dual homed PE to CE routing is being
used along with the as-override feature
BGP SoO is also useful when the as-override or allowas-in options are
being used which means that the as-path loop prevention may not be reliable
If a VPNv4 route is received with the same SoO value used for the PE-CE
peering, the route will not be installed into the VRF routing table or
advertised to the CE, it will just appear in the bgp vpn vrf table.

BGP SoO Configuration

router bgp 200
address-family ipv4 vrf B
neighbor 10.1.37.7 remote-as 100
neighbor 10.1.37.7 route-map SOO-MAP in
!
route-map SOO-MAP permit 10
set extcommunity soo 36:36
OR

Int s0/0
Ip vrf site-map SOO-MAP
NOTE: to insure that connection will be always up if one of the dual-homed links
went down choose one of the following options:
1- Enable iBGP between the dual homed CEs
2- Redistribute BGP inside the IGP used between the CEs

router bgp 100

bgp redistribute internal (allow the redistribution from iBGP into IGP, when Im doing redistribution
from BGP into IGP only the eBGP routes are redistributed by default)

sh ip bgp vpn all summary

Analogous to sh ip bgp summary; lists all of the MP-BGP and CE peers.
sh ip bgp vpn all
Lists all of the VPN prefixes advertised and received by the router.
sh ip bgp vpn vrf <vrf> summary
Similar to the first command, but for a specific VRF.
sh ip bgp vpn vrf <vrf>
Lists all of the VPN prefixes received in a specific VRF.
sh ip bgp vpn vrf <vrf> labels
Lists labels for the VPN prefixes in a VRF.
sh mpls forwarding
Shows all LFIB entries (VPN, non-VPN, TE, and so on).
sh mpls forwarding | inc <prefix>
Shows whether the prefix is present in the LFIB or not.
sh mpls forwarding vrf <vrf> <prefix>
Shows LFIB lookup based on a VPN prefix.
sh mpls forwarding label <label>
Shows LFIB lookup based on an incoming label

MPLS TE
MPLS TE is using RSVP
Constrained-Based Shortest Path First (CSPF)
Bandwidth
Affinity
Administrative weight
Explicitly defined path
Path calculation can also be done offline
Traffic Engineering and IGP
TE uses existing link-state routing protocols, OSPF and ISIS, to disseminate the
topology Information
OSPF uses Type 10 (area-local) Opaque LSAs (TLV)
ISIS uses new TLVs
Normally IGP carries the information about itself, neighbors, and cost to the neighbors
TE adds information regarding available bandwidth to the neighbors
show mpls traffic-eng topology
IS-IS scales better with TE, as OSPF restricts that TE must be inside 1 area only, no
inter-area TE.(based on Cisco supporting only intra-area TLV)
CSPF Path Options
Dynamic (will mainly choose the best IGP path)
The router will calculate the best path for the tunnel.
Uses the configured constraints such and bandwidth and other attributes
Explicit (commonly used)
User defined path for the tunnel
Uses the configured constraints such and bandwidth and other attributes
More than one path option can be configured for a tunnel.
Dynamic and Explicit can be used for the same tunnel.
TE tunnels are unidirectional
Routing Across the TE Tunnel
Static routing
Policy based routing
Dynamic routing protocol (autoroute announce)

Configuration Steps for All Routers, Order of operation is important in MPLS TE

1-Ensure CEF is enabled on all routers.
Config)#ip cef
2-Enable TE support for the IGP protocol being used on all routers. (For TE TLV ext)
Config)# router OSPF 10
Config-router)#mpls traffic-eng area <area-id>
Config-router)#mpls traffic-eng router-id <router-id>
Config)# router isis
Config-router)#metric-style wide {level-1 | level-2}
Config-router)# mpls traffic-eng {level-1 | level-2}
Config-router)#mpls traffic-eng router-id <router-id>
3-Enable MPLS TE Tunnels on all routers in the path. (For TE support)
Config)#mpls traffic-eng tunnels
4-Enable MPLS TE Tunnels & RSVP on all interface in the path. (For RSVP activation)
Config-if)#mpls traffic-eng tunnels
Config-if)#ip rsvp bandwidth <total kbps> <per-flow kbps>
5- Configure the Tunnel Interface on the Head-End

NOTES:
If the ip rsvp bandwidth command is entered without specifying an amount, the
available bandwidth will be 75% of the interface's bandwidth, The Note that the
bandwidth could be different in each direction of the TE tunnel
If the ip rsvp bandwidth command is not configured for the reservable bandwidth is
set to 0 although TE signaling will still occur on the interface, so no traffic will pass
through.

debug ip r svp dump-messages

Config)#Mpls traffic-eng link-management timers periodic-flooding <sec>

For periodic flooding for LSAs, default is 3 min, 30 min in ospf , 15 min is ISIS

Periodic Reoptimization
In Cisco IOS, the reoptimization of a TE tunnel occurs with a frequency of one hour, by default.
You can change this with the command mpls tr affic-eng r eoptimize timer s fr equency interval.
The interval that you can specify needs to be between 0 and 604,800 seconds (168 hours, or 7
days). The default value is 1 hour. If you specify 0 for the interval, the periodic reoptimization is
turned off globally on the router for all TE tunnels. You can turn off the reoptimization check for
an individual TE tunnel by specifying the lockdown keyword on the path-option command.
tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name | path-number}}
[lockdown]
Event-Driven Reoptimization
By default, Cisco IOS does not trigger reoptimization when a link in the network is available to
TE again, either by configuration or because its state becomes operational. To enable the
reoptimization when a link becomes operational for MPLS TE, configure the following command:
mpls tr affic-eng r eoptimize events link-up
Manual Reoptimization
To force the immediate reoptimization of all the TE tunnels on the head end router, you must type
the mpls tr affic-eng r eoptimize command at the router prompt. You can specify a specific TE
tunnel number to reoptimize only a specific tunnel with the command :
mpls tr affic-eng r eoptimize tunnel tunnel-number

TE configuration Templates
On all routers (Head-tail-Mid)
ip cef
mpls traffic-eng tunnels
mpls traffic-eng logging lsp <setup/teardown> (optional to log TE LSP status)
!
router ospf x
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
!
interface <x/y> (on all interfaces)
mpls traffic-eng tunnels
ip rsvp bandwidth <> <>
On Head router
interface Tunnel0
ip unnumbered Loopback0 (source)
tunnel destination 150.1.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth < required tunnel bandwidth>
tunnel mpls traffic-eng priority <setup-priority> <hold-priority> (the lower the better)
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng record-route
tunnel mpls traffic-eng path-option x dynamic
tunnel mpls traffic-eng path-option y explicit <name pathname| id path-number><lock>
tunnel mpls traffic-eng path-selection metric < te/igp> (by default its te )
(use igp when MPLS TE carries data traffic with no delay requirement, if needed Delay requirements for
traffic such as VOIP use te which is the default, to manipulate the dynamic path selection play with
the admin weight delay under the interfaces.)
interface pos0/1
mpls traffic-eng administrative-weight 15

(TE metric different from IGP metric)

tunnel mpls traffic-eng fast-reroute <node>

mpls ip (only of the Tail is a P router + @ P mpls ldp discovery targeted-hello accept )
exit
ip explicit-path name <name>| identifier <ID> [{enable | disable}]
next-address Specify the next (adjacent) address in the path, the destination must be at
hard coded at the end of the list
append-after Append additional entry after specified index
exclude-address Exclude an address (you may exclude a router if u exclude its TE RID)

index Specify the next entry index to add, edit (or delete)
list Re-list all or part of the explicit path entries
check MPLS Fundamentals for more details
Fast Reroute FRR
Use the cmd tunnel mpls traffic-eng fast-reroute on the Head end and on the PLR
create the backup tunnel, and configure the Primary PLR physical interface with the cmd:
mpls traffic-eng backup-path Tunnel 0
Regular tr affic should not use the backup tunnel. Ther efor e, the backup tunnel should not have
autor oute announce or for war ding adj acency configur ed.

Fast Reroute FRR Node:

Node protection works by creating a next-next-hop (NNHOP) backup tunnel.
An NNHOP backup tunnel is not a tunnel to the next-hop router of the PLR, but to the router that is one
hop behind the protected router.
Therefore, in the case of node protection, the NNHOP router is the MP router. You configure the cmd on
the head end of the TE tunnel,
tunnel mpls tr affic-eng fast-r er oute node-pr otect
This backup tunnel avoids router Y altogether by specifying the router Y in the explicit path as excluded.
This is done by specifying the MPLS TE router ID of router Y as an excluded IP address in the explicit
path.

Int pos0/0/0
mpls traffic-eng backup-path Tunnel2000
!
Int tunnel9999
mpls traffic-eng path-option 1 explicit name <EXCLUDE>
exit
ip explicit-path name <EXCULDE> enable
exclude-address 10.200.254.5
Note: you can use TE Tunnels to distribute labels rather than LDP between peers, but
thats not used a lot.you may have a whole backbone running TE tunnels for label
distribution rather than LDP
show mpls traffic-eng tunnels brief
#show mpls traffic-eng tunnels destination <ip>
#show mpls traffic-eng tunnels tunnel <#>
#show mpls traffic-eng tunnels fast-reroute database
#

#show mpls traffic-eng topology

#show ip explicit paths
To confirm your configuration, do a normal ICMP extended ping with the record
option.

Notes2:
Constraint-based SPF can use either administrative weights or IGP metric (also called TE
metric) during the constraint-based computation. In the event of a tie, the path with the
highest minimum bandwidth takes precedence, followed by the least number of hops
along the path. If all else is equal, CSPF picks a path at random and chooses the same to
be the TE LSP path of preference.
To have a load balance between tunnels, They must have same source & destination,
and also same BW; if BW isnt equal they will have load sharing inversely proportional
to their BW.
Notes 3
CSCsh42565 Bug Details
TE tunnel does not come up on ospf non-broadcast network type
Symptoms: Traffic engineering (TE) tunnels go down when an intermediate
link has the ip ospf network non-broadcast command enabled.
Conditions: This symptom is observed in an OSPF network over TE tunnels
that are established on non-broadcast links.
My Workaround: Do not use non-broadcast links. Rather, use another OSPF network
type. If this is not an option, there is no workaround.
NO the workaround is ip ospf network point-to-multipoint non-broadcast
Notes 4: TE and Multicast

Multicast packets are not sent over TE tunnels, but over the underlying physical
infrastructure. This can cause problems with multicast's Reverse-Path Forwarding (RPF)
lookup when autoroute is enabled,
The problem with this and TE, though, is that if you enable autoroute, your routing table
points to a bunch of routes out a TE tunnel, but packets never come in on TE tunnels!
Multicast breaks! Bad!
You may use Static mroute to override this RPF-failure, or use the cms under ISIS-OSPF
Rouetr isis/opsf 10
mpls traffic-eng multicast-intact

INTERNET VPN
Option 1: VRF Internet
Similar to previous Central Services MPLS VPNs
BGP peering with Internet peers is configured inside a VRF (i.e. INTERNET)
INTERNET export route target will be import route target into all VRFs that want
Internet routes
Other VRF routes must be imported into INTERNET or combined with NAT
So its just advertizing the 0.0.0.0 route from the Internet VRF, and let it be imported by
all other VPNs that need internet. (export-map with prefix-list to set export RT)

Option 2a: Static leaking to Global Table

VRF static routes are assumed to recurs to interfaces or next hops within that VRF
global option at the end of ip route vrf allows VRF lookup to occur in global table
Simple way to insert default route from the Internet into a VRF.
This static vrf route to global must be configured on all VRF PEs in the MPLS VPN
Global table still needs a route back to VRF using static routes or NAT

Option 2b separate interfaces

1 link for VRF connection.
1 link for internet (using IGP)
The routes for customer will be configured in the global PE table for returning traffic.
Global table of the backbone still needs a route back to the customer via the 2nd link this
can be done using static routes, this solution isnt scalable.

Option 3: VRF Aware NAT

VRF aware NAT allows CE traffic to be translated to global SP address space.
must use route-map with ACL, dont use prefix-list as it didnt ever work
This solution is not documented
ip nat pool PUBLIC_ADDRESSES 1.1.1.1 1.1.1.254 prefix-length 24

ip nat inside source route-map ABC interface E0/0

add-route

vrf VPN_A overload

add-route is used to automatically add a static route to the

RIB, used in the exam if advised not to use any static routes.
Option 3a: NAT at Local PE
Each PE NATs CE to separate global NAT pool.
Option 3b: NAT at Central PE
One central PE NATs multiple VRFs to single global NAT pool

RT Rewrite
When two service providers perform Inter-Autonomous MPLS VPN, they need to synchronize
and agree on the RTs that are used on the vpnv4 routes they exchange. This can be tedious,
especially if one or both parties need to change the RTs used in their network. The RT Rewrite
feature is a nice workaround to the problem because the RT is simply replaced on the ASBR router.
As such, each service provider can keep its own policy regarding the RT assignment.
The service provider needs to configure a route map toward the other service provider. This route map
allows deletion of the RT and replacement with a new one. RT rewrite is supported both in the inbound
and outbound directions. Therefore, you can use an inbound or an outbound route map to replace
the RT. The set extcomm-list extended-community-list-number delete command and the set
extcommunity r t extended-community-value [additive] command replace the RT

hostname sydney-as-1
!
router bgp 1
!
address-family vpnv4
neighbor 10.10.4.2 activate
neighbor 10.10.4.2 send-community both
neighbor 10.10.4.2 route-map to-as-2 out
neighbor 10.200.254.3 activate
neighbor 10.200.254.3 send-community both
exit-address-family
!
!
ip extcommunity-list 2 permit rt 1:1
!
route-map to-as-2 permit 10
match extcommunity 2
set extcomm-list 2 delete
set extcommunity rt 2:1 additive

Thanks & B.regards

Ahmed Elhoussiny,2x CCIE# 21988 (R&S-SP)
Network Consultant & Cisco Academy Instructor