CCIE-SP

INE Vol 1 multicast - Lab 3 - Multicast RPF Failure (3rd Pass)

2010-10-28T15:41:00.000-07:00

So this lab deals with Multicast with broken uRPF due to PIM no being enabled on preferred route/link.

The best way to determine where the problem is, is to use "no ip mroute-cache" on the the PIM enabled interfaces and to "debug ip mpacket". Of course, you'll want to log this to the buffer and not the console.

Doing this at each step of the way, you'll find that R4 is preferring a NON-PIM link to get back to the source.

*Oct 28 18:38:27.499: IP(0): s=10.1.37.7 (FastEthernet2/0) d=224.1.1.1 id=133, ttl=251, prot=1, len=114(100), not RPF interface

This should be an indication that path isn't taking the correct interface back to the source. A static mroute fixes this issue.

INE Vol 1 - Lab 26 - Multicast over MPLS VPNs (3rd pass) - BGP MDT SAFI!!!

2010-10-25T15:29:00.000-07:00

For the IOS I'm using for my lab 12.4(20)T, it's necessary to configure BGP address-family MDT for the MDT tunnel to come up.

Otherwise everything else in this lab is straight forward. Configure Multicast throughout the SP and Enterprise devices, enable Multicast on the PE's for the specific VPN and if using static RPs remember to configure the RP address in the VRF on the PEs.

INE Vol 1 - Lab 22 MPLS TE - Dynamic PE to PE tunnels (3rd Pass)

2010-10-23T11:39:00.000-07:00

In this lab, it states that you should enable mpls ip on the links but in reality you don't have to since RSVP will take care of the IGP labeling for the BGP next hop and VPNv4 BGP takes care of the Customer prefixes. I did this lab without enable ldp/tdp and it worked as expected.

Just as a review, there are 5 major steps.

Step 1: Enable MPLS traffic-eng tunnels globally

Step 2: Enable MPLS traffic-eng tunnels in the IGP

OSPF - mpls traffic-eng area 0 & mpls traffic-eng router l 0

ISIS - metric-style wide, mpls traffic-eng [level1 | level 2], mpls traffic-eng router l 0

Step 3: Enable MPLS traffic-eng on the interface as well as IP RSVP on the interface

Step 4: Create a tunnel interface and configure as an mpls traffic-eng tunn

Step 5: Ensure that the tunnel is taken for some/all traffic, autoroute announce, static routing, pbr, etc.

INE Vol 1 - Lab 21 - Controlling MPLS Label Distribution (3rd Pass)

2010-10-23T11:01:00.000-07:00

Don't forget when restricting label advertisements using "mpls ldp advertise-label for X to Y" that you need to disable mpls ldp advertise-labels for ALL labels which is on be default and won't show up in the config.

Use:

no mpls ldp advertise-labels

mpls advertise-labels for X to Y

INE Vol 1 - Lab 20 - VRF Lite (twist)

2010-10-21T16:51:00.000-07:00

I redid this lab again and this time I introduced my own twist. Instead of running a dynamic routing protocol between the VRF lite router and the PE, try using static routes and then try using static default routes. Turns out it's a fun redistribution exercise.

** Also be aware that for sub-interfaces on a serial link wasn't working correctly for me but once I used 2 physical serial interfaces instead of 1 with 2 subs, everything came up correctly.

INE Vol 1 - Lab 16 - Inter-AS MPLS VPNs with Multihop MP-eBGP for VPNv4 Exchange (3rd Pass)

2010-10-19T16:35:00.000-07:00

This time around, I forgot I needed to redistribute from IPv4 Unicast BGP into IGP. This is required because when the VPNv4 BGP peers recurse to IGP (putting the IGP label on top of the VPN label), it has to know of the loopback in IGP. Even if it knows it by IPv4 BGP, that's not an IGP so it still won't work (meaning you may see the routes appear on the CEs but pings will fail, because the labeling is failing).

Other things to note, MP-eBGP multi hop and IPv4 Send-label are required.

IPv4 BGP Send-label to get labels across the Inter AS connection.

INE Vol 1 - Lab 15 - Inter-AS w/ MP-eBGP (3rd Pass)

2010-10-19T05:21:00.000-07:00

Redoing this lab was good. Caught some silly mistake be trouble shooting.

1. Ensuring the control plane, ie. the BGP VPNv4 tables, look good, meaning you're receiving BGP routes. If you're not, then check to make sure you have next-hop-self enabled where appropriate and that you are not filtering route-targets by default on certain BGP-ASBR routers

2. Once the routes appear on the CEs, ping, if ping fails, then check step by step LDP and make sure labels are assigned for the destinations. A common mistake, if you have a loopback configured but not in IGP then you're LDP peering won't come up since it'll use the loopback as it's ID but the peers won't have reachability to it (unless you put it in IGP).

INE Vol 1 - Lab 14 - Inter AS Back to Back VRFs

2010-10-18T16:53:00.000-07:00

Re-doing this lab, I used different RDs and Route-Targets in the 2 different ASes and I wasn't able to get connectivity. My thoughts were that the ASes were independent of each other being that they are doing the PE-CE transition into IP routing to exchange routes.

When I reconfigured the VRFs to be uniform through out the 2 the ASes, everything worked.

OL - MPLS Label filtering

2010-09-07T08:08:00.000-07:00

Notes:

Atleast 2 ways to accomplish label filtering, meaning appending label to prefix. Outbound filtering and Inbound filtering.

Configs:

Outbound Filtering

no mpls ldp advertise-labels

mpls ldp advertise-labels for 51 to 50

Access List 51 is ACL for the prefixes and ACL 50 is the ACL for the LDP neighbor

Inbound Filtering

mpls ldp neighbor 1.1.1.1 labels accept 99

Access List 99 is the ACL for the prefixes

OL - L2TPv3

2010-09-02T13:37:00.001-07:00

Notes:

The difference between AToM and L2TP is that AToM is over an MPLS network whereas L2TP is over straight IP.

The concepts are very similar. The CE facing interfaces on the PEs need to create a VC across IP (for L2TP or MPLS for AToM). This requires pseudowires to make that connection.

With both AToM, the use of LDP neighbor/peer of the remote PE is used but in L2TP, under the pseudowire-class, you need to define a ip local inteface loop 0. And then use the peer's loopback as the xconnect's peer.

Config:

R3 - PE

l2tp-class L2TP

authentication

password 7 047822352C0E

pseudowire-class L2TP

encapsulation l2tpv3

protocol l2tpv3 L2TP

ip local interface Loopback0

interface FastEthernet1/1

no ip address

duplex auto

speed auto

no cdp enable

no clns route-cache

xconnect 4.4.4.4 12 pw-class L2TP

OL - ATOM

2010-09-02T08:08:00.000-07:00

Notes:

I've created my own lab to test out the different types of Layer 2 protocols I can transport over MPLS.

There are, at a basic level, 2 parts to enabling AToM. First, create a pseudowire-class and second, create the VC via an xconnect statement under the CE facing interface on the PE.

Of course, the prerequisite for this to work is that MPLS is enabled throughout the core network.

Also, note that to make life easier use 'mpls ldp router-id loop 0 force'. You have to designate the other PE as peer in xconnect which will be the ldp router id.

Layer 2 protocols that can be transported are EoMPLS, FRoMPLS, PPPoMPLS, HDLCoMPLS, and ATMoMPLS (can't emulate in dynamips, as the PA-A1 doesn't support it).

Config:

R3 - PE

mpls ldp router-id Loopback0 force

mpls label protocol ldp

pseudowire-class EOMPLS

encapsulation mpls

interface Loopback0

ip address 3.3.3.3 255.255.255.255

no clns route-cache

interface FastEthernet1/0

ip address 150.1.35.3 255.255.255.0

duplex auto

speed auto

mpls ip

no clns route-cache

interface FastEthernet1/1.100

description EoMPLS

encapsulation dot1Q 100

no cdp enable

xconnect 4.4.4.4 100 pw-class EOMPLS

interface Serial2/0

description HDLCoMPLS

no ip address

serial restart-delay 0

no cdp enable

no clns route-cache

xconnect 4.4.4.4 67 pw-class EOMPLS

interface Serial2/1

description FRoMPLS

no ip address

serial restart-delay 0

no cdp enable

no clns route-cache

xconnect 4.4.4.4 607 pw-class EOMPLS

interface FastEthernet3/0

ip address 150.1.34.3 255.255.255.0

shutdown

duplex auto

speed auto

mpls ip

no clns route-cache

CE config

The CE's are generally configured like back to back CE to CE connections with nothing but a pseudo wire connecting the two. * Remember for FRoMPLS though, you'll want once side to act as Frame switch and that interface to be DCE.

OL - ISIS

2010-08-26T15:39:00.000-07:00

Notes:

I've been working through ISIS since I'm not very familiar with it. ISIS by default creates Level 1 (intra area) and Level 2 (inter area) adjacencies with other ISIS routers. You can limit the type on a per interface level ['isis circuit-type'] or on a per process level ['is-type']. Same with authentication, you can do on s per link or on a per process level and authentication supports clear text as well as MD5 hash.

Level 2 is considered the 'backbone' area as all other level1 router need to connect and transit a level 2 area to get to another level 1 router. Level 1-2 routers automatically redistribute level1 prefixes into level 2. In order to redistribute Level 2 into Level 1 you need to configure 'redistribute isis ip level-2 into level-1 route-map/distribute-list'. The route-map doesn't need to contain any entries, it just needs to exist.

Default-information originate by default will originate only a L2 default, in order to generate and L1 default create a route-map, set level level-1 and then append the route map to the default-information originate.

Metrics, without metric-style wide configured, isis defaults to max metric of 63, enabling wide metrics lets you go far beyond that. The default metric of any interface is 10 and can be changed.

Priority, the default priority is 64 with the max being 127. Priority is used to determine who will be the DIS on a multi access segment like ethernet.

Summary-address, can summarize groups of addresses for a given level. The metric used to advertise the summary is the smallest metric of all the more specific routes.

[DOC CD REF]

OL - PPPoE

2010-08-23T17:28:00.000-07:00

Notes:

PPPoE can be configured in a many different ways. One of the simplest is demonstrated here. R1 is the client and R2 is the server.

Summary Steps:

Order of Operation is important!

For the client:

1. under the FastE interface, enable pppoe 'pppoe-enable'

2. create a dialer interface, assign an IP, encaps PPP, and associate the this interface to a dialer pool

3. under the FastE interface, associate this interface to the dialer pool

For the server:

1. enable vpdn 'vpdn enable', create a vpdn-group 'vpdn-group CISCO', under the group 'accept-dailin' to make it a server, designate a virtual-template 'virtual-template 1' and configure the protocol to pppoe 'protocol pppoe'

2. configure the virtual-template with an IP (note the default encaps for the Virtual template is ppp)

3. under the FastE interface, enable pppoe.

Config:

interface FastEthernet1/0

no ip address

duplex auto

speed auto

pppoe enable group global

pppoe-client dial-pool-number 1

interface Dialer1

ip address 150.1.12.1 255.255.255.0

encapsulation ppp

dialer pool 1

dialer idle-timeout 0

dialer persistent

vpdn enable

vpdn-group CISCO

! Default L2TP VPDN group

accept-dialin

protocol pppoe

virtual-template 1

interface FastEthernet1/0

no ip address

duplex auto

speed auto

pppoe enable group global

interface Virtual-Template1

ip address 150.1.12.2 255.255.255.0

For DocCD reference, under 12.2 configuration guides, Wide-Area Networking, Configuring Broadband Access... [DocCD Ref]

INE Vol 1 multicast - Lab 12 - Multicast BGP

2010-08-22T14:14:00.001-07:00

Notes:

Nothing really to difficult here. This lab uses AFI and SAFI for ipv4 multicast.

Some things to note:

1. On the router connecting to the receiver, disable ip mroute-cache.

2. Disabling Fast Switching via the "no ip route-cache" command helps ensure that the packets are process switched.

INE Vol 1 multicast - Lab 11 - Anycast RP

2010-08-22T12:03:00.001-07:00

Notes:

This lab demonstrates an application of MSDP by using AnycastRP in a single PIM-SM domain. AnycastRP is used to provide RP redundancy within a PIM-SM domain and can provide load balancing.

Anycast RP uses an additional loopback on 2 or more routers with the same /32 ip address. This IP address is now the IP for the RP and must be known to all PIM-SM routers either via a static rp, autorp, or bsr.

MSDP is used to connect the 2 or more routers with this additional loopback so they can exchange RP source information.

The same reference as the last lab provides a better description and details.

[Good Ref]

Config:

R1 and R5 as the RP using AnycastRP (similar config on R5)

hostname R1

no ip domain lookup

ip multicast-routing

no ipv6 cef

multilink bundle-name authenticated

interface Loopback0

ip address 150.1.1.1 255.255.255.255

interface Loopback1

ip address 150.1.255.255 255.255.255.255

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

interface Serial1/0.12 point-to-point

ip address 150.1.12.1 255.255.255.0

ip pim sparse-mode

snmp trap link-status

frame-relay interface-dlci 102

interface Serial1/1

ip address 150.1.13.1 255.255.255.0

ip pim sparse-mode

serial restart-delay 0

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

ip pim rp-address 150.1.255.255

ip msdp peer 150.1.5.5 connect-source Loopback0

INE Vol 1 multicast - Lab 10 - MSDP

2010-08-22T11:17:00.000-07:00

Notes:

This Lab deals with MSDP, Multicast Source Discovery Protocol, which allows RPs in different domains to exchange information about Multicast Sources. This is used in PIM Sparse mode. Since RPs know about the receivers in its own domains but couldn't know about sources in other domains, MSDP is used to exchange the information about sources so that multicast traffic can flow between domains. Below is a good description on MSDP.

[Good Ref]

Config:

R2 and R4 are RPs for their respective PIM Sparse multicast domains, they are also edge routers in their own domains and peer via eBGP.

hostname R2

no ip domain lookup

ip multicast-routing

interface Loopback0

ip address 150.1.2.2 255.255.255.255

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

interface Serial1/0.21 point-to-point

ip address 150.1.12.2 255.255.255.0

ip pim sparse-mode

snmp trap link-status

frame-relay interface-dlci 201

interface FastEthernet2/0

ip address 150.1.24.2 255.255.255.0

duplex auto

speed auto

router ospf 1

log-adjacency-changes

network 150.1.2.2 0.0.0.0 area 0

network 150.1.12.2 0.0.0.0 area 0

default-information originate always

router bgp 1

no synchronization

bgp log-neighbor-changes

redistribute ospf 1

neighbor 150.1.24.4 remote-as 2

no auto-summary

ip pim rp-address 150.1.24.2

ip msdp peer 150.1.24.4 remote-as 2

hostname R4

no ip domain lookup

ip multicast-routing

interface Loopback0

ip address 150.1.4.4 255.255.255.255

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

interface Serial1/0.45 point-to-point

ip address 150.1.45.4 255.255.255.0

ip pim sparse-mode

snmp trap link-status

frame-relay interface-dlci 405

interface FastEthernet2/0

ip address 150.1.24.4 255.255.255.0

duplex auto

speed auto

router ospf 1

log-adjacency-changes

network 150.1.4.4 0.0.0.0 area 0

network 150.1.45.4 0.0.0.0 area 0

default-information originate always

router bgp 2

no synchronization

bgp log-neighbor-changes

redistribute ospf 1

neighbor 150.1.24.2 remote-as 1

no auto-summary

ip pim rp-address 150.1.24.4

ip msdp peer 150.1.24.2

Verification:

R6 - router closest to the receiver

R6#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:00:20/stopped, RP 150.1.24.4, flags: SJC
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:00:20/00:02:39

(10.1.37.7, 224.1.1.1), 00:00:19/00:02:41, flags: JT
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:00:19/00:02:40

(*, 224.0.1.40), 00:00:20/00:02:39, RP 150.1.24.4, flags: SJPCL
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list: Null

R6#

INE Vol 1 multicast - Lab 9 - Bootstrap Router

2010-08-21T17:34:00.000-07:00

Notes:

Similar to autoRP, BSR has a similar concept to autoRP and Mapping Agent. The "autoRP" equivalent in BSR is "ip pim rp-candidate " and the equivalent to the Mapping Agent is "ip pim bsr-candidate "

Config:

R1 - RP Candidate

interface Loopback0

ip address 150.1.1.1 255.255.255.255

ip pim sparse-mode

ip pim rp-candidate Loopback0

R5 - BSR

R5#sh run int l 0
Building configuration...

Current configuration : 85 bytes
!
interface Loopback0
ip address 150.1.5.5 255.255.255.255
ip pim sparse-mode
end

R5#sh run | i bsr
ip pim bsr-candidate Loopback0 0
R5#

INE Vol 1 multicast - Lab 8 - AutoRP and Default RP Placement

2010-08-21T16:53:00.000-07:00

Notes:

This lab uses both autoRP and static RP while in Sparse mode. When both are configured, autoRP takes precedence and if for whatever reason the RP info is lost, it falls to the statically configured RP.

You can also limit the groups that a particular RP will be the RP for.

Config:

R2 - the autoRP candidate

ip pim rp-address 150.1.2.2 1

ip pim send-rp-announce Loopback0 scope 16

ip pim send-rp-discovery Loopback0 scope 16

logging alarm informational

access-list 1 permit 224.0.1.39

access-list 1 permit 224.0.1.40

R1-R6 (minus R4), the other PIM routers

!
ip pim rp-address 150.1.2.2 1
!
logging alarm informational
access-list 1 permit 224.0.1.39
access-list 1 permit 224.0.1.40

Verification:

R1#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.2.2 (?), v2v1
Info source: 150.1.2.2 (?), elected via Auto-RP
Uptime: 00:13:45, expires: 00:02:10
Acl: 1, Static
RP: 150.1.2.2 (?)
R1#

Removed autoRP from R2
R1#sh ip pim rp mapping
PIM Group-to-RP Mappings

Acl: 1, Static
RP: 150.1.2.2 (?)
R1#
R1#

INE Vol 1 multicast - Lab 7 - PIM NBMA Mode

2010-08-21T14:16:00.001-07:00

Notes:

In this lab, R1 has a frame-relay multipoint interface via the physical serial interface which is to test the use of ip pim nbma mode.

Good Ref

[excerpt]

This PIM feature allows the router to only send packets to those neighbors that want to receive them. A router in PIM NBMA mode treats each remote PIM neighbor as if it were connected to the router through a point-to-point link.

Configs:

R1 - NBMA mode router

R1#sh run

Building configuration...

hostname R1

logging message-counter syslog

no ip domain lookup

ip multicast-routing

no ipv6 cef

interface Loopback0

ip address 150.1.1.1 255.255.255.255

ip pim sparse-mode

interface Serial1/0

ip address 150.1.125.1 255.255.255.0

ip pim nbma-mode

ip pim sparse-mode

encapsulation frame-relay

ip ospf network point-to-multipoint

serial restart-delay 0

frame-relay map ip 150.1.125.2 102 broadcast

frame-relay map ip 150.1.125.5 105 broadcast

no frame-relay inverse-arp

interface Serial1/1

ip address 150.1.13.1 255.255.255.0

ip pim sparse-mode

serial restart-delay 0

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

ip pim rp-address 150.1.1.1

ip pim autorp listener

INE Vol 1 multicast - Lab 6 - AutoRP Listener

2010-08-21T11:40:00.001-07:00

Notes:

Autorp listener is used in Sparse mode to ensure that the RP can talk to the Mapping Agent 224.0.1.39 and that the Mapping Agent can talk to the rest of the routers 224.0.1.40, which is accomplished by allowing these 2 groups to speak in Dense mode.

The Lab asks that we do not allow Dense mode fallback however since this is strictly Sparse mode, there is no possibility of this falling back to Dense mode. "no ip pim dm-fallback" should be used in Sparse-Dense mode, to stop the routers from speaking in Dense Mode if RP info is lost, since RPs are not used in Dense mode.

Configs:

No configs necessary as the only difference between Sparse mode and Sparse-Dense mode is "ip pim autorp listener"

Good Ref

*** INE Vol 1 Multicast note. No ip mroute-cache and autorp listener.

2010-08-21T11:16:00.000-07:00

Wanted to put a little marker to remember that on the router closest to the Receiver, you need to disable ip mroute-cache.

#no ip mroute-cache

on the interface pointing to the receiver router.

auto-rp listener - to be used in Sparse mode only - enables 224.0.1.39 and .40 the RP candidate and Mapping Agent to use Dense mode to get the RP mappings out to the other routers.

INE Vol 1 multicast - Lab 5 - AutoRP - Multiple Candidate RP

2010-08-21T11:06:00.000-07:00

Notes:

The objective of this lab is to use 2 separate routers R2 and R4 for the RPs for different multicast groups, 224.0.0.0/5 and 232.0.0.0/5, respectively. The task also designates only 1 Mapping Agent.

The configuration is the same as the last lab, lab 4, except for designating a group-list on the RPs.

I stumbled when creating the ACL for the group list, instead of using the wild card mask 7.255.255.255, used 31.255.255.255. I should have just done it the right way 8 bits minus 5 bits is 3 bits. 3 bits in decimal is 7.

Configs:

R2 - RP for 224.0.0.0/5

ip pim send-rp-announce Loopback0 scope 16 group-list 1

logging alarm informational

access-list 1 permit 224.0.0.0 7.255.255.255

R4 - RP for 232.0.0.0/5

ip pim send-rp-announce Loopback0 scope 16 group-list 1

logging alarm informational

access-list 1 permit 232.0.0.0 7.255.255.255

Verification:

R6#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.1.1.1), 00:02:21/stopped, RP 150.1.4.4, flags: SJC
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list:
FastEthernet1/1, Forward/Sparse-Dense, 00:02:21/00:02:35

(10.1.37.7, 232.1.1.1), 00:00:27/00:02:50, flags: JT
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list:
FastEthernet1/1, Forward/Sparse-Dense, 00:00:27/00:02:35

(*, 224.1.1.1), 00:02:22/stopped, RP 150.1.2.2, flags: SJC
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list:
FastEthernet1/1, Forward/Sparse-Dense, 00:02:22/00:02:42

(10.1.37.7, 224.1.1.1), 00:00:37/00:02:55, flags: JT
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list:
FastEthernet1/1, Forward/Sparse-Dense, 00:00:37/00:02:42

(*, 224.0.1.39), 00:02:40/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse-Dense, 00:02:40/00:00:00

(150.1.4.4, 224.0.1.39), 00:00:37/00:02:22, flags: PTX
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list: Null

(150.1.2.2, 224.0.1.39), 00:00:39/00:02:20, flags: PTX
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list: Null

(*, 224.0.1.40), 00:02:47/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse-Dense, 00:02:47/00:00:00

(150.1.5.5, 224.0.1.40), 00:00:39/00:02:22, flags: PLTX
Incoming interface: FastEthernet1/0, RPF nbr 150.1.56.5
Outgoing interface list: Null

R6#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/5
RP 150.1.2.2 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:00:43, expires: 00:02:16
Group(s) 232.0.0.0/5
RP 150.1.4.4 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:00:41, expires: 00:02:17
R6#

INE Vol 1 multicast - Lab 4 - AutoRP

2010-08-21T10:24:00.000-07:00

Notes:

Previous lab asked you to use a static rp address, in this lab, the objective is to use Auto RP.

Configure the network to support PIM Sparse Dense mode and designate which router will be the RP and which router the Mapping Agent (can be 1 and the same), usually using a loopback interface.

Configs:

R1 as the RP

R1#sh run

Building configuration...

Current configuration : 2367 bytes

hostname R1

no aaa new-model

ip source-route

ip cef

no ip domain lookup

ip multicast-routing

no ipv6 cef

interface Loopback0

ip address 150.1.1.1 255.255.255.255

ip pim sparse-dense-mode

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

interface Serial1/0.12 point-to-point

ip address 150.1.12.1 255.255.255.0

ip pim sparse-dense-mode

snmp trap link-status

frame-relay interface-dlci 102

interface Serial1/1

ip address 150.1.13.1 255.255.255.0

ip pim sparse-dense-mode

serial restart-delay 0

interface FastEthernet2/0

ip address 150.1.15.1 255.255.255.0

ip pim sparse-dense-mode

duplex auto

speed auto

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

ip pim send-rp-announce Loopback0 scope 16

R5 - Mapping Agent

R5#sh run
Building configuration...

Current configuration : 2331 bytes
!
upgrade fpd auto
version 12.4

hostname R5

ip source-route
ip cef
!
no ip domain lookup
ip multicast-routing
no ipv6 cef
!
multilink bundle-name authenticated
!
interface Loopback0
ip address 150.1.5.5 255.255.255.255
ip pim sparse-dense-mode
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial1/0.54 point-to-point
ip address 150.1.45.5 255.255.255.0
ip pim sparse-dense-mode
snmp trap link-status
frame-relay interface-dlci 504
!
interface FastEthernet2/0
ip address 150.1.56.5 255.255.255.0
ip pim sparse-dense-mode
duplex auto
speed auto
!
interface FastEthernet2/1
ip address 150.1.15.5 255.255.255.0
ip pim sparse-dense-mode
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
ip pim send-rp-discovery Loopback0 scope 16

INE Vol 1 multicast - Lab 3 - Multicast RPF Failure

2010-08-21T09:12:00.000-07:00

Notes:

This lab tests your understanding regarding uRPF for multicast. R1 and R5 have a high speed link, ie. FastEthernet connecting them, they also have another path through frame-relay and through other routers making it a less preferred path, however, pim isn't configured across the high speed link. This is where multicast gets "broken". Because data traffic will flow through the high speed link and will also carry multicast traffic, you either need to enable PIM on the high speed link OR use static mroutes to point through the less preferred path.

Config:

R1 - R5 have a high speed connection, FastE, with no PIM configured - they also have a low speed connection with PIM configured.

R5#sh run

Building configuration...

Current configuration : 2247 bytes

hostname R5

ip cef

no ip domain lookup

ip multicast-routing

no ipv6 cef

multilink bundle-name authenticated

interface Loopback0

ip address 150.1.5.5 255.255.255.255

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

interface Serial1/0.54 point-to-point

ip address 150.1.45.5 255.255.255.0

ip pim dense-mode

snmp trap link-status

frame-relay interface-dlci 504

interface FastEthernet2/0

ip address 150.1.56.5 255.255.255.0

ip pim dense-mode

duplex auto

speed auto

interface FastEthernet2/1

ip address 150.1.15.5 255.255.255.0

duplex auto

speed auto

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

ip forward-protocol nd

no ip http server

no ip http secure-server

ip mroute 10.1.37.7 255.255.255.255 Serial1/0.54

Verification:

Before applying the static mroute to R4 and R5

R5#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:00:02/00:02:57, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet2/0, Forward/Dense, 00:00:02/00:00:00

Serial1/0.54, Forward/Dense, 00:00:02/00:00:00

R5#

After applying the static mroute to R4 and R5

R5#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:00:14/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet2/0, Forward/Dense, 00:00:14/00:00:00
Serial1/0.54, Forward/Dense, 00:00:14/00:00:00

(10.1.37.7, 224.1.1.1), 00:00:14/00:02:52, flags: T
Incoming interface: Serial1/0.54, RPF nbr 150.1.45.4, Mroute
Outgoing interface list:
FastEthernet2/0, Forward/Dense, 00:00:14/00:00:00

(*, 224.0.1.40), 00:03:16/00:01:53, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet2/0, Forward/Dense, 00:03:16/00:00:00
Serial1/0.54, Forward/Dense, 00:03:16/00:00:00

R5#

INE Vol 1 multicast - Lab 1 & 2 - Dense & Sparse mode

2010-08-20T08:03:00.000-07:00

Notes:

Pretty straight forward. Dense uses a PUSH model and floods the mcast traffic whereas sparse uses a PULL model and receivers must join an mcast group.

Dense - you don't need an RP, Sparse - you need an RP, static or auto.

Lab is scheduled.

2010-08-20T04:48:00.001-07:00

Scheduled the lab... no turning back now :)

INE Vol 1 - Second Pass (minus Multicast) completed

2010-08-19T06:17:00.000-07:00

Finished 26 labs of INE Vol1, still have to do the Multicast labs but thought I'd give my thoughts on these so far.

Overall, these labs certainly focused more on MPLS VPNs and their capabilities, applications, etc. then IPX Vol 1. I think I can get through 90% of them just by looking at the diagram and the Objective which I take is a good sign that I can infer whats needed.

I plan on going over everything again, doing an assessment of where I am in relation to the blue print and then tackling another workbook. Reviewing MPLS Fundamentals. And finally tackling the Vol 2 labs.

INE Vol 1 - Lab 26 - Multicast over MPLS VPNs ?

2010-08-19T05:37:00.000-07:00

Notes:

For the second time, I couldn't get the tunnel to show up on PE R3 when executing a "show ip pim vrf SW1-SW2 neighbor"

I see the tunnel interface as up/up but I can't seem to see the other end, R6 the remote PE, as neighbor through the tunnel.

I did a show ip pim mdt and shows the loopback.

Not sure what's wrong...

Configs:

R3 -PE

hostname R3

boot-start-marker

boot-end-marker

logging message-counter syslog

no aaa new-model

ip source-route

ip cef

no ip domain lookup

ip vrf SW1-SW2

rd 1:2

route-target export 1:2

route-target import 1:2

mdt default 232.0.0.1

ip multicast-routing

ip multicast-routing vrf SW1-SW2

no ipv6 cef

interface Loopback0

ip address 150.1.3.3 255.255.255.255

ip router isis

ip pim sparse-mode

interface FastEthernet0/0

no ip address

shutdown

duplex half

interface Serial1/0

ip address 150.1.13.3 255.255.255.0

ip router isis

ip pim sparse-mode

mpls ip

serial restart-delay 0

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

ip pim sparse-mode

duplex auto

speed auto

interface FastEthernet2/1

no ip address

shutdown

duplex auto

speed auto

router isis

net 00.0000.0000.0003.00

is-type level-2-only

log-adjacency-changes

router rip

address-family ipv4 vrf SW1-SW2

redistribute bgp 100 metric 1

network 10.0.0.0

no auto-summary

version 2

exit-address-family

router bgp 100

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 100

neighbor 150.1.6.6 update-source Loopback0

address-family vpnv4

neighbor 150.1.6.6 activate

neighbor 150.1.6.6 send-community extended

exit-address-family

address-family ipv4 vrf SW1-SW2

redistribute rip

no synchronization

exit-address-family

ip forward-protocol nd

no ip http server

no ip http secure-server

ip pim ssm default

ip pim vrf SW1-SW2 rp-address 10.1.37.7

R6 - PE router

hostname R6

boot-start-marker

boot-end-marker

logging message-counter syslog

no aaa new-model

ip source-route

ip cef

no ip domain lookup

ip vrf SW1-SW2

rd 1:2

route-target export 1:2

route-target import 1:2

mdt default 232.0.0.1

ip multicast-routing

ip multicast-routing vrf SW1-SW2

no ipv6 cef

interface Loopback0

ip address 150.1.6.6 255.255.255.255

ip router isis

ip pim sparse-mode

interface FastEthernet0/0

no ip address

shutdown

duplex half

interface FastEthernet1/0

ip address 150.1.56.6 255.255.255.0

ip router isis

ip pim sparse-mode

duplex auto

speed auto

mpls ip

interface FastEthernet1/1

ip vrf forwarding SW1-SW2

ip address 10.1.68.6 255.255.255.0

ip pim sparse-mode

duplex auto

speed auto

router isis

net 00.0000.0000.0006.00

is-type level-2-only

log-adjacency-changes

router rip

address-family ipv4 vrf SW1-SW2

redistribute bgp 100 metric 1

network 10.0.0.0

no auto-summary

version 2

exit-address-family

router bgp 100

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 100

neighbor 150.1.3.3 update-source Loopback0

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

exit-address-family

address-family ipv4 vrf SW1-SW2

redistribute rip

no synchronization

exit-address-family

ip forward-protocol nd

no ip http server

no ip http secure-server

ip pim ssm default

ip pim vrf SW1-SW2 rp-address 10.1.37.7

INE Vol 1 - Lab 25 - MPLS QoS

2010-08-18T07:05:00.000-07:00

Notes:

QoS in MPLS is similar to doing a translation on PEs.

The objective was to guarantee 640 kbps of Voice traffic as a priority through the SP. Therefor, on the PEs, you need to classify VOIP coming from the CE and also VOIP-Translated coming from the P. Keep in mind that within the MPLS VPN, the labels carry EXP bits (3) so with the SP network you should be dealing with EXP exclusively.

Config:

R3 - PE router

class-map match-all VoIP

match access-group name VoIP

class-map match-all QOS_GROUP_5

match qos-group 5

class-map match-all MPLS_EXP_5

match mpls experimental topmost 5

policy-map TO_P

class MPLS_EXP_5

priority 640

class MPLS_EXP_1

bandwidth 1000

random-detect

policy-map FROM_P

class MPLS_EXP_5

set qos-group 5

class MPLS_EXP_1

set qos-group 1

policy-map TO_CE

class QOS_GROUP_5

priority 640

class QOS_GROUP_1

bandwidth 1000

random-detect

policy-map FROM_CE

class VoIP

set qos-group 5

set mpls experimental imposition 5

class class-default

set qos-group 1

set mpls experimental imposition 1

INE Vol 1 - Lab 24 - MPLS TE Unequal Cost Load Balancing

2010-08-14T12:17:00.001-07:00

Notes:

The objective asks you to configure TE tunnels with a total of 10 Mbps between 2 PE routers, R3 and R4. One third of the traffic between these PEs need to transit thru R5.

In order to accomplish this, I created to TE tunnels, Tun 0 and Tun 1, both explicit paths. Tun 0 bypassed R5 and Tun 1 went thru R5. The setup is identical until you get to the tunnels bandwidth statement. Since 1/3 has to go through R5, tunnel 1 has a bandwidth of 3333 kbps and tunnel 0 has 6667 kbps.

This is a good exercise to show that the RSVP Total BW is 10 Mbps so the sum of the individual tunnel bandwidths must be no more then 10 Mbps. This also achieves unequal cost load balancing via the bandwidth statements.

Config:

R3 - PE and TE Head End

interface Loopback0

ip address 150.1.3.3 255.255.255.255

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 3 3

tunnel mpls traffic-eng bandwidth 6667

tunnel mpls traffic-eng path-option 1 explicit name THRU_R4

no routing dynamic

interface Tunnel1

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 3 3

tunnel mpls traffic-eng bandwidth 3333

tunnel mpls traffic-eng path-option 1 explicit name THRU_R5

no routing dynamic

interface Serial1/0

bandwidth 155000

ip address 150.1.13.3 255.255.255.0

mpls traffic-eng tunnels

mpls ip

fair-queue 64 256 313

serial restart-delay 0

ip rsvp bandwidth 10000

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

duplex auto

speed auto

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

network 150.1.0.0 0.0.255.255 area 0

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.4.4 remote-as 1

neighbor 150.1.4.4 update-source Loopback0

address-family vpnv4

neighbor 150.1.4.4 activate

neighbor 150.1.4.4 send-community extended

neighbor 150.1.4.4 next-hop-self

exit-address-family

address-family ipv4 vrf SW1-SW2

neighbor 10.1.37.7 remote-as 2

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

ip explicit-path name THRU_R4 enable

next-address 150.1.13.1

next-address 150.1.12.2

next-address 150.1.24.4

next-address 150.1.4.4

ip explicit-path name THRU_R5 enable

next-address 150.1.13.1

next-address 150.1.12.2

next-address 150.1.25.5

next-address 10.1.45.4

next-address 150.1.4.4

INE Vol 1 - Lab 23 - MPLS TE Explicit PE to PE tunnels

2010-08-14T10:57:00.000-07:00

Notes:

*** Rule of thumb to simplify this configuration. After the MPLS VPN network is setup, think of it as overlaying TE on top. Go from General to Specific, meaning General = enabling MPLS TE on a global level, router wide. Then go to more Specific, like enabling MPLS TE in the link state IGP routing protocol, and then even more specific on the interfaces enabling RSVP and TE and then last step create the tunnel interfaces.

This lab is identical to the previous except for the TE tunnels using an explicit path list, hop by hop list, instead of a dynamic path like the last lab.

REMEMBER, the next-address is the next hop's inbound interface (looking from a downstream perspective).

Config:

R3 - PE and Tunnel head end

R3#sh run | b ipv6

no ipv6 cef

multilink bundle-name authenticated

mpls traffic-eng tunnels

interface Loopback0

ip address 150.1.3.3 255.255.255.255

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 4 4

tunnel mpls traffic-eng bandwidth 10000

tunnel mpls traffic-eng path-option 1 explicit name PATH

no routing dynamic

interface FastEthernet0/0

no ip address

shutdown

duplex half

interface Serial1/0

bandwidth 155000

ip address 150.1.13.3 255.255.255.0

mpls traffic-eng tunnels

mpls ip

fair-queue 64 256 313

serial restart-delay 0

ip rsvp bandwidth 10000

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

duplex auto

speed auto

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

network 150.1.0.0 0.0.255.255 area 0

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.4.4 remote-as 1

neighbor 150.1.4.4 update-source Loopback0

address-family vpnv4

neighbor 150.1.4.4 activate

neighbor 150.1.4.4 send-community extended

neighbor 150.1.4.4 next-hop-self

exit-address-family

address-family ipv4 vrf SW1-SW2

neighbor 10.1.37.7 remote-as 2

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

ip forward-protocol nd

no ip http server

no ip http secure-server

ip explicit-path name PATH enable

next-address 150.1.13.1

next-address 150.1.12.2

next-address 150.1.25.5

next-address 10.1.45.4

next-address 150.1.4.4

logging alarm informational

INE Vol 1 - Lab 22 MPLS TE - Dynamic PE to PE tunnels

2010-08-13T13:29:00.001-07:00

Notes:

Remember to configure the bandwidth statement on serial interfaces, this is especially important if you plan on using RSVP and reserving a large amount of BW because you won't be able to reserve say 10 Megs if the serial link is only 1.5 Meg.

Summary of configuration steps:

1. Enable MPLS Traffic Engineering tunnels globally

2. Ensure the Link State protocol is configured to support Traffic Engineering Tunnels and remember to use a /32 router-id loopback for MPLS TE

3. Ensure the links are configured for RSVP and MPLS TE

4. Create Tunnel Interfaces; use ip unnumbered for address, set a tunnel destination IP (the other loopback), autoroute announce so the tunnel is in the IGP, set bandwith, priority, and path-options.

Don't forget that the destination IPs need to be in IGP as well as do the MPLS TE router-ids. And that TE is unidirectional.

Configs:

R3 - PE and Tunnel Head End

R3#sh run | b no ipv6

no ipv6 cef

multilink bundle-name authenticated

mpls traffic-eng tunnels

INE Vol 1 - Lab 21 - Controlling MPLS Label Distribution

2010-08-12T17:17:00.000-07:00

Notes:

This lab asks you to limit the traffic that should be label switched. It states that only traffic between R3 and R6's (the PEs) Loopbacks should be label switched. In order to do so, on the PE and P nodes, use 'mpls ldp advertise-labels for #' and an ACL to limit what prefixes are allowed to be labeled and what prefixes are not.

Config:

R1 - P node

R1#sh run | i 99

mpls ldp advertise-labels for 99

access-list 99 permit 150.1.3.3

access-list 99 permit 150.1.6.6

access-list 99 deny any log

R1#

INE Vol 1 - Lab 20 - VRF Lite

2010-08-12T15:05:00.000-07:00

Notes:

It IS pretty straight forward, except for the fact that in GNS3, I used a single serial interface with 2 sub interfaces to another router. HDLC, nothing fancy, but wasn't able to ping on the sub-interfaces. I ended up making a separate physical connection for R3 to R1 and my configuration worked.

On point, this lab demonstrated the use of VRF lite to use a Managed CE with sub interfaces to the PE and segment traffic.

INE Vol 1 - Lab 19 - CSC Hierarchical MPLS VPNs

2010-08-09T12:39:00.000-07:00

Notes:

Fairly similar to the previous lab, same concepts with supporting more then 1 Enterprise end customer.

I would recommend review Lab 17 as it's not as intuitive as 18 or 19.

INE Vol 1 - Lab 18 - CSC MPLS enabled Customer Carrier

2010-08-09T10:19:00.000-07:00

Notes:

This Lab was much more intuitive, probably from struggling and figuring out the previous lab, and I was able to configure the topology without viewing the instructions. From the Objective and from the diagram, I understood that the Customer Carrier was supporting MPLS and MPLS VPNs, the Provider Carrier didn't change much as they too support MPLS VPNs. Providing IGP transport for R3 and R6, the Customer Carrier's PE routers, was straight forward. Since R3 and R6 participate in OSPF and R2 and R4's link into OSPF was through a VRF, redistribution for Carrier Providers PE's was necessary. Once R3 had reachability to R6, vpnv4 iBGP was established spanning the Provider Carrier's network. Finally, putting the Customer PE interfaces into a vrf for PE-CE connectivity and establishing eBGP with the Enterprise client routers, full reachability was established.

Remember to ensure MPLS is enabled through out the network up until the Enterprise connectivity links.

Configs:

R2 - Provider Carrier's PE

R2#srb

router ospf 100 vrf AS1

log-adjacency-changes

redistribute bgp 2 subnets

network 150.1.12.2 0.0.0.0 area 0

router ospf 1

log-adjacency-changes

network 150.1.24.2 0.0.0.0 area 0

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.24.4 remote-as 2

address-family vpnv4

neighbor 150.1.24.4 activate

neighbor 150.1.24.4 send-community extended

exit-address-family

address-family ipv4 vrf AS1

redistribute ospf 100 vrf AS1

no synchronization

exit-address-family

R3 - Customer Carrier's PE

R3#srb

router ospf 1

log-adjacency-changes

network 150.1.3.3 0.0.0.0 area 0

network 150.1.13.3 0.0.0.0 area 0

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 1

neighbor 150.1.6.6 update-source Loopback0

address-family vpnv4

neighbor 150.1.6.6 activate

neighbor 150.1.6.6 send-community extended

neighbor 150.1.6.6 next-hop-self

exit-address-family

address-family ipv4 vrf CUST

neighbor 10.1.37.7 remote-as 65001

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

INE Vol 1 - Lab 17 - CSC IP only Customer Carrier

2010-08-09T06:31:00.001-07:00

Notes:

The purpose of this lab was to utilize another carrier as transport for a customer carrier to provide IP services to their end customers, presumably enterprise clients. The SP carrier uses R2 and R4 and BGP between them as well as MPLS and MPLS VPNs down to R1 and R5 (the customer carrier's upstream routers). Being how this is an "IP Only" Customer Carrier BGP was only ipv4, however, R2 and R4 were VPNv4 for label transport/MPLS VPN.

I attempted to configure this lab and all the previous labs just from the Objective and the diagram without reading the specific tasks, this one was a difficult in doing that because the peering between BGP ASes was evident from the diagram. I ended up trying to peer AS1 and AS2 but instead should have redistributed OSPF vrf into ipv4 bgp vrf... etc.

This is a great lab to review again.

Configs:

R2 - SP Carrier Router

R2#sri s1/0.21

Building configuration...

Current configuration : 172 bytes

interface Serial1/0.21 point-to-point

ip vrf forwarding AS1

ip address 150.1.12.2 255.255.255.0

snmp trap link-status

mpls ip

frame-relay interface-dlci 201

end

R2#sri f2/0

Building configuration...

Current configuration : 104 bytes

interface FastEthernet2/0

ip address 150.1.24.2 255.255.255.0

duplex auto

speed auto

mpls ip

end

R2#srb

router ospf 1 vrf AS1

log-adjacency-changes

redistribute bgp 2 subnets

network 150.1.12.2 0.0.0.0 area 0

router ospf 100

log-adjacency-changes

network 150.1.24.2 0.0.0.0 area 0

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.12.1 remote-as 1

neighbor 150.1.24.4 remote-as 2

address-family vpnv4

neighbor 150.1.24.4 activate

neighbor 150.1.24.4 send-community extended

exit-address-family

address-family ipv4 vrf AS1

redistribute ospf 1 vrf AS1

no synchronization

exit-address-family

R1 - Customer Carrier Router

R1#sri s1/0.12

Building configuration...

Current configuration : 149 bytes

interface Serial1/0.12 point-to-point

ip address 150.1.12.1 255.255.255.0

snmp trap link-status

mpls ip

frame-relay interface-dlci 102

end

R1#sri s1/1

Building configuration...

Current configuration : 88 bytes

interface Serial1/1

ip address 150.1.13.1 255.255.255.0

serial restart-delay 0

end

R1#srb

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.2.2 remote-as 2

neighbor 150.1.2.2 update-source Loopback0

neighbor 150.1.5.5 remote-as 1

neighbor 150.1.5.5 update-source Loopback0

neighbor 150.1.13.3 remote-as 1

address-family ipv4

neighbor 150.1.5.5 activate

neighbor 150.1.5.5 route-reflector-client

neighbor 150.1.13.3 activate

neighbor 150.1.13.3 route-reflector-client

no auto-summary

no synchronization

exit-address-family

R3 - Customer Provider Edge Router

R3#srb

router ospf 1

log-adjacency-changes

network 150.1.3.3 0.0.0.0 area 0

network 150.1.13.3 0.0.0.0 area 0

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 10.1.37.7 remote-as 65001

neighbor 150.1.13.1 remote-as 1

address-family ipv4

neighbor 10.1.37.7 activate

neighbor 150.1.13.1 activate

neighbor 150.1.13.1 next-hop-self

no auto-summary

no synchronization

exit-address-family

INE Vol 1 - Lab 16 - Inter-AS MPLS VPNs with Multihop MP-eBGP for VPNv4 Exchange

2010-08-06T04:42:00.001-07:00

Notes:

The last 3 labs have been a similar problem with 3 different solutions. This one uses MP-eBGP to peer across different ASes for PEs (that are in different ASes). In order to accomplish this, the ipv4 bgp peering between R2 and R4 need to advertise the loopbacks of R3 and R6 (PE in AS1 and PE in AS2, respectively), they also need to advertise or redistribute into the IGP so the R3 and R6 can know of each other's loopback for MP-eBGP multihop peering. Don't forget to send-label for ipv4 peering. Finally, VPNv4 peer between R3 and R6.

Configs:

R2 - AS1 ipv4 peering point to AS2

R2#sh run | b router
router ospf 1
log-adjacency-changes
redistribute bgp 1 subnets route-map LOOP6
network 150.1.2.2 0.0.0.0 area 0
network 150.1.12.2 0.0.0.0 area 0
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.24.4 remote-as 2
!
address-family ipv4
neighbor 150.1.24.4 activate
neighbor 150.1.24.4 send-label
no auto-summary
no synchronization
network 150.1.3.3 mask 255.255.255.255
exit-address-family
!
R4 - AS2 ipv4 peering point to R2
router isis
net 00.0000.0000.0004.00
is-type level-2-only
redistribute bgp 2 route-map LOOP3
!
router bgp 2
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.24.2 remote-as 1
!
address-family ipv4
neighbor 150.1.24.2 activate
neighbor 150.1.24.2 send-label
no auto-summary
no synchronization
network 150.1.6.6 mask 255.255.255.255
exit-address-family
!
R3 - AS1 PE - ebgp vpnv4 multihop peering to R6
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.6.6 remote-as 2
neighbor 150.1.6.6 ebgp-multihop 255
neighbor 150.1.6.6 update-source Loopback0
!
address-family vpnv4
neighbor 150.1.6.6 activate
neighbor 150.1.6.6 send-community extended
exit-address-family

R6 - AS2 PE - ebgp vpnv4 multihop peering to R3
router bgp 2
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.3.3 remote-as 1
neighbor 150.1.3.3 ebgp-multihop 255
neighbor 150.1.3.3 update-source Loopback0
!
address-family vpnv4
neighbor 150.1.3.3 activate
neighbor 150.1.3.3 send-community extended
exit-address-family
!

INE Vol 1 - Lab 15 - Inter-AS MPLS VPNs with MP-eBGP for VPNv4 Exchange

2010-08-05T17:16:00.000-07:00

Notes:

Same physical setup as the previous lab, the important point to note here, is that if a you are using VPNv4 for route exchange between ASes, hence Inter-AS, then you have to disable BGP's default behavior of filter route-targets that it doesn't need. "Doesn't need" meaning no interfaces that are configured for that VRF.

R2 and R4 are "PEs" and they sit in 2 different BGP ASes, the eBGP peer in the VPNv4 AFI (MP-eBGP) but they won't have the VPNv4 routes from their respective PEs since they don't have interfaces in the particular VRFs. This means those VPNv4 routes are filter until you disable the feature.

Configs:

R2#sh run | b router bgp

router bgp 1

no bgp default ipv4-unicast

no bgp default route-target filter

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 1

neighbor 150.1.3.3 update-source Loopback0

neighbor 150.1.24.4 remote-as 2

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

neighbor 150.1.3.3 next-hop-self

neighbor 150.1.24.4 activate <- notice there's no "next-hop-self" because ebgp next hop is the

neighbor 150.1.24.4 send-community extended neighbor

exit-address-family

router bgp 2
no bgp default ipv4-unicast
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 150.1.6.6 remote-as 2
neighbor 150.1.6.6 update-source Loopback0
neighbor 150.1.24.2 remote-as 1
!
address-family vpnv4
neighbor 150.1.6.6 activate
neighbor 150.1.6.6 send-community extended
neighbor 150.1.6.6 next-hop-self
neighbor 150.1.24.2 activate
neighbor 150.1.24.2 send-community extended
exit-address-family
!

INE Vol 1 - Lab 14 - Inter-AS MPLS VPNs with Back to Back VRF

2010-08-05T13:12:00.001-07:00

Notes:

As the title suggests, or rather blatantly states, 2 BGP ASes that are MPLS enabled with an interconnect between R2 and R4, a VPN that spans both ASes.

So how is this accomplished? R2 and R4 have dot1q trunk between them and each subinterface belongs to a separate VRF. IPV4 eBGP between them. For the purpose of trying to keep it straight and simple. R2 and R4 both seem to act as PEs and CEs at the same time. The connections between them belong to VRFs and no label distribution protocol is deployed.

For example, R2 sends all it's routes in the VRFs via ebgp (the CE-PE routing protocol) R4 then sends them to the other PE via VPNv4 routes. And vice versa, R4 sends all it's routes in the VRFs via the same eBGP (CE-PE routing protocol) connections to R2 and then R2 sends them as VPNv4 routes to the other PE in it's AS.

Config:

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 1

neighbor 150.1.3.3 update-source Loopback0

neighbor 150.1.100.4 remote-as 2

neighbor 150.1.200.4 remote-as 2

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

neighbor 150.1.3.3 next-hop-self

exit-address-family

address-family ipv4 vrf SW2-BB2

neighbor 150.1.200.4 remote-as 2

neighbor 150.1.200.4 activate

no synchronization

exit-address-family

address-family ipv4 vrf SW1-BB1

neighbor 150.1.100.4 remote-as 2

neighbor 150.1.100.4 activate

no synchronization

exit-address-family

R2#sh run int f2/0.100

Building configuration...

Current configuration : 127 bytes

interface FastEthernet2/0.100

encapsulation dot1Q 100

ip vrf forwarding SW1-BB1

ip address 150.1.100.2 255.255.255.0

end

R2#sh run int f2/0.200

Building configuration...

Current configuration : 127 bytes

interface FastEthernet2/0.200

encapsulation dot1Q 200

ip vrf forwarding SW2-BB2

ip address 150.1.200.2 255.255.255.0

end

router bgp 2
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.6.6 remote-as 2
neighbor 150.1.6.6 update-source Loopback0
!
address-family vpnv4
neighbor 150.1.6.6 activate
neighbor 150.1.6.6 send-community extended
neighbor 150.1.6.6 next-hop-self
exit-address-family
!
address-family ipv4 vrf SW2-BB2
neighbor 150.1.200.2 remote-as 1
neighbor 150.1.200.2 activate
no synchronization
exit-address-family
!
address-family ipv4 vrf SW1-BB1
neighbor 150.1.100.2 remote-as 1
neighbor 150.1.100.2 activate
no synchronization
exit-address-family
!
!
interface FastEthernet2/0.100
encapsulation dot1Q 100
ip vrf forwarding SW1-BB1
ip address 150.1.100.4 255.255.255.0
!
interface FastEthernet2/0.200
encapsulation dot1Q 200
ip vrf forwarding SW2-BB2
ip address 150.1.200.4 255.255.255.0
!

INE Vol 1 - Lab 13 - MPLS VPNs with VPNv4 Route Reflection

2010-08-05T06:37:00.000-07:00

Notes:

This one is pretty straight forward, the ability to use AFI and disabling bgp default ipv4-unicast, you can separate VPNv4 RR and IPv4 RR.

* Regarding GNS3/dynamips, for some reason LDP didn't come up in the core right away, it took awhile, minutes, for LDP to come up but eventually it did on its own.

INE Vol 1 - Lab 12 - MPLS VPNs with OSPF Domain ID

2010-08-04T05:54:00.001-07:00

Notes:

When using OSPF as the CE-PE routing protocol and using unique OSPF process IDs and you want the routes at different vpn sites but the same VRF to have IA - Inter Area routes and not E2 - external (redistributed) routes, you can use the same OSPF Domain ID on the PEs for a single VRF. This changes the routes from E2 to IA.

Configs:

PE 1

R4#sh run | b router ospf

router ospf 5 vrf R5-SW1

domain-id 1.1.1.1

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

router ospf 6 vrf R6-SW2

domain-id 2.2.2.2

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

PE2

R3#sh run | b router os

router ospf 7 vrf R5-SW1

domain-id 1.1.1.1

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

router ospf 8 vrf R6-SW2

domain-id 2.2.2.2

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

CE - before using domain-id

R5#sr os

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O E2 10.1.7.7/32 [110/2] via 10.1.45.4, 00:00:39, FastEthernet1/0

O E2 10.1.37.0/24 [110/1] via 10.1.45.4, 00:00:39, FastEthernet1/0

R5#

CE - After using domain-id

R5#sr os

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O IA 10.1.7.7/32 [110/3] via 10.1.45.4, 00:00:17, FastEthernet1/0

O IA 10.1.37.0/24 [110/2] via 10.1.45.4, 00:00:27, FastEthernet1/0

INE Vol 1 - Lab 11 - OSPF Sham Link

2010-08-03T16:16:00.001-07:00

Notes: OSPF Sham link is a "virtual link" between 2 PEs, this is used because the CE-PE protocol is OSPF and it gets redistributed into MP-BGP and then back to OSPF making the routes over MPLS WAN an Inter Area route. The backdoor connection is an Intra Area route and would always take precedence. To over come this, the Sham link is created between the 2 PEs and the the routes no longer are Inter Area routes.

Some things to remember, create a new loopback on the PEs and put them in the VRF, the advertise the Loopback interfaces in the IPv4 VRF in BGP to create reachability. Also remember to add a high OSPF cost on the backdoor link.

Configs:

R3#sh run | b router os

router ospf 1 vrf R6-SW1

log-adjacency-changes

area 0 sham-link 10.1.3.3 10.1.4.4

redistribute bgp 1 subnets

network 10.1.37.3 0.0.0.0 area 0

router isis

net 00.0000.0000.0003.00

is-type level-2-only

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.4.4 remote-as 1

neighbor 150.1.4.4 update-source Loopback0

address-family vpnv4

neighbor 150.1.4.4 activate

neighbor 150.1.4.4 send-community extended

exit-address-family

address-family ipv4 vrf R6-SW1

redistribute ospf 1 vrf R6-SW1

no synchronization

network 10.1.3.3 mask 255.255.255.255

exit-address-family

interface Loopback1

ip vrf forwarding R6-SW1

ip address 10.1.3.3 255.255.255.255

end

R3#

INE Vol 1 - Lab 10 - SOO

2010-08-03T08:12:00.001-07:00

(The best explanation I can give is the one I already gave)

This lab was interesting in that there is a "gotcha".

The CE's in 2 different locations are using the SAME BGP AS number (AS 100) so inherently they won't exchange routes due to the loop prevention mech. That being said, using AS-OVERIDE on the neighboring CEs will replace any AS number (AS 100) that is the same with the PE AS number (AS 1), thus allowing connectivity.

The purpose of BGP SOO, which is a BGP extended community attribute, is to provide a loop prevention mechanism. A route-map applied on the PE to 2 CE neighbors "tags" the prefixes learned with a SOO. When tagging to 2 CEs off the same PE, the effect is that the PE won't advertise a learned route with the same SOO to another CE, effectively preventing a loop. An assumption is that the 2 CE's have a backdoor connection between themselves.

1 Thing to note, the solution guide config for SW1 doesn't have a bgp neigh peer statement for SW2, iBGP. But SW2 has a neighbor statement for SW1. (since one side is missing they are not iBGP peering)

On to the next one.

INE Vol 1 - Lab 9 - Export Map

2010-08-02T09:37:00.000-07:00

No issues with this one as well, just using an Export map within the VRF to change the RTs for some prefixes. Create a route-map, match an acl for the prefix, set the extcommunity rt and then in the vrf specify the route-map as an EXPORT map.

INE Vol 1 - Lab 8 - Extranet

2010-07-29T15:39:00.001-07:00

Another fairly easy review. Extranets using their own import/export of route-targets.

So far no notes or configs to put down seeing as I'm flying through the last (or first) 8 labs.

INE Vol 1 - Lab 7 - Central Services

2010-07-29T12:55:00.000-07:00

Also, pretty straight forward, a manipulation of route-targets, importing only the route target of the CS vrf and exporting your own route-target.

INE Vol 1 - Lab 1 thru 6

2010-07-29T12:09:00.000-07:00

Pretty straight forward, covers CE-PE routing protocols and static routes. Was a very easy review and not much to say.

Review of IPX Vol 1 for CCIE SP.

2010-07-26T16:24:00.000-07:00

Pros:

This volume is a great first step into studying for the CCIE SP Lab. It touches on a wide range of topics and it also focuses on the main portion of the Lab, MPLS. For a Volume 1, it's right where a candidate should start out, especially for someone who isn't familiar with what happens in the core of an MPLS network. The Volume has 25 labs, comes with initial configs, diagrams, and final configs and solutions.

Cons:

The volume could have had more detailed solutions and explanations, although I guess it's assumed that the candidate has some prior experience with these topics like MPLS VPNS, it should not assume some of the outliers, like frame-relay dlci switching or pppoe. I would have really liked this lab if the solutions were more detailed and the explanations discussed the reasoning for the technology.

Overall:

This is great first workbook, it gives you the first bite or taste of what to expect but is by no means an all encompassing volume.

IPX Vol 1 - Lab 25 - Adv. Routing

2010-07-25T14:24:00.001-07:00

Task 25.1 - ISIS on multipoint Frame Relay (main interface)

Notes: CLNS operation is different from other routing protocols. Rather then being encapsulated into IP, it operates on the data link layer. Since IP is being mapped across frame, CLNS needs to be mapped across frame as well. This is not an issue when using point-to-point subinterfaces because the frame-relay interface-dlci command sends ALL traffic out the DLCI. Remember to include the broadcast key word at the end.

Config:

R6#sh run int s1/0

Building configuration...

Current configuration : 243 bytes

interface Serial1/0

ip address 150.50.46.6 255.255.255.0

ip router isis

encapsulation frame-relay

serial restart-delay 0

frame-relay map clns 604 broadcast

frame-relay map ip 150.50.46.4 604 broadcast

no frame-relay inverse-arp

end

R6#

* Of the Advance Routing in this lab, the only place I stumbled was 25.1.

I'll review my notes for this workbook for myself and then I'll write up a review of IPX Vol1 in my next post and where I think it fits into the grand scheme.

IPX Vol 1 - Lab 24 - Multicast VPN

2010-07-25T12:32:00.000-07:00

[DOC CD REF] ** This is a good review of Multicast VPN

Note: Referring to the Doc CD, in the IOS I'm currently using (12.4(20T)), it's required that under BGP, I have to configure BGP MDT SAFI, activate neighbors and send-community.

Excerpt:
Configuring the MDT Address Family in BGP for Multicast VPN
Perform this task to configure an MDT address family session on PE routers to establish MDT peering sessions for MVPN.
The mdt keyword has been added to the address-family ipv4 command to configure an MDT address-family session. MDT address-family sessions are used to pass the source PE address and MDT group address to PIM using Border Gateway Protocol (BGP) MDT Subaddress Family Identifier (SAFI) updates.
Config:

router bgp 256
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 200.0.0.5 remote-as 256
neighbor 200.0.0.5 update-source Loopback0
neighbor 200.0.0.6 remote-as 256
neighbor 200.0.0.6 update-source Loopback0
!
address-family ipv4 mdt
neighbor 200.0.0.5 activate
neighbor 200.0.0.5 send-community extended
neighbor 200.0.0.6 activate
neighbor 200.0.0.6 send-community extended
exit-address-family
!
address-family vpnv4
neighbor 200.0.0.5 activate
neighbor 200.0.0.5 send-community extended
neighbor 200.0.0.6 activate
neighbor 200.0.0.6 send-community extended
exit-address-family
!
address-family ipv4 vrf VPNA
redistribute ospf 1 vrf VPNA
no synchronization
exit-address-family
!

Task 24.9 - Configure PIM sparse-mode on PE to PE links and loopbacks, configure SSM for multicast range 239.1.1.0 to 239.1.1.255, configure PIM spare-dense on VPN facing interfaces.

Config:

R2#sh run | sec pim|interface

interface Loopback0

ip address 200.0.0.2 255.255.255.255

ip pim sparse-mode

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

interface Serial1/0.24 point-to-point

ip vrf forwarding VPNA

ip address 150.50.24.2 255.255.255.252

ip pim sparse-dense-mode

snmp trap link-status

frame-relay interface-dlci 104

interface Serial1/0.25 point-to-point

ip address 150.50.25.2 255.255.255.252

ip router isis

ip pim sparse-mode

snmp trap link-status

mpls ip

frame-relay interface-dlci 105

interface Serial1/0.26 point-to-point

ip address 150.50.26.2 255.255.255.252

ip router isis

ip pim sparse-mode

snmp trap link-status

mpls ip

frame-relay interface-dlci 106

ip pim ssm range 1

ip pim vrf VPNA rp-address 200.0.0.4

R2#

R2#sh run | i access-list

access-list 1 permit 239.1.1.0 0.0.0.255

R2#Sh run | i multicast

ip multicast-routing

ip multicast-routing vrf VPNA

R2#

Task 24.10 - Enable VPNA for Multicast Routing... configure a default MDT and configure an RP address

Notes:

Here you have enable multicast for the VRF under multicast and enable MDT (multicast distribution tree) under the VRF. Finally, for a specific VRF you can specify the rp-address.

Config:

R2#Sh run | i multicast

ip multicast-routing

ip multicast-routing vrf VPNA

R2#

ip vrf VPNA

rd 256:1

route-target export 256:1

route-target import 256:1

mdt default 239.1.1.1

R2#sh run | sec rp-address

ip pim vrf VPNA rp-address 200.0.0.4

R2#

Task 24.11 - Configure PIM Sparse-Dense on SP facing interfaces on R1..., configure R1 to be a member of group 239.2.2.1...

Notes:

This is basic Multicast configurations.

Config:

R1#sh run | i multicast|rp-address|interface|pim|igmp
ip multicast-routing
interface Loopback0
interface FastEthernet0/0
interface FastEthernet1/0
ip pim sparse-dense-mode
ip igmp join-group 239.2.2.1
interface FastEthernet1/1
ip pim rp-address 200.0.0.4
R1#

IPX Vol 1 - Lab 23 - Traffic Policing

2010-07-24T11:02:00.001-07:00

Note:

Again, another quick and simple lab on using MQC to police traffic. Supports 2 bucket policing.

IPX Vol 1 - Lab 21 & 22 Congestion Avoidance & Traffic Classification

2010-07-24T10:26:00.001-07:00

Notes:

Labs 21 and 22 are quick labs focusing on Congestion Avoidance and Traffic Classification.

Congestion Avoidance = WRED, you can configure WRED directly under the interface or you can be more specific and use MQC to apply WRED to a specific set of traffic.

Traffic Classification can be done a number of ways, PBR, CAR (or Rate-limit), or MQC.

There's not much to say about these labs as they are quick and to the point.

IPX Vol1 - Lab 20 - CAR

2010-07-23T13:22:00.000-07:00

Notes:

For the most part this is a review from R&S studies. Whenever I see CAR, I equate that to 'rate-limit'.

A good review would be using the equations to find Tc, Bc, and Be.

Also, using different ACLs to classify, ie standard, extended, mac-address, and using extended ACLs for IP Prec classification is a good review.

[Doc CD Ref]

IPX Vol 1 - Lab 19 - Carrier Supporting Carrier

2010-07-22T17:14:00.000-07:00

Notes: This lab is similar in format as Lab 18 in that it tells you what to configure. Not much thought is required.

The overall idea of Carrier Supporting Carrier (CsC) is that you are utilizing another carrier as a backbone network, ie, using their footprint.

Task 19.5 - Configure IPv4 eBGP on R5 and R2... advertise its MPLS label

Config:

R5#sh run | sec bgp

mpls bgp forwarding

router bgp 156

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.50.25.2 remote-as 2

neighbor 200.0.0.6 remote-as 156

neighbor 200.0.0.6 update-source Loopback0

address-family vpnv4

neighbor 200.0.0.6 activate

neighbor 200.0.0.6 send-community extended

exit-address-family

address-family ipv4 vrf CSC

neighbor 150.50.25.2 remote-as 2

neighbor 150.50.25.2 activate

neighbor 150.50.25.2 send-label

no synchronization

exit-address-family

The highlighted config shows using IPv4 eBGP to send mpls labels while the next task simply asks you to configure ldp.

Task 19.6 - Configure OSPF... LDP on the link between R6 and R8

Config:

R6#sh run | sec bgp

redistribute bgp 156 subnets

router bgp 156

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 200.0.0.5 remote-as 156

neighbor 200.0.0.5 update-source Loopback0

address-family vpnv4

neighbor 200.0.0.5 activate

neighbor 200.0.0.5 send-community extended

exit-address-family

address-family ipv4 vrf CSC

redistribute ospf 1 vrf CSC

no synchronization

exit-address-family

alias exec sb sh ip bgp

alias exec cb clear ip bgp *

R6#sh run int f1/1

Building configuration...

Current configuration : 128 bytes

interface FastEthernet1/1

ip vrf forwarding CSC

ip address 150.50.68.6 255.255.255.0

duplex auto

speed auto

mpls ip

end

R6#

Notice there's no bgp peer with R8, hence, no send-label. However, looking at interface Fa1/1, you see that it's in a VRF AND it's using LDP with R8 to send the labels.

IPX Vol 1 - Lab 18 - Inter AS VPNs

2010-07-22T06:41:00.000-07:00

Notes: Regarding this lab, it's pretty straight forward when you are basically configuring what the task tells you to configure. The problem is, that it's too obvious and doesn't require a lot of thought.

There are 2 different ASes that eBGP peer between the PEs. The important thing to remember here is under ipv4 eBGP neighbor statements to "send-label". Also remember the use of "next-hop-self" for reachability into the other AS and "next-hop-unchanged" when receiving routes from the other AS for the CEs.

One other thing to personally note. Task 18.8 uses EIGRP as the CE-PE protocol, I tend to forget to state the "autonomous-system", if you don't it wont peer.

-- Also, the lab doesn't state that you should import the route-target of the other AS' routes but you can do so to test that the CE in one AS is receiving the routes advertised by the CE in the other AS and vice versa.

IPX Vol1 - Lab 17 - MPLS VPN

2010-07-20T11:51:00.000-07:00

Pretty basic configurations, some route-target import and export understanding is required. No issues to report.

IPX Vol 1 - Lab 16 - MP-BGP

2010-07-18T12:43:00.000-07:00

Task 16.10 - Using VRF Export maps to change the route-target.

Notes: In order to change the route-target of prefixs coming in, create a route-map setting the extcommunity rt to the new rt. Then under the vrf use "export map ", don't apply the route-map to the neighbor.

Config:

ip vrf RED

rd 100:1

export map RT

route-target export 100:1

route-target import 100:1

ip prefix-list 100 seq 5 permit 100.100.100.0/24

ip prefix-list 200 seq 5 permit 100.100.200.0/24

logging alarm informational

route-map RT permit 20

match ip address prefix-list 100

set extcommunity rt 100:100

route-map RT permit 30

match ip address prefix-list 200

set extcommunity rt 100:200

route-map RT permit 40

set extcommunity rt 100:1

Lab 15 - Review this lab.

2010-07-18T11:13:00.000-07:00

Marked as a lab to revisit.

IPX Vol 1 - Lab 15 - L2 VPN

2010-07-18T10:10:00.000-07:00

Task 15.2 - Configure Frame-Relay DLCI-to-DLCI switching on R4 and R5...

Notes: Remember that the "ip local interface..." needs to be reachable, ie, make sure it's in OSPF in this case.

Also keep in mind that L2TPv3 is found on the Doc CD under 12.4 WAN.

Config:

R4#sh run | sec pseudo

pseudowire-class MYWIRE
encapsulation l2tpv3
ip local interface Loopback0
R4#sh run int s1/0
Building configuration...

Current configuration : 162 bytes
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 402 switched
no frame-relay inverse-arp
end

R4#sh run | sec connect
connect R6_R2 Serial1/0 402 l2transport
xconnect 200.0.0.5 5544 pw-class MYWIRE
!
R4#sh run | sec ospf
router ospf 1
log-adjacency-changes
network 150.50.45.1 0.0.0.0 area 0
network 200.0.0.4 0.0.0.0 area 0

Verification:

R4#show l2tun session brief

L2TP Session Information Total tunnels 1 sessions 1

LocID TunID Peer-address State Username, Intf/
sess/cir Vcid, Circuit
19171 43255 200.0.0.5 est,UP 5544, Se1/0:402
R4#show l2tun session

L2TP Session Information Total tunnels 1 sessions 1

LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
19171 48468 43255 5544, Se1/0:402 est 00:05:20 1
R4#

R5
R5#
R5#sh run | sec pseudo
pseudowire-class MYWIRE
encapsulation l2tpv3
ip local interface Loopback0
R5#sh run int s1/0
Building configuration...

Current configuration : 162 bytes
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 506 switched
no frame-relay inverse-arp
end

R5#sh run | sec connect
connect R6_R2 Serial1/0 506 l2transport
xconnect 200.0.0.4 5544 pw-class MYWIRE
!
R5#sh run | sec ospf
router ospf 1
log-adjacency-changes
network 150.50.0.0 0.0.255.255 area 0
network 200.0.0.5 0.0.0.0 area 0

[DOC CD Ref]

[DOC CD Ref 2]

Task 15.3 - Q-in-Q Tunneling on Cat switches

Don't have switches right now.

Task 15.4 - Ethernet L2TPv3 on R1 and R4...

Notes: Same as 15.2, remember to advertise the loopback interface if you're using it in the pseudowire-class. Also, for Ethernet, you can make an xconnect statement right under the FE interface, rather then making a global connect statement

Config:

pseudowire-class MYWIRE

encapsulation l2tpv3

ip local interface Loopback0

interface Loopback0

ip address 200.0.0.1 255.255.255.255

interface FastEthernet1/0

no ip address

duplex auto

speed auto

xconnect 200.0.0.4 1144 pw-class MYWIRE

[Doc CD Ref]

Task 15.6 PPPoE

Notes: When you configure PPPoE, one side is the PPPoE client and the other side, the server. Configurations are different.

Configs:

R7 - Client Side

interface FastEthernet1/0

no ip address

duplex auto

speed auto

pppoe enable

pppoe-client dial-pool-number 1

interface Dialer1

ip address negotiated

encapsulation ppp

dialer pool 1

R9 - Server Side

bba-group pppoe global

virtual-template 1

interface FastEthernet1/0

no ip address

duplex auto

speed auto

pppoe enable group global

interface Virtual-Template1

ip address 150.50.79.9 255.255.255.0

peer default ip address pool R7

ip local pool R7 150.50.79.7

[Can't find Doc CD Ref]

IPX Vol 1 - Lab 14 - HSRP & VRRP

2010-07-17T15:35:00.000-07:00

Very simple lab on HSRP and VRRP. There were 2 tasks with a few sub task, took about 10 to 15 minutes to accomplish.

Note to self, can skip this one next time.

IPX Vol 1 - Lab 13 - QoS

2010-07-17T14:15:00.000-07:00

This lab focuses on QoS, including MQC, Rate-limit, Multicast Rate-limit, WFQ, and WRED.

Here are some things that I need to watch out for.

Task 13.4 and 13.5 - Generic Traffic Shaping

This task specifically says to configure GTS for Frame Relay. In order to configure GTS for FR, you need ACLs to classify traffic, and then under the interface use the "traffic-shape" command.

And to verify, see below.

Config:

R4#

R4#sh run | sec access-list

access-list 101 permit tcp any any eq telnet

access-list 101 permit tcp any eq telnet any

access-list 101 permit icmp any any

access-list 102 permit tcp any any eq ftp

access-list 102 permit tcp any eq ftp any

access-list 103 permit ip any any

alias exec sa sh access-list

R4#

R4#sh run int s1/0.24

Building configuration...

Current configuration : 294 bytes

interface Serial1/0.24 point-to-point

bandwidth 64

ip address 150.50.24.1 255.255.255.252

snmp trap link-status

traffic-shape group 101 9600 7968 7968 1000

traffic-shape group 102 32000 8000 8000 1000

traffic-shape group 103 22400 7952 7952 1000

frame-relay interface-dlci 401

end

R4#

R4#sh traffic-shape s1/0.24

Interface Se1/0.24

Access Target Byte Sustain Excess Interval Increment Adapt

VC List Rate Limit bits/int bits/int (ms) (bytes) Active

- 101 9600 1992 7968 7968 885 996 -

- 102 32000 2000 8000 8000 250 1000 -

- 103 22400 1988 7952 7952 361 994 -

R4#

Also, in order to configure Adaptive GTS

Config:

R5#

R5#sh run int s1/0.56

Building configuration...

Current configuration : 240 bytes

interface Serial1/0.56 point-to-point

ip address 150.50.56.1 255.255.255.252

snmp trap link-status

traffic-shape rate 64000 8000 8000 1000

traffic-shape adaptive 32000

traffic-shape fecn-adapt

frame-relay interface-dlci 506

end

R5#

[Doc CD Reference]

Task 13.7 - CAR

Remember, when a task says CAR, use the rate-limit command. Using ACLs to classify traffic and then combining it with the interface rate-limit command and the direction you can accomplish a single bucket policing.

Task 13.8 - Multicast Rate-limit

This tasks ask you to rate limit the incoming multicast traffic from a range of multicast groups,

226.0.0.1 to 226.0.0.126.

Config:

#sh run int f1/0

Building configuration...

Current configuration : 142 bytes

interface FastEthernet1/0

ip address 150.50.12.1 255.255.255.0

ip multicast rate-limit in group-list 25 512

duplex auto

speed auto

end

R1#sh run | sec access-list

access-list 25 deny 226.0.0.127

access-list 25 deny 226.0.0.0

access-list 25 permit 226.0.0.0 0.0.0.127

alias exec sa sh access-list

R1#

[Doc CD Reference]

Passed the SP written.

2010-07-15T09:44:00.000-07:00

Took and passed the written.

Now back to doing the labs.

IPX Vol 1 - Lab 12 - Security

2010-07-10T10:05:00.000-07:00

Lab 12 deals with Security in a very broad manner. Securing BGP, IGPs, Interfaces, logging, SNMP, NTP, anti-spoofing, Management security, and disabling unnecessary services.

Let's break it down...

12.1 - Accepting a limited amount of BGP prefixes from a neighbor

#neighbor 1.2.3.4 max-prefix 125000

12.2 - Securing BGP, on the destination router, create an ACL to allow the neighbor/source to create a TCP connection on port 179 to the destination router. Allow both sourcing from tcp 179 and destined to 179 on the destination router, then deny any to port 179 and finally permit tcp any and ip any.

12.3 - (a) Advertise a default route to neighbor #nieghbor 1.2.3.4 default-information originate.

Then configure the neighbor to only receive a default route via a prefix-list (0.0.0.0/0).

(b) RFC 1918 prefix-list should look like:

#ip prefix-list RFC1918 permit 10.0.0.0/8 le 32

#ip prefix-list RFC1918 permit 192.168.0.0/16 le 32

#ip prefix-list RFC1918 permit 172.16.0.0/12 le 32

Don't forget the le 32 since subnets of each of these ranges are still RFC1918.

(c) ORF - BGP outbound route filter is used to send a prefix-list upstream so that the filter happens there instead of after getting all the BGP prefixs and then having to filter locally. Saves resources.

#neighbor 1.2.3.4 capability orf prefix-list send

12.4 and 12.5 are OSPF and EIGRP authentication, EIGRP everything is done on the interface while OSPF area authentication is done in the area and then on the interfaces in that area.

12.6 - Anti-Spoofing

(a) to prevent spoofing configure uRPF under an interface.

#ip verify unicast source reachable-via rx allow-default

(b) uRPF in loose mode the router will drop the packet if the route for the source is via a null interface. Configured the same was as (a) plus the routes pointing to null0

(c) using an ACL to block spoofing. Create a standard ACL denying the subnets/hosts in your internal network, then apply inbound on the ingress interface.

(d) redundant

(e) configure ip accounting.

#interface s0/1.26

#ip accounting access-violations

12.7 - Logging - straight forward with the exception of Core dumps. Remember the key work "exception" to configure core dump file name, protocol, and IP addy of the dump server.

12.8 - Interactive Access

(d) SSH server - don't forget to configure a domain-name, crypto key generate rsa, and AAA if necessary.

This section was long and there are definitely some things I knew at one point but have forgotten. Good to review and to deep dive via Narbik's books.

IPX Vol 1 - Lab 11- Traffic Engineering (TE)

2010-07-06T16:07:00.000-07:00

This is a straight forward one. TE tunnels are unidirectional, therefore, if you want bidirectional traffic between 2 end points to flow through a certain path, that means 2 tunnels. This task asks the student to prep the topology for MPLS TE, create the TE tunnels (one dynamic path and one explicit path), and verify.

Points to remember:

*prerequisiste: mpls and cef are enabled globally and on the interfaces

1. Must enable TE globally on a router

R1(config)#mpls traffic-eng tunnel

#mpls ldp router-id l0 - This is important as it will be used when creating a TE tunnel as a tunnel destination

2. Must configure TE for the routing protocol (OSPF or ISIS)

R1(config)#router os 1

#mpls traffic-eng router-id l0

#mpls traffic-eng area 0

3. Configure RSVP on the interfaces

R1(config)#interface f1/0

#ip rsvp bandwidth 75000 100 - By default the router will reserve 75% of max-reserveable bandwidth, if not defined

4. Interfaces must support traffice engineering

R1(config)#interface f1/0

#mpls traffic-eng tun

5. If using explicit path

R1(config)#ip explicit-path name ABC

#next-address 1.2.3.4 - the ip is the inbound interface of the next-hop router

#next-address .... - list all the inbound interfaces in order including the destination router

6. Create a tunnel interface

R1(config)#int tun0

#ip unnumber l0

#tun destination 200.0.0.6

#tunn mode mpls traffic-eng

#tun mpls traffic-eng path-option 1 explict name ABC

#tun mpls traffic-eng path-option 2 dynamic

#tun mpls traffic-eng autoroute announce

#tun mpls traffic band 100

There are a few things to remember here, ip addy, tunnel destination, tunnel mode, path options. The autoroute announce is used so that traffic can be forwarded on to the tunnel, it specifies that the IGP (in this case ospf) should use the tunnel when calculating SPF.

7. Specify tunnel priorities for setup and hold (lower is better)

R1(config)#int tun 0

#tunn mpls traffic prio 7 7

IPX Vol 1 - Lab 10 - Multicast

2010-07-05T15:07:00.000-07:00

This one was a little jacked up. It started out fine but then towards the end, it went to pieces.

A few things to remember:

- multicast groups 224.0.1.39 and 224.0.1.40 are used for RP announce and discovery respectively.

- ip pim autorp listener used for sparse mode interfaces/routers so that they can receive the rp announce info in dense mode.

- I need to brush up on 10.5 - For BSR, using ip pim bsr-border will ensure dynamic RP announcements from one AS aren't propagated to the neighboring AS. For AutoRP, set up a filter to block traffic e for 224.0.1.39 and .40 and apply the filter with a multicast boundry, ie,

#int s1/0.26

#ip pim sparse-mode

#ip multicast boundary 24

#access-list 24 deny 224.0.1.39

#access-list 24 deny 224.0.1.40

#access-list 24 permit 224.0.0.0 0.15.255.255

IPX Vol 1 - Lab 9 - MPLS

2010-07-05T05:53:00.000-07:00

Pretty straight forward for me now, nothing that I stumbled on. Just a few things that can escape you if you don't keep them in the back of your mind.

1. CEF - required to be on the routers to support MPLS
2. #no bgp default ipv4-unicast - used to disable the default behavior of putting "unspecified" commands into the AFI ipv4 unicast. This means, you have to manually go into the AFI and make your configurations.

3. If you don't advertise the WAN link then you have to source your pings from the loopback because there's no route back, since it's not being advertised.

4. BGP Next Hop Self - know when and why you need it.

Most of this is stuff I know but can forget if rushed :)

IPX Vol 1 - Lab 8 - MBGP

2010-07-04T13:17:00.000-07:00

Task 8.3 - BGP Dampening.

- Remember that BGP dampening is under the address-family as "bgp dampening route-map ABC" and not a applied to a neighbor.

- To verify, show ip bgp dampening parameters

Restarting... again.

2010-07-04T12:49:00.001-07:00

It's been awhile since I've hit the workbooks and it's never good to stop in the middle of something, progress becomes hindered.

I'm back to studying for the CCIE SP lab and this time I'm taking it more seriously.

New Plan!

IPX Vol1 workbook
INE Vol1 workbook

And then assess and make more plans.

Lab 14 done. INE Vol 1 - 2nd pass.

2010-03-31T11:49:00.000-07:00

Lab 14 - Back to Back VRFs - Let's say you have 2 different Service Providers you want to leverage in order to get reachability between 2 remote sites. One way the 2 service providers can still utilize MPLS is to create a peering point between 2 PE routers. Lab 14, goes into using 2 PE routers, 1 per provider, and establishing multiple interfaces for multiple VRF route exchange. So, after putting a sub-interface into a vrf, you'll have to ipv4 vrf bgp peer to the other providers PE. In this lab, the other thing to recognize is that the VRF stays consists/uniform as it traverses through both providers, same route-target and Route distinguishers are used. However, if you wanted to export and import different route targets, you should be able to do that as well.

Lab 13 done. INE Vol 1 - 2nd pass.

2010-03-30T17:12:00.000-07:00

Lab 13 - MPLS VPNs with VPNv4 Route Reflection - pretty straight forward, under the vpnv4 address family in bgp you designate the neighbors you want as Route-Reflector-Clients. Similar to ipv4 route-reflector-clients. To deny IPv4 bgp route exchange, under the address-family ipv4, do a 'no nei a.b.c.d activate' to turn off ipv4.

Labs 9, 10, 11, and 12 done. INE Vol 1 - 2nd pass.

2010-03-24T04:47:00.000-07:00

9- VRF Export Maps - basically using a route-map to classify a prefix/subnet and setting a extcommunity RT.

10- BGP SOO - Pretty similar to an Export Map but instead of setting RT in a route-map setting extcommunity SOO and applying the route-map to a bgp neighbor

11- OSPF Sham Links - Because OSPF will always prefer Intra area routes, when there's a backdoor link between 2 remote sites, the MPLS connectivity isn't used for the intersite communications unless a OSPF Sham link is created between the 2 PEs. Similar to a virtual link in syntax, just remember to advertise the Loopbacks your using to create the sham link into BGP (red connected) for reachability

12- OSPF and Domain-id - using individual processes on a per site basis and individual VRFs, you can still achieve site to site communications or restrict via a OSPF domain id and the proper import/export of route-targets.

Labs 6, 7, and 8 done. INE Vol 1 - 2nd pass.

2010-03-20T09:18:00.000-07:00

Lab 6 - MPLS VPNs with eBGP, straight forward, don't need any redistribution into BGP VPNv4, an administrative benefit of using eBGP as the CE-PE protocol.

Lab 7 - Central Services MPLS VPNs, need to be careful on what to route-targets to import and export, be specific and only include the ones you need.

Lab 8 - MPLS VPNs with Extranet, using an additional route-target to connect CEs in 2 different MPLS VPNs together. By using a second route-target import/export you can create an overlapping VPN between 2 or more CEs.

Labs 4 and 5 done. INE Vol 1 - 2nd pass.

2010-03-19T19:21:00.000-07:00

Lab 4 - MPLS VPNs with OSPF
- Pretty straight forward, use "router ospf XXX vrf YYY"

Lab 5 - MPLS VPNs with EIGRP
- Not as straight forward for me, use a main EIGRP process then use address-families, don't forget to include an "autonomous-system XXX" in the address family.

Good to do these two labs back to back because you get to see the difference in how VRFs are handled.

Labs 1,2, and 3 done. INE Vol 1 - 2nd pass.

2010-03-17T12:46:00.001-07:00

Decided to Vol 1 again from both vendors, 2nd time around is much easier but still tripping up on some silly mistakes.

I was able to do labs 1, 2, and 3 in a matter of an hour. I still made the silly mistake of not specifying bgp next-hop-self between the PEs... It's funny how quickly I forget, I even made a note of this at the end of lab 1 during my first pass.

on to the next one.

1 Year as a CCIE.

2010-03-17T09:21:00.000-07:00

In three days, it'll be one full year since I got my numbers in R&S. Like many other bloggers, it a good time to reflect.

What's changed in the last year?
- My job, although with the same company, I've transitioned from a Pre-Sales Engineer to a Post Sales Engineer, augmenting the customer's staff by being on site and being responsible for primarily their WAN devices.
- Opportunities, I've had doors open and opportunities present themselves that had I not gotten my CCIE, I don't think I'd be considered or offered.
- Confidence and Understanding, the last year has been a growth experience within myself. I'm more confident in what I do and where I want to be.

I'm looking forward to the remainder of 2010, I'm pursuing another track, albeit much slower. And who knows what the future has in store?

Back on track.... sort of.

2010-02-28T17:49:00.000-08:00

I'm back to studying Service Provider material... but instead of continuing where I left off, INE Vol 1 Multicast Labs, I'm reading/re-reading 'MPLS Fundamentals'.

A lab I set up for AToM comes from chapter 10 of the book.

I tried to recreate the configuration from memory and being that it's only a few lines, I thought it would be easy.

I missed the configuration "mpls ldp router-id loopback 0 force" and until I put that command in, the VC never came up. This lab was for a simple HDLC connection.

What's the significance of this command? Why does the MPLS router-id have to be set?

Hmm...

*** Edit

I'm assuming the LDP router-id has to be the same has the xconnect peer. I'm guessing if I didn't for the router-id to be the loopback but specified the outgoing interfaces as the xconnect peers, it would have worked. Time to lab it up.

*** Edit 2

Odd, I tested it out, removed the mpls ldp router-id force command, clear mpls ldp nei *, xconnect to the serial interface of the remote end, the L2 VC circuit showed up, but the CE router interfaces never came up.

Side Tracked - Passed CCNA Voice.

2010-02-15T13:01:00.000-08:00

With 2010 comes new goals, both personal and professional. I decided to take some time to study, lab up, and take the CCNA Voice 640-460 exam. Overall it was pretty straightforward, I studied using a single router with an AIM-CUE for CME and CUE, CBT-Nuggets and the OECG. No access to an UC-500 but that's ok. Was this a personal goal? No, it was work related.

Now I'm debating on CCVP... what to do... what to do...

INE Vol 1 - Multicast Lab 1 - ip pim dense mode.

2010-01-22T11:44:00.000-08:00

I still have to revisit the last lab and review the comments in the last post but I went ahead and did the first lab of the IP Multicast section in Vol 1 INE.

Relatively easy as it's basic PIM Dense mode multicast and was covered under R&S.

There's 13 labs in this section and that will complete Vol 1. I'm also going over the CoD for SP from INE too and I'm finding them very helpful

I'm thinking of going on to IEMENTOR's lab book... but after that, what should I tackle next? IPX vol 2 or INE vol 2 (both have 10 labs)...

INE Vol 1 - Lab 26 - finished - Mulicast over MPLS VPNs

2010-01-18T08:22:00.000-08:00

I completed this lab, albeit, I had to cheat and look at the solutions for some parts since I wasn't sure what to do.

Question:

1. What is the purpose of MDT under the VRF?

I suppose, I'll Cisco Univercd or google it.

Also my verifications didn't come up. When I do a "show ip pim vrf SW1-SW2 neighbor" I don't actually see the tunnel0 interface of R3 or R6. The tunnel interface is up/up though.

Think I have to read about Multicast over MPLS A LOT more.

INE Vol 1 - Lab 25 - finished - MPLS QOS

2010-01-12T09:42:00.000-08:00

QoS is pretty straight forward for SP as it is for R&S. Just have to read carefully what's being classified, what's being marked, and where and what direction to apply the service policy. Then you have to make sure it's consistent throughout the SP network.

It's more of exercise in being careful and thorough then anything else.

On to the Last lab in the MPLS section...

INE Vol 1 - Lab 24 - finished - TE Unequal Cost Load Balancing

2010-01-08T09:41:00.000-08:00

Completed this lab pretty easily since it was combination of the 2 before it, one dynamic tunnel and one explicit tunnel, manipulating the tunnel bandwidth for unequal cost load balancing via OSPF.

Something I don't understand is why INE didn't have TE labs based on ISIS, the 3 TE labs were using OSPF. I understand they are pretty similar to each other with an addition of using Wide Metric (metric style wide) under the physical interfaces. But still, it would have been nice to through 1 lab in there with IS-IS.

On to the next lab.

INE Vol 1 - Lab 23 - finished - TE Explicit PE to PE tunnel.

2010-01-06T14:10:00.000-08:00

Very similar with the last lab with exception of creating an
'ip explicit-path name ABC enable' and then on the tunnel interface
'tunnel mpls traffic-eng path-option 1 explicit name ABC'

One gotcha is to make sure that the HOPs in the list are correct... I had a 10.x.x.x network but I put it in as 150.x.x.x because the rest of the network was like that.

Another good one to review and dissect.

INE Vol 1 - Lab 22 - finished - TE Dynamic PE to PE tunnels

2010-01-06T11:05:00.001-08:00

This one was my first exposure to Traffic Engineering (TE) and it was an eye opening lab on how much I don't know about TE.

Notes:
1. enable 'mpls traffic-eng' globally on MPLS routers (PE and P)
2. enable 'mpls traffic-eng' on a per interface basis for the links that are MPLS enabled
3. enable 'mpls traffic-eng' under the OSPF process specifying a router-id and area
4. configure RSVP on a per interface basis for the tunnel path
5. configure tunnel interfaces on the PE end points
6. advertise the tunnel interface/ip in OSPF.

TE is something I need to read up on but doing the lab before hand actually will help understand what I'm going to read.

INE Vol 1 - Lab 21 - Question? - Controlling MPLS Label Distribution.

2010-01-05T08:05:00.000-08:00

So I configured the following to limit the distribution of labels local to a router.

R3's Loopback is 150.1.3.3/32 and R6's Loopback is 150.1.6.6/32

#access-list 1 permit 150.1.3.3
#access-list 1 permit 150.1.6.6
#access-list 1 deny any

#mpls ldp advertise-labels for 1

But I'm still able to see labels for other prefixes...

Any thoughts on why this is? I even cleared MPLS LDP Nei * but still see labels for other prefixes...

INE Vol 1 - Lab 20 - finished - VRF Lite (Multi VRF)

2010-01-04T10:43:00.001-08:00

Good lab to get an understanding of doing VRF Lite on the CE routers which can be done when a customer subscribes to more then 1 VRF at a site but with only 1 CE router.

From the CE's perspective, it has multiple logical (can be physical) interfaces up stream to the PE. Each link is put into it's own VRF. Downstream to other customer internal routers, each link is put into the respective VRFs. The VPN/VRF table is extended to the CEs. This segregates the 2 networks even when there's only 1 CE. One thing to note, on the CE's there's no need to import or export Route Targets, that's still done on the PE.

The PE's put the logical interfaces into different VRFs and reference the same RDs used on the CEs for their corresponding links/VRFs, for route targets. Basically the PE configuration stays the same EXCEPT for the fact the link to the CE is a single physical link but with multiple logical links.

Good lab to review and build by just looking at the topology.

INE Vol 1 - Lab 19 - CSC Hierarchical MPLS VPNs

2010-01-04T07:48:00.001-08:00

This one was pretty straight forward as well and the name implies the structure of the VPNs. One CSC VPN/VRF to connect the Customer Providers network and then the Customer Provider has End Customers so each of them will have their own VRF.

Main point is that redistribution occurs on the Main Service Providers network and then once again on the Customer Service Providers network to get end to end reachability.

On to the next one.

INE Vol 1 - Lab 18 - CSC MPLS enabled.

2010-01-02T08:34:00.000-08:00

Pretty straight forward, although I should definitely read up on the theory on these. This lab, compared to the last one, was a bit easier since there were less BGP peerings since the links were MPLS enabled throughout both Service Providers. In the last lab, not all links in the provider cloud was MPLS enabled, hence the title, IP ONLY.

On to the next one.

INE Vol 1 - Lab 17 - CSC IP Only

2010-01-01T14:54:00.000-08:00

First lab for Carrier Supporting Carrier (CSC) and it's still not very clear to me on some of configurations. Still got it to work by following the tasks but not as intuitive as the other labs.

I still made the same mistake, although I caught it much faster this time, as in the previous lab. "MPLS IP" was missing from some of the provider links, the control plane (ie. the routing table) look good, saw the BGP route but the forwarding plane was messed up because I couldn't ping.

At least I'm learning.

BGP AS 2 was used as the Service Provider servicing the Customer Service Provider and BGP AS 1 was used as the Customer Service Provider's network. BGP AS 65001 and 65002 were customer CEs connecting to the Customer Service Provider's network.

Within AS 1, I had to use route-reflectors in order to get around the fully meshed iBGP peering rule and another note I had to mutually redistribute on the Service Provider routers supporting the Customer Service Provider before iBGP could be formed. This was asked to be done in the last step.

On to the next one.

INE Vol 1 - Lab 16 - Multihop MP-eBGP for VPNv4 Exchange

2009-12-22T10:45:00.000-08:00

Finally finished this lab, but experienced and oddity...

I saw the routes in the CE routers for the remote CE but wasn't able to ping. I even sourced my pings from a loopback that was being advertised in the CE-PE routing protocol. Weird.

Other than that, this was an interesting one, the 2 routers that join the 2 BGP ASes, were configured as eBGP peers and configured to send-label. Then the the eBGP VPNv4 relationship was farther spread apart, it was actually a peering of the PE to PE across 2 BGP ASes.

All in all, a good lab, but I'm troubled by why I can't seem to ping from CE to CE in either VRF.

On to the next one.

UPDATE------------ Issue resolved.
The problem was something so silly, I didn't have MPLS IP configured on R4, R5, and R6 in my ISIS domain. A good lesson, if your control plane looks good (ie your routing table) then the problem has to be in your forwarding plane. Thanks to Vignesh for his help.

INE Vol 1 - Lab 15 - finished - MP-BGP for Inter VRF

2009-12-14T16:57:00.000-08:00

So it's taken awhile to finish this lab, mostly due to the my new role at work. I'm supporting production networks and troubleshooting issues and while it's interesting to some degree, it does take away from studying.

Anyhow, this lab was the same setup as the last one, back to back VRFs, but uses MP-BGP to leak routes between BGP domains. The thing to note on this lab is BGP automatically filters route-targets that it doesn't need to know of (meaning it doesn't have a link configured for). So in order to exchange VPN routes it needs to stop this filtering by...
'no bgp default route-target filter' under the BGP process. That way, it can know the VRF routes and leak them between it's MP-eBGP peer of the other network.

I'm afraid my progress will continue to slow, I hope once things settle down I'll be able to return more aggressively to my studies.

INE Vol 1 - Lab 14 - finished - Back to Back VRF

2009-11-19T09:44:00.000-08:00

Pretty straight forward lab on using 2 routers and a single Fast Ethernet interface, dot1q trunked or "router on a stick", to exchange VRF information for 2 ASes to interconnect CEs. Yeah, that's a long sentence. So the 2 CE's span 2 different BGP ASes, and the 2 BGP ASes meet at a single point where the 2 routers share a dot1q FE trunk. The sub interfaces of the FE are configured like CE connections, meaning that the links are configured for a specific vrf on both routers. Then there are 2 BGP peering sessions for each VRF in the IPv4 table. RDs for the VRFs are the same even if the BGP Peering isn't direct.

The BGP peering point just looks like a connection to another CE on each AS.

Good lab, have a feeling a similar configuration is done for VRF-Lite and I'll see it when I do that lab.

INE Vol 1 - Lab 13 - finished - VPNv4 Route Reflection

2009-11-09T11:21:00.001-08:00

This lab was interesting. Basically, the lab asks you to use a router (R2) to be VPNv4 route reflector for 3 BGP clients R3, R4, and R6. The 3 clients (or PEs) have a MPLS VPN configured but the route-reflector doesn't. I'm going to liken R2 as a P-core router.

This lab also demonstrates another router, R1, to be the IPv4 route-reflector for it's BGP peers. R1 is the route-reflector for R2 through R6. R1 is also eBGP peered with BB3 and is receiving routes. This portion demonstrates how ipv4 bgp routes are unaffected by VPNv4 BGP routes and vice versa.

This one would be good to go back to, to keep VPNv4 and IPv4 BGP straight.

INE Vol 1 - Lab 12 - finished - OSPF Domain-ID.

2009-11-03T09:32:00.000-08:00

In this lab we were asked to peer with the PE routers from 4 remote CE sites using different OSPF AS numbers. The 4 routers were put into 2 VPNs (as most of these labs require). Using different RDs and importing and exporting different RTs, only the members of a vpn were able to talk to each other.

The part that this lab tests you on is OSPF Domain-ID. Using the same domain-id for OSPF on the PEs for the CE members in the same VPN allows the OSPF routes on the CEs to look like inter-area (ia) routes instead of external (e2) routes. This means that over mpls cloud, the 2 sites are looking like they're separated by an area-boarder router when in actuality they're still mutually redistributed into BGP.

On to the next lab.

INE Vol 1 - Lab 11 - finished - OSPF Sham Link.

2009-11-03T05:21:00.000-08:00

The gist of this lab was when using OSPF to interconnect 2 remote sites to 2 PEs and they have a back door link to each other (ie a private line) then because the routers are in the same area 0, routes within an area are preferred over routes that are INTER area and OSPF has a lower AD then iBGP. To get around this, between the two PEs you can create an ospf sham-link and then change the cost of the backdoor link to be worse.

config:

Router1(config-if)# area 1 sham-link 10.2.1.1 10.2.1.2 cost 40

verify:

show ip ospf sham-links

INE Vol 1 - Lab 10 - finished - BGP SOO.

2009-10-27T10:32:00.001-07:00

This lab was interesting in that there is a "gotcha".

On to the next one.

INE Vol 1 - Lab 9 - finished - Export Maps.

2009-10-26T10:49:00.000-07:00

This one was pretty straight forward as well...

Use an export map to gain connectivity to ONLY certain subnet in a different VRF, similar to a Extranets and subsequently Common Services VRF but more restrictive (granular). The VRF offering the different subnets still needs to import the rt's from all the other VRFs for connectivity back. Using an Export map (route-map), you set the extended community to designate an rt associated with the matching subnet.

I THINK I'm getting a better handle on VRFs as I go through these labs, I hope I can keep it up.

On to the next one.

INE Vol 1 - Lab 8 - finished - Extranet.

2009-10-22T10:52:00.000-07:00

Building off the concept of Central Services, you can use an Extranet to "leak" vrf/routes between two or more VRFs.

Since you can't establish more then 1 Route Distinguisher, you can use an "artificial" rd by route-target export/import and use the "artificial rds.

On to the next one...

INE Vol 1 - Lab 7 - finished - Central Services.

2009-10-22T07:43:00.001-07:00

Finished this lab with no issues.

Basically using importing and exporting of RD's for certain VRFs to limit communications between different sites/vrfs.

On to the next one.

INE Vol 1 - Lab 6 - finished - EBGP.

2009-10-19T07:38:00.000-07:00

Pretty straight forward, no redistribution necessary since it's bgp.

The one thing I wanted to verify was the eBGP routes on a PE. Something like "show ip bgp ipv4 vrf ... " but there's no command to do that.

Is that right?

On to the next one.