Jan
24

Just ahead of our brand new CCNA Voice live online bootcamp beginning this Monday, I thought it might be nice to provide an easy-to-follow graphic for those starting out in Voice (or on any other Cisco networking track). This graphic was from last year, but remains quite easy to follow for each and every Cisco track.

Be sure you have a high resolution set if you wish to see the entire thing, otherwise scrolling may be necessary.

Click here for the Cisco Career Certification Path poster

Sep
18

When we ask students “what are your weakest areas” or “what are your biggest areas of concern” for the CCIE Lab Exam, we typically always here non-core topics like Multicast, Security, QoS, BGP, etc. As such, INE has responded with a series of bootcamps focused on these disciplines.

The IPv4/IPv6 Multicast 3-Day live, online bootcamp, and the associated Class On-Demand version seeks to address the often confounding subject of Multicast. Detailed coverage of Multicast topics for the following certifications is provided:

Cisco Certified Network Professional (CCNP)

Cisco Certified Design Associate (CCDA)

Cisco Certified Design Professional (CCDP)

Cisco Certified Design Expert (CCDE)

Cisco Certified Internetwork Expert Routing & Switching (CCIE R&S)

Cisco Certified Internetwork Expert Service Provider (CCIE Service Provider)

Cisco Certified Internetwork Expert Security (CCIE Security)

To purchase the live and on-demand versions of the course for just an amazing $295 - just click here. The live course runs 11 AM to 6 PM EST US on September 29,30, and October 1.

The preliminary course outline is as follows:

  • Module 1 Introduction to Multicast

Lesson 1 The Need for Multicast

Lesson 2 Multicast Traffic Characteristics and Behavior

Lesson 3 Multicast Addressing

Lesson 4 IGMP

Lesson 5 Protocol Independent Multicast

  • Module 2 IGMP

Lesson 1 IGMP Version 1

Lesson 2 IGMP Version 2

Lesson 3 IGMP Version 3

Lesson 4 CGMP

Lesson 5 IGMP Snooping

Lesson 6 IGMP Optimization

Lesson 7 IGMP Security

Lesson 8 Advanced IGMP Mechanisms


  • Module 3 Protocol Independent Multicast Forms

Lesson 1 Dense Mode

Lesson 2 Sparse Mode

Lesson 3 Sparse-Dense Mode

Lesson 4 Bidirectional PIM

Lesson 5 PIM on NBMA Networks

  • Module 4 Rendezvous Points

Lesson 1 Static Configuration

Lesson 2 AUTO-RP

Lesson 3 BSR

Lesson 4 Hybrid RP Assignment Approaches

  • Module 5 Connecting PIM Domains

Lesson 1 MSDP

Lesson 2 MSDP Configurations

Lesson 3 MSDP to Anycast

  • Module 6 Multicast Tools

Lesson 1 Rate Limiting

Lesson 2 Multicasting with Tunnels

Lesson 3 Multicast Helper

Lesson 4 Miscellaneous Other Tools and Features

  • Module 7 IPv6 Multicast

Lesson 1 PIM

Lesson 2 RP Assignments

Lesson 3 MLD

Aug
30

One of the frequent questions I hear regarding L3VPNs, is regarding the bottom VPN label.  In this article, we will focus on the control plane that provides both the VPN and transit labels, and then look at the data plane that results because of those labels.

In the topology, there are 2 customer sites (bottom right, and bottom left).  The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane.   Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.

MPLS-class blog3 simple larger canvas

A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.

R1 sources net 1.1.1.1

R2 has learned the route from R1, has assigned a VPN label for it, and has exported it from the VRF into BGP.  This lucky route was assigned the local label of 16 by R2.

R2 has route in bgp and has label for it

We can also look at the MPLS forwarding table on R2 to see the same tag information.

verfy mpls forwarding table on R2

This prefix, as a VPNV4 route, is sent as an update to the iBGP peer R4.   We can force an update with refresh.

r2 clear ip bgp

The update can be seen on the wire between R2 and R3, (on its way to R4) using a protocol analyzer.  You may also notice that R2 uses outgoing label 19 for forwarding this update to 4.4.4.4   The label can be seen in the MPLS forwarding output above.

wireshard update from r2 to R4

The VPN label being advertised in the update is Label 16, which is R2's local label for the 1.1.1.1 network.

On R4, which will be the ingress PE for transit traffic destined for 1.1.1.1, we can see that the VPN label of 16 is associated with destination network of 1.1.1.1  The next hop of 2.2.2.2 to reach the 1.1.1.1 network, is due to R2 assigning next-hop-self for updates it sends to R4.

R4 has vpn label now learned from R2

We can also see the outgoing MPLS label that R4 will use to reach the next hop of 2.2.2.2.  The label of 18 below, was advertised by R3, as the label to use to reach 2.2.2.2

R4 next hop for 2.2.2.2

We can also verify that the route (1.1.1.1) has been imported by R4 into the customer vrf.

r4 vrf has 1.1.1.1

So when a transit packet is sent from R5 to 1.1.1.1, R4 should impose 2 labels.   The bottom label will be 16 (the VPN label) for the 1.1.1.1 network (R2 told us about that via the iBGP update), and the top label should be 18 (advertised via LDP from R3), to reach the next hop of 2.2.2.2

On R4 a quick check of the CEF table for the vrf can verify both labels.

cef table on R4

A simple trace from R5, to the destination network of 1.1.1.1 should prove all the labels in the path.

Trace from R5 to 1.1.1.1

The top label of 18 is used to reach the next hop of 2.2.2.2, and the bottom label of 16, which is meaningful to R2, because he sourced it, will be used by R2 in forwarding the transit traffic destined to 1.1.1.1 to the next hop, which is R1.

R3 will pop the transit label off, due to R2 advertising implicit-null for the network 2.2.2.2 (itself).

For more information and step by step training on MPLS, take a look at our newest MPLS self paced course!

If you like, an 8 minute video, that reviews the same steps, may be viewed here.

Thanks for reading!

 

Aug
26

basic.mpls.example

In this blog post we’re going to discuss the fundamental logic of how MPLS tunnels allow applications such as L2VPN & L3VPN to work, and how MPLS tunnels enable Service Providers to run what is known as the “BGP Free Core”. In a nutshell, MPLS tunnels allow traffic to transit over devices that have no knowledge of the traffic’s final destination, similar to how GRE tunnels and site-to-site IPsec VPN tunnels work. To accomplish this, MPLS tunnels use a combination of IGP learned information, BGP learned information, and MPLS labels.

In normal IP transit networks, each device in the topology makes a routing decision on a hop-by-hop basis by comparing the destination IP address of the packet to the routing or forwarding table. In MPLS networks, devices make their decision based on the MPLS label contained in the packet that is received. In this manner, MPLS enabled Label Switch Routers (LSRs for short) do not necessarily need IP routing information about all destinations, as long as they know how to forward traffic based on an MPLS label. To demonstrate how this process works, we’ll examine the above topology in two sample cases, first with normal IP packet forwarding, and secondly with IP packet forwarding plus MPLS.

In this topology R4, R5, and R6 represent the Service Provider network, while SW1 and SW2 represent customers that are using the Service Provider for transit. In each example case, the goal of our scenario will be to provide IP packet transport between the 10.1.7.0/24 network attached to SW1, and the 10.1.8.0/24 network attached to SW2.

Case 1: Normal IP Forwarding

In case 1, the devices in the topology are configured as follows. AS 100, which consists of R4, R5, and R6, runs OSPF as an IGP on all internal interfaces, along with a full mesh of iBGP. AS 7, which consists of SW1, and AS 8, which consists of SW2, peer EBGP with AS 100 via R4 and R6 respectively, and advertise the prefixes 10.1.7.0/24 & 10.1.8.0/24 respectively into BGP. The relevant device configurations are as follows. Note that these configs assume that layer 2 connectivity has already been established between the devices.

R4#
interface Loopback0
ip address 10.1.4.4 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.1.47.4 255.255.255.0
!
interface FastEthernet0/1
ip address 10.1.45.4 255.255.255.0
ip ospf 1 area 0
!
router bgp 100
neighbor 10.1.6.6 remote-as 100
neighbor 10.1.6.6 update-source Loopback0
neighbor 10.1.6.6 next-hop-self
neighbor 10.1.45.5 remote-as 100
neighbor 10.1.45.5 next-hop-self
neighbor 10.1.47.7 remote-as 7

R5#
interface FastEthernet0/0
ip address 10.1.45.5 255.255.255.0
ip ospf 1 area 0
!
interface FastEthernet0/1
ip address 10.1.56.5 255.255.255.0
ip ospf 1 area 0
!
router bgp 100
neighbor 10.1.45.4 remote-as 100
neighbor 10.1.56.6 remote-as 100

R6#
interface Loopback0
ip address 10.1.6.6 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.1.56.6 255.255.255.0
ip ospf 1 area 0
!
interface FastEthernet0/1
ip address 10.1.68.6 255.255.255.0
!
router bgp 100
neighbor 10.1.4.4 remote-as 100
neighbor 10.1.4.4 update-source Loopback0
neighbor 10.1.4.4 next-hop-self
neighbor 10.1.56.5 remote-as 100
neighbor 10.1.56.5 next-hop-self
neighbor 10.1.68.8 remote-as 8

SW1#
interface Loopback0
ip address 10.1.7.7 255.255.255.0
!
interface Vlan47
ip address 10.1.47.7 255.255.255.0
!
router bgp 7
network 10.1.7.0 mask 255.255.255.0
neighbor 10.1.47.4 remote-as 100

SW2#
interface Loopback0
ip address 10.1.8.8 255.255.255.0
!
interface Vlan68
ip address 10.1.68.8 255.255.255.0
!
router bgp 8
network 10.1.8.0 mask 255.255.255.0
neighbor 10.1.68.6 remote-as 100

Next, let’s examine the hop-by-hop packet flow as traffic moves between the 10.1.7.0/24 and 10.1.8.0/24 networks, starting at SW1 towards SW2, and then back in the reverse direction. Note that verification should be done in both directions, as packet flow from the source to destination is independent of packet flow from the destination back to the source.

SW1#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "bgp 7", distance 20, metric 0
Tag 100, type external
Last update from 10.1.47.4 00:21:13 ago
Routing Descriptor Blocks:
* 10.1.47.4, from 10.1.47.4, 00:21:13 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100

On SW1, the prefix 10.1.8.0 is learned via BGP from R4, with a next-hop of 10.1.47.4. Next, SW1 performs a second recursive lookup on the next-hop to see which interface must be used for packet forwarding.

SW1#show ip route 10.1.47.4
Routing entry for 10.1.47.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Vlan47
Route metric is 0, traffic share count is 1

The result of this lookup is that SW1 should use interface Vlan47, which connects towards R4. Assuming that underlying IP address to MAC address resolution is successful, packets going to 10.1.8.0 should be properly routed towards R4. Next, the lookup process continues on R4.

R4#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "bgp 100", distance 200, metric 0
Tag 8, type internal
Last update from 10.1.6.6 00:25:19 ago
Routing Descriptor Blocks:
* 10.1.6.6, from 10.1.6.6, 00:25:19 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 8

R4 is learning the prefix 10.1.8.0 via iBGP from R6, with a next-hop value of 10.1.6.6, R6’s Loopback0 interface. R4 must now perform an additional recursive lookup to figure out what interface 10.1.6.6 is reachable out.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.45.5 on FastEthernet0/1, 00:25:26 ago
Routing Descriptor Blocks:
* 10.1.45.5, from 10.1.6.6, 00:25:26 ago, via FastEthernet0/1
Route metric is 3, traffic share count is 1

R4 knows 10.1.6.6 via OSPF from R5, which uses interface FastEthernet0/1. Assuming layer 2 connectivity is working properly, packets towards 10.1.8.0 are now routed to R5, and the lookup process continues.

R5#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "bgp 100", distance 200, metric 0
Tag 8, type internal
Last update from 10.1.56.6 00:24:36 ago
Routing Descriptor Blocks:
* 10.1.56.6, from 10.1.56.6, 00:24:36 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 8

R5 is learning the prefix 10.1.8.0 via iBGP from R6, with a next-hop of 10.1.56.6. A recursive lookup on the next-hop, as seen below, indicates that R5 should use interface FastEthernet0/1 to forward packets towards 10.1.8.0.

R5#show ip route 10.1.56.6
Routing entry for 10.1.56.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/1
Route metric is 0, traffic share count is 1

The lookup process now continues on R6, as seen below.

R6#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "bgp 100", distance 20, metric 0
Tag 8, type external
Last update from 10.1.68.8 00:28:58 ago
Routing Descriptor Blocks:
* 10.1.68.8, from 10.1.68.8, 00:28:58 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 8

R6 is learning the prefix 10.1.8.0 via EBGP from SW2, with a next-hop of 10.1.68.8.

R6#show ip route 10.1.68.8
Routing entry for 10.1.68.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/1
Route metric is 0, traffic share count is 1

A recursive lookup on 10.1.68.8 from R6 dictates that interface FastEthernet0/1 should be used to forward traffic on to SW2.

SW2#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Advertised by bgp 8
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1

SW2’s lookup for 10.1.8.0 indicates that the destination is directly connected, and packets are routed to the final destination. For return traffic back to 10.1.7.0, a lookup occurs in the reverse direction similar to what we saw above, starting as SW2, and moving to R6, R5, R4, and then finally SW1.

This example shows how the hop-by-hop routing paradigm works in IPv4 networks. While this type of design works, one of the limitations of IPv4 forwarding is that all devices in the transit path must have routing information for all destinations they are forwarding packets towards. If AS 100 was used for Internet transit in this example, each router in the transit path would need 300,000+ routes in their routing tables in order to provide transit to all Internet destinations. This is just one of the many applications for which MPLS can be helpful. By introducing MPLS into this design, the need for large routing tables can be avoided in the core of the Service Provider network.

Case 2: MPLS Forwarding

By enabling MPLS in the Service Provider network of AS 100, BGP can be disabled in the core, lightening the load on devices that are possibly already taxed for resources. The configuration for MPLS in this scenario is very simple, but the understanding of what happens behind the scenes can be intimidating when learning the technology for the first time. To help with this learning curve, we’ll look at the step by step process that occurs when an MPLS tunnel is functional in AS 100.

The configuration changes necessary to implement MPLS in AS 100 are as follows:

R4#
mpls label protocol ldp
!
interface FastEthernet0/1
mpls ip
!
router bgp 100
no neighbor 10.1.45.5 remote-as 100

R5#
mpls label protocol ldp
!
interface FastEthernet0/0
mpls ip
!
interface FastEthernet0/1
mpls ip
!
no router bgp 100

R6#
mpls label protocol ldp
!
interface FastEthernet0/0
mpls ip
!
router bgp 100
no neighbor 10.1.56.5 remote-as 100

Once MPLS is enabled inside AS 100, BGP can be disabled on R5, and the additional BGP peering statements removed on R4 and R6. The end result of this change is surprising for some, as seen below.

R5#show ip route 10.1.7.0
% Subnet not in table
R5#show ip route 10.1.8.0
% Subnet not in table

SW1#ping 10.1.8.8 source 10.1.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Although R5 no longer has a route to the prefixes 10.1.7.0/24 or 10.1.8.0/24, it can still provide transit for traffic between them. How is this possible you may ask? The key is that an MPLS tunnel has now been formed between the ingress and egress routers of the Service Provider network, which are R4 and R6 in this case.  To see the operation of the MPLS tunnel, we'll follow the same lookup process as before, but now R4, R5, and R6 will add an additional MPLS label lookup.

Below SW1 looks up the route for 10.1.8.0/24, and finds that it recurses to R4's next-hop value reachable via the Vlan47 interface.

SW1#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "bgp 7", distance 20, metric 0
Tag 100, type external
Last update from 10.1.47.4 01:02:56 ago
Routing Descriptor Blocks:
* 10.1.47.4, from 10.1.47.4, 01:02:56 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100

SW1#show ip route 10.1.47.4
Routing entry for 10.1.47.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Vlan47
Route metric is 0, traffic share count is 1

Next, R4 receives packets for this destination and performs its own lookup.

R4#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
Known via "bgp 100", distance 200, metric 0
Tag 8, type internal
Last update from 10.1.6.6 01:05:15 ago
Routing Descriptor Blocks:
* 10.1.6.6, from 10.1.6.6, 01:05:15 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 8

Like before, R4 finds the route via BGP from R6, with a next-hop of 10.1.6.6.  R4 must now perform a recursive lookup on 10.1.6.6 to find the outgoing interface to reach R6.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.45.5 on FastEthernet0/1, 01:06:22 ago
Routing Descriptor Blocks:
* 10.1.45.5, from 10.1.6.6, 01:06:22 ago, via FastEthernet0/1
Route metric is 3, traffic share count is 1

R4's recursive lookup finds the outgoing interface FastEthernet0/1 with a next-hop of 10.1.45.5.  In normal IP forwarding, the packet would now be sent to the interface driver for layer 2 encapsulation.  However in this case, R4 first checks to see if the interface FastEthernet0/1 is MPLS enabled, as seen below.

R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/1        Yes (ldp)     No       No  No     Yes

Since interface FastEthernet0/1 is running MPLS via Label Distribution Protocol (LDP), R4 now consults the MPLS Label Forwarding Information Base (LFIB) to see if there is an MPLS label assigned to the next-hop we're trying to reach, 10.1.6.6.

R4#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.56.0/24      0             Fa0/1      10.1.45.5
17     17            10.1.6.6/32       0             Fa0/1      10.1.45.5
18     18            10.1.68.0/24      0             Fa0/1      10.1.45.5

R4 finds an entry for 10.1.6.6/32 in the LFIB, and uses the outgoing label value of 17.  This means that for traffic going to 10.1.8.0/24, the label 17 will be added to the packet header.  In reality this lookup process occurs as one step, which is the lookup in the CEF table.  The below output of the CEF table for the final destination on R4 shows that label 17 will be used, because it is inherited from the next-hop of 10.1.6.6.

R4#show ip cef 10.1.8.0 detail
10.1.8.0/24, epoch 0
recursive via 10.1.6.6
nexthop 10.1.45.5 FastEthernet0/1 label 17

Now that the MPLS label lookup is successful, the packet is label switched to R5, which leads us to the key step in this example.  When R5 receives the packet, it sees that it has an MPLS label in the header.  This means that R5 performs a lookup in the MPLS LFIB first, and not in the regular IP routing table.  Specifically R5 sees the label number 17 coming in, which has a match in the LFIB as seen below.

R5#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.4.4/32       15447         Fa0/0      10.1.45.4
17     Pop Label     10.1.6.6/32       15393         Fa0/1      10.1.56.6
18     Pop Label     10.1.68.0/24      0             Fa0/1      10.1.56.6

The local label 17 is associated with the destination 10.1.6.6/32.  Although our packets are going to the final destination 10.1.8.0/24, knowing how to get towards the next-hop 10.1.6.6/32 is sufficient for R5, because we know that R6 actually does have the route for the final destination.  Specifically R5's operation at this point is to remove the label 17 from the packet, and continue to forward the packet towards R6 without an additional label.  This operation is known as the "pop" operation, or label disposition.  This occurs because R5 sees the outgoing label as "no label", which causes it to remove any MPLS labels from the packet, and continue forwarding it.

On the return trip for packets from 10.1.8.0/24 back to 10.1.7.0/24, R6 adds the label 16 and forwards the packet to R5, then R5 removes the label 16 and forwards the packet to R4.  This can be inferred from the LFIB and CEF table verifications below.

R6#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 16 10.1.4.4/32 0 Fa0/0 10.1.56.5
17 Pop Label 10.1.45.0/24 0 Fa0/0 10.1.56.5

R6#show ip cef 10.1.7.0 detail
10.1.7.0/24, epoch 0
recursive via 10.1.4.4
nexthop 10.1.56.5 FastEthernet0/0 label 16

R5#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 No Label 10.1.4.4/32 17606 Fa0/0 10.1.45.4
17 No Label 10.1.6.6/32 17552 Fa0/1 10.1.56.6
18 Pop Label 10.1.68.0/24 0 Fa0/1 10.1.56.6

To see this operation in action, we can send traffic from 10.1.7.0/24 to 10.1.8.0/24, and look at the debug mpls packet output on R5.

R5#debug mpls packet
Packet debugging is on

SW1#ping 10.1.8.8 source 10.1.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

R5#
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data

The beauty of this MPLS design is that for any new routes AS 7 or AS 8 advertise into the network, AS 100 does not need to allocate new MPLS labels in the core.  As long as MPLS transport is established between the BGP peering address of the Provider Edge routers (R4 and R6 in this case), traffic for any destinations can transit over the Service Provider's network without the core needing any further forwarding information.

Route tag 8
R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.45.5 on FastEthernet0/1, 01:06:22 ago
Routing Descriptor Blocks:
* 10.1.45.5, from 10.1.6.6, 01:06:22 ago, via FastEthernet0/1
Route metric is 3, traffic share count is 1

R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/1        Yes (ldp)     No       No  No     Yes
R4#show mpls forw
R4#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.56.0/24      0             Fa0/1      10.1.45.5
17     17            10.1.6.6/32       0             Fa0/1      10.1.45.5
18     18            10.1.68.0/24      0             Fa0/1      10.1.45.5
R4#show ip cef 10.1.8.0 detail
10.1.8.0/24, epoch 0
recursive via 10.1.6.6
nexthop 10.1.45.5 FastEthernet0/1 label 17

We recently created a new self-paced MPLS course, which walks the learner step by step from concept to implementation for MPLS and L3 VPNs.  Click here for more information.

Aug
21

Our BGP class is coming up!  This class is for learners who are pursuing the CCIP track, or simply want to really master BGP.  I have been working through the slides, examples  and demos that we'll use in class, and it is going to be excellent.  :) If you can't make the live event, we are recording it, so it will be available as a class on demand, after the live event.    More information, can be found by clicking here.

One of the common questions that comes up is "Why does the router choose THAT route?

We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the "best" path.

bgp bestpath

So now for the question.   Take a look at the partial output of the show command below:

bgp bestpath

Regarding the 2.2.2.0/24 network, why did this router select the 192.168.68.8 next hop route, over the one just below it?

Post your ideas, and we will have a drawing next week, before the BGP class begins.   We'll give 1 lucky winner some rack tokens for our preferred rack vendor, Graded Labs.   Everyone who comments, will be entered into the drawing.  I will update the post with the lucky winner.

Thanks for your ideas, and happy learning.

Thank you to all who responded.  eBGP is preferred over iBGP, and that is what it came down to.

The winner of the graded labs tokens is Jon!  Congratulations.

Aug
16

Last week we wrapped up the MPLS bootcamp, and it was a blast!   A big shout out to all the students who attended,  as well as to many of the INE staff who stopped by (you know who you are :)).    Thank you all.

Here is the topology we used for the class, as we built the network, step by step.

MPLS-class blog

The class was organized and delivered in 30 specific lessons. Here is the "overview" slide from class:

MPLS Journey Statement

One of the important items we discussed was troubleshooting.   When we understand all the components of Layer3 VPNs, the troubleshooting is easy.   Here are the steps:

  • Can PE see CE’s routes?
  • Are VPN routes going into MP-BGP?  (The Export)
  • Are remote PEs seeing the VPN routes?
  • Are remote PEs inserting the VPN routes into the correct local VRF? (The Import)
  • Are remote PEs, advertising these to remote CEs?
  • Are the remote CEs seeing the routes?

We had lots of fun, and included wireshark protocol analysis, so we could see and verify what we were learning.   Here is one example, of a BGP updated from a downstream iBGP neighbor which includes the VPN label:

VPN Label

If you missed the class, but still want to benefit from it, we have recorded all 30 sessions, and it is available as an on-demand version of the class.

Next week, the BGP bootcamp is running, so if you need to  brush up on BGP, we will be covering the following topics, also  in 30, easy to digest lessons:

  • Monitoring and Troubleshooting BGP
  • Multi-Homed BGP Networks
  • AS-Path Filters
  • Prefix-List Filters
  • Outbound Route Filtering
  • Route-Maps as BGP Filters
  • BGP Path Attributes
  • BGP Local Preference
  • BGP Multi-Exit-Discriminator (MED)
  • BGP Communities
  • BGP Customer Multi-Homed to a Single Service Provider
  • BGP Customer Multi-Homed to Multiple Service Providers
  • Transit Autonomous System Functions
  • Packet Forwarding in Transit Autonomous Systems
  • Monitoring and Troubleshooting IBGP in Transit AS
  • Network Design with Route Reflectors
  • Limiting the Number of Prefixes Received from a BGP Neighbor
  • AS-Path Prepending
  • BGP Peer Group
  • BGP Route Flap Dampening
  • Troubleshooting Routing Issues
  • Scaling BGP

I look forward to seeing you in class!

Best wishes in all of your learning.

Jul
24

Are you wondering what the month of August 2010 will bring for INE fans?

Try all new, online bootcamps in the following disciplines:

  • MPLS
  • BGP
  • CCNA
  • CCNP
  • CCDA

Watch the blog and your email for all of the exciting new details.

Join the INE Experts Online in August

May
09

INE is thrilled to announce the Live Online 5-Day QoS bootcamp. The course begins June 7, 2010 at 11 AM EST US. This course includes:

  • The Live Online class
  • The Recorded Online class
  • An interactive, self-paced version
  • An audio bootcamp version
  • A full Implementing QoS practice exam with a Tell Me Why PDF

Click here to sign up right now!

This one-of-a-kind course is targeted at CCIE R&S, Voice, Wireless, and Security candidates, as well as students pursuing their CCIP professional-level certification. Here is the course At A Glance:

Module 1 Overview of QoS

Module 2 Components of QoS

Module 3 The MQC

Module 4 Classification and Marking

Module 5 Congestion Management

Module 6 Congestion Avoidance

Module 7 Policing and Shaping

Module 8 Link Efficiency

Module 9 AutoQoS

Module 10 QoS on Cisco Security Equipment

Module 11 QoS and Wireless

Subscribe to INE Blog Updates

New Blog Posts!