Sei sulla pagina 1di 123

Introduction to MPLS

18 votes

To understand MPLS there are two questions we need to answer:

What is MPLS?

Why do we need MPLS?

I’m going to start this lesson with an explanation of why we need it and how MPLS solves some of the issues of other protocols, this will help you to understand why we use MPLS. In the second part of this lesson you will learn what MPLS is and how it actually works.

When you want to learn MPLS, you need to be very familiar with the following topics before you continue:

Having said that, let’s get started!

Why do we need MPLS?

Take a look at the following picture:

Above we have an example of an ISP with two customers called “A” and “B”. The ISP only offers Internet connectivity and no other services. Each customer uses the ISP to have connectivity between their sites.

To accomplish our goal, the ISP is running eBGP between the CE (Customer Edge) and PE (Provider Edge) to exchange prefixes. This means all internal (P) routers of the ISP have to run iBGP or they don’t know where to forward their packets to. A full internet routing table currently has > 500.000 prefixes and with 8 ISP routers running iBGP, we need 28 iBGP peerings. We can reduce this number by using route

reflectors or a confederation. All routers have to do lookups in the routing table for any possible destination. Now here’s something to think about…when our goal is to have connectivity between two customer sites, why should all internal P routers know about this? The only routers that need to know how to reach the customer sites are the PE routers of the provider. Why not build a tunnel between the PE routers? Take a look at the picture below:

In the picture above I added two GRE tunnels:

The two PE routers at the top will use a GRE tunnel for the customer A sites.

The two PE routers at the bottom will use a GRE tunnel for the customer B sites.

With a solution like this, we can have a BGP free core! There’s only two places where we need BGP:

eBGP between the PE and CE router.

iBGP between two PE routers.

Let’s take a closer look at the solution I described above.

Tunnel between PE routers

Let’s take a look at the example above in action. I will use the following topology for this:

The topology above is a smaller version of the topology I showed you before. This is

The topology above is a smaller version of the topology I showed you before. This is the ISP with only one customer. We’ll use a GRE tunnel between PE1 and PE2 so that we don’t need iBGP on the P router. Let me walk you through the entire configuration…

OSPF Configuration

First we will configure OSPF on all ISP routes so that PE1 and PE2 are able to reach each other. I’ve added some loopback interfaces on the ISP routers that will be advertised as well:

 

PE1(config)#router ospf 1

 

PE1(config-router)#network 192.168.23.0 0.0.0.255 area 0 PE1(config-router)#network 2.2.2.2 0.0.0.0 area 0 P(config)#router ospf 1 P(config-router)#network 192.168.23.0 0.0.0.255 area 0 P(config-router)#network 192.168.34.0 0.0.0.255 area 0 P(config-router)#network 3.3.3.3 0.0.0.0 area 0 PE2(config)#router ospf 1 PE2(config-router)#network 192.168.34.0 0.0.0.255 area 0

 
 

PE1(config-router)#network 4.4.4.4 0.0.0.0 area 0

That takes care of all internal routing for the ISP.

eBGP Configuration

Let’s continue by configuring eBGP between the CE and PE routers. We will advertise a loopback on each CE router:

 

CE1(config)#router bgp 10

 

CE1(config-router)#neighbor 192.168.12.2 remote-as 1234 CE1(config-router)#network 1.1.1.1 mask 255.255.255.255 PE1(config)#router bgp 1234 PE1(config-router)#neighbor 192.168.12.1 remote-as 10 PE2(config)#router bgp 1234 PE2(config-router)#neighbor 192.168.45.5 remote-as 20 CE2(config)#router bgp 20 CE2(config-router)#neighbor 192.168.45.4 remote-as 1234

 
 

CE2(config-router)#network 5.5.5.5 mask 255.255.255.255

That takes care of eBGP.

GRE Tunnel Configuration

Now we can configure the GRE tunnel between PE1 and PE2. I will use their loopback interfaces as the source and destination. We will use the 192.168.24.0 /24 subnet on the tunnel interfaces:

 

PE1(config)#interface tunnel 0

 

PE1(config-if)#tunnel source 2.2.2.2 PE1(config-if)#tunnel destination 4.4.4.4 PE1(config-if)#ip address 192.168.24.2 255.255.255.0 PE2(config)#interface tunnel 0 PE2(config-if)#tunnel source 4.4.4.4 PE2(config-if)#tunnel destination 2.2.2.2

 
 

PE2(config-if)#ip address 192.168.24.4 255.255.255.0

Now we have a working GRE tunnel.

iBGP Configuration

With the GRE tunnel up and running, we can configure iBGP between the two PE routers:

 

PE1(config)#router bgp 1234

 

PE1(config-router)#neighbor 192.168.24.4 remote-as 1234 PE1(config-router)#neighbor 192.168.24.4 next-hop-self PE2(config)#router bgp 1234 PE2(config-router)#neighbor 192.168.24.2 remote-as 1234

 
 

PE2(config-router)#neighbor 192.168.24.2 next-hop-self

Our PE routers will establish an iBGP peering using the IP addresses on the GRE tunnel.

I also could have established iBGP between the loopback interfaces of PE1 and PE2 instead of the IP addresses of the tunnel interfaces. The advantage is that BGP traffic between PE1 and PE2 wouldn’t be encapsulated by GRE. The downside however is that you will need to configure a route-map that changes the next hop IP address of all prefixes learned through BGP to the IP addresses of the tunnel interfaces.

Our configuration is now complete. Let’s find out if it works shall we?

Verification

I’ll do a trace from CE1 to CE2:

 

CE1#traceroute 5.5.5.5 source loopback 0

 

Type escape sequence to abort.

 
 

Tracing the route to 5.5.5.5

 

VRF info: (vrf in name/id, vrf out name/id)

 
  • 1 192.168.12.2 0 msec 0 msec 0 msec

 
  • 2 192.168.24.4 0 msec 0 msec 4 msec

 
  • 3 192.168.45.5 0 msec 0 msec *

Great, it’s working! The ISP has a BGP-free core. Here’s what an IP packet from CE1 to CE2 looks like to the P router:

The outer IP header has source address 2.2.2.2 and destination address 4.4.4.4, the P router knows how to route these since it learned these addresses through OSPF.

Great! Now you might be thinking…so what? Where’s MPLS?

For now, keep in mind that tunneling is used to create a BGP free core. Hold this

thought while you read the next section of this lesson where we finally start talking about MPLS!

What is MPLS?

In the previous example I used a GRE tunnel but I could have used any tunneling mechanism. Besides GRE, there’s IP-in-IP, Q-in-Q and…

MPLS (Multi Protocol Label Switching).

What does multi protocol label switching mean?

Multi protocol: besides IP you can tunnel pretty much anything…IP, IPv6,

Ethernet, PPP, frame-relay, etc. Label switching: forwarding is done based on labels, not by looking up the destination in the routing table.

MPLS can do anything that any of the other tunneling protocols support and it can do a lot more than that.

Let’s start with something simple, let’s replace the GRE tunnel from the previous example with MPLS so I can explain how MPLS uses labels.

First let’s get rid of the GRE tunnel and the BGP peering between PE1 and PE2:

 

PE1 & PE2

 

(config)#no interface tunnel 0 PE1(config)#router bgp 1234 PE1(config-router)#no neighbor 192.168.24.4 remote-as 1234 PE2(config)#router bgp 1234

 
 

PE2(config-router)#no neighbor 192.168.24.2 remote-as 1234

Now we can start with the MPLS configuration.

iBGP configuration

Once again I will configure iBGP between PE1 and PE2 but this time I will use their loopback interfaces. You will see why in a minute:

 

PE1(config)#router bgp 1234

 

PE1(config-router)#neighbor 4.4.4.4 remote-as 1234 PE1(config-router)#neighbor 4.4.4.4 update-source loopback 0 PE1(config-router)#neighbor 4.4.4.4 next-hop-self PE2(config)#router bgp 1234 PE2(config-router)#neighbor 2.2.2.2 remote-as 1234 PE2(config-router)#neighbor 2.2.2.2 update-source loopback 0

 
 

PE2(config-router)#neighbor 2.2.2.2 next-hop-self

That takes care of iBGP.

MPLS Configuration

This is the exciting part, let’s enable MPLS. We’ll do this on all interfaces that connect PE1, PE2 and the P router:

 

PE1(config)#interface FastEthernet 0/1

 

PE1(config-if)#mpls ip P(config)#interface FastEthernet 0/0 P(config-if)#mpls ip P(config)#interface FastEthernet 0/1 P(config-if)#mpls ip PE2(config)#interface FastEthernet 0/0

 
 

PE2(config-if)#mpls ip

That’s pretty simple…only one command to activate MPLS on our interfaces. In the next lesson I will explain what exactly happens when you use this command, for now I want to focus on the labels.

Verification

Let’s try a quick ping between CE1 and CE2:

 

CE1#ping 5.5.5.5 source loopback 0

 

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:

 

Packet sent with a source address of 1.1.1.1 !!!!!

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Great, it works. Why does it work? Keep in mind there is no iBGP on the P router:

 

P#show ip cef 5.5.5.5

 

0.0.0.0/0

 
 

no route

Normally this traffic should be dropped since this router has no idea how it can reach 5.5.5.5. However, since we enabled MPLS we are now using labels for our forwarding decisions. Let me explain how that works.

Let’s start with PE1:

 

Known via "bgp 1234", distance 200, metric 0

 

Tag 5, type internal Last update from 4.4.4.4 00:20:16 ago Routing Descriptor Blocks:

 

* 4.4.4.4, from 4.4.4.4, 00:20:16 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 5

 

MPLS label: none

To reach 5.5.5.5, we have to use 4.4.4.4 as the next hop. Instead of checking the routing table, let’s take a look at the MPLS forwarding table:

 

PE1#show mpls forwarding-table

 
 

Local

Outgoing

Prefix

Bytes Label

Outgoing

 

Next Hop

Label

Label

or Tunnel Id

Switched

interface

  • 16 4.4.4.4/32

17

0

Fa0/1

192.168.23.3

 
  • 17 Pop Label 192.168.34.0/24

0

Fa0/1

192.168.23.3

 
 
  • 18 Pop Label 3.3.3.3/32

0

Fa0/1

192.168.23.3

 

Above you can see the labels that this router uses to reach certain prefixes. In the next lesson we’ll discuss how these labels are generated. To reach 4.4.4.4, this router will add label 17 to the IP packet and forwards it on FastEthernet 0/1 (towards the P router). A quicker method to see what labels are used for different prefixes is by checking the CEF table:

 

PE1#show ip cef 5.5.5.5

 

5.5.5.5/32

 
 

nexthop 192.168.23.3 FastEthernet0/1 label 17

Here’s a capture of the IP packet that PE1 sends to the P router:

You can see that the MPLS header has been added in between the Ethernet and IP header. This is why they call MPLS a layer 2.5 protocol.

So what happens when the P router receives this IP packet? It’s using MPLS for forwarding decisions so let’s take a look at its labels:

 

P#show mpls forwarding-table

 
 

Local

Outgoing

Prefix

Bytes Label

Outgoing

 

Next Hop

Label

Label

or Tunnel Id

Switched

interface

16

Pop Label 2.2.2.2/32

152492

Fa0/0

192.168.23.2

 
 

17

Pop Label 4.4.4.4/32

153234

Fa0/1

192.168.34.4

 

When the P router receives something that is tagged with label 17, then it has to be forwarded to 4.4.4.4. It’s outgoing label says “pop label” which means to remove the label.

PE2 will receive a regular IP packet (without label) with destination 5.5.5.5 and it will forward it using the routing table towards CE2.

When CE2 receives the packet, it will create an ICMP echo reply which will end up at PE2. Here’s what PE2 will do with it:

 

PE2#show ip route 1.1.1.1

 

Routing entry for 1.1.1.1/32 Known via "bgp 1234", distance 200, metric 0 Tag 1, type internal Last update from 2.2.2.2 00:31:34 ago Routing Descriptor Blocks:

 

* 2.2.2.2, from 2.2.2.2, 00:31:34 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 1

 

MPLS label: none

PE2 knows that it has to use next hop 2.2.2.2 to reach 1.1.1.1. Let’s check what label we will use to reach 2.2.2.2:

 

PE2#show mpls forwarding-table

 
 

Local

Outgoing

Prefix

Bytes Label

Outgoing

 

Next Hop

Label

Label

or Tunnel Id

Switched

interface

  • 16 2.2.2.2/32

16

0

Fa0/0

192.168.34.3

 
  • 17 Pop Label 192.168.23.0/24

0

Fa0/0

192.168.34.3

 
 
  • 18 Pop Label 3.3.3.3/32

0

Fa0/0

192.168.34.3

 

PE2 will add label 16 to the IP packet and will forward it out the FastEthernet 0/0 interface towards the P router. Looking at the CEF table is a quicker method to find the label for a destination prefix:

 

PE2#show ip cef 1.1.1.1

 

1.1.1.1/32

 
 

nexthop 192.168.34.3 FastEthernet0/0 label 16

The PE2 router will forward it to the P router. Let’s check what it will do with this packet:

 

P#show mpls forwarding-table

 
 

Local

Outgoing

Prefix

Bytes Label

Outgoing

 

Next Hop

Label

Label

or Tunnel Id

Switched

interface

16

Pop Label 2.2.2.2/32

154767

Fa0/0

192.168.23.2

 
 

17

Pop Label 4.4.4.4/32

155528

Fa0/1

192.168.34.4

 

Router P sees that anything with label 16 should be forwarded on the FastEthernet 0/0 interface. It will remove the label and forwards it to PE1.

PE1 can then forward the IP packet (without label) using its routing table to CE1.

That’s how we use MPLS to tunnel traffic between PE routers, creating a BGP free

core.

Conclusion

I hope this lesson has been useful to get a basic understanding of why we use MPLS and how it uses labels as a tunneling mechanism to create a BGP free core. There’s a lot more to this story. In other lessons you will learn:

How MPLS routers generate/exchange labels using LDP.

How to build MPLS VPNs

How to tunnel Ethernet or frame-relay over your MPLS network.

And more…

If you have any questions, feel free to leave a comment!

Rate this Lesson:

MPLS Labels and Devices

8 votes

In my introduction to MPLS I explained why we use MPLS and explained some of the basics of how we use labels for forwarding decisions. In this lesson, we’ll take a closer look at the MPLS labels, the devices that we use and how IP packets travel through the MPLS network.

MPLS Label Format

The MPLS header has been standardized, you can find it in RFC 3032. The header is pretty simple, here’s what it looks like:

Here’s what the different fields are used for:

Label value: the name says it all, this is where you will find the value of the label.

EXP: these are the three experimental bits. These are used for QoS, normally the IP

precedence value of the IP packet will be copied here. S: this is the “bottom of stack” bit. With MPLS it’s possible to add more than one label,

you’ll see why in some of the MPLS VPN lessons. When this bit is set to one, it’s the last MPLS header. When it’s set to zero then there is one or more MPLS headers left. TTL: just like in the IP header, this is the time to live field. You you can use this for traces in the MPLS network. Each hop decrements the TTL by one.

The MPLS header is added in between the L2 and L3 header:

That’s why we call it a “layer 2.5” protocol. Here’s an example of what it looks like in wireshark:

Above you have an example of the MPLS header in between the Ethernet and IP header. You can also see the different fields, this header uses label value 16. We don’t use QoS and since there is only one MPLS header, the bottom of label stack bit has been set.

Where did the label value come from? MPLS uses a protocol called LDP (Label Distribution Protocol) for this. You will learn about it in the next lesson.

MPLS Devices and Operations

Now you know what the MPLS labels look like, let’s talk about a bit about the different devices you will encounter in a MPLS network. Here’s an overview:

Above you have an example of the MPLS header in between the Ethernet and IP header.

Above you will find three different routers:

CE (Customer Edge): this device is the last device in the customer’s network, it could be a

L2 or L3 device. In my picture I used a router but for example, it could be a switch. This device does not use MPLS. PE (Provider Edge): this device is owned by the ISP and sits at the edge of the ISP’s

network. It has an important role…it receives packets or frames from the customer and will then add a MPLS label to it and forwards towards the core. Another common name for this device is LER (Label Edge Router). P (Provider): this device connects to PE routers and other P routers. It has a simple job, it switches packets based on their labels or removes the labels. Another common name for this device is theLSR (Label Switch Router) or transit router.

There are three actions we can perform with labels:

Label push: when we add a label to a packet, we call it a label push.

Label swap: replacing a label with another value is called a label swap.

Label pop: removing the label is called a label pop.

Let's look at an example of how labels are pushed, swapped and popped in a MPLS network:

Let me add some more detail to the picture above:

  • 1. The CE1 router is owned by the customer and connected to the ISP's PE1 router. This device doesn't have a clue what MPLS is and sends an IP packet that should end up at CE2 (another site of the customer).

3.

P1 receives the labeled packet from PE1, swaps the label and forwards it to P2. Labels are only locally significant, we'll talk more about this in the next lesson.

  • 4. P2 receives the labeled packet from P1, swaps the label and forwards it to P3.

  • 5. P3 receives the labeled packet and will pop the label, forwarding the IP packet to PE2. This is called penultimate hop popping and is performed to save PE2 the trouble of looking at the MPLS label.

  • 6. PE2 receives the IP packet and forwards it to the CE2 router.

  • 7. The CE2 router receives the IP packet and the customer is happy.

The label swapping that the P routers perform is similar to how a frame-relay switch behaves. A frame with a DLCI number comes in on one interface and is switched to another interface with a different DLCI number.

Conclusion

You have now seen what the MPLS header looks like, the different devices and their role in the MPLS network. You have also seen an example of how labels are pushed, swapped and popped. In the next lesson we will take a close look at LDP (Label Distribution Protocol) where you will learn where the different label values come from.

I hope you enjoyed this lesson, if you have any questions comment.

...

feel free to leave a

Rate this Lesson:

MPLS LDP (Label Distribution Protocol)

10 votes

LDP is a protocol that automatically generates and exchanges labels between routers. Each router will locally generate labels for its prefixes and will then advertise the label values to its neighbors.

It’s a standard, based on Cisco’s proprietary TDP (Tag Distribution Protocol). It’s pretty much the same story as 802.1Q/ISL or PaGP/LACP. Cisco created a protocol and a standard was created later. Nowadays almost everyone uses LDP instead of TDP.

Like many other protocols, LDP first establishes a neighbor adjacency before it exchanges label information. It works a bit different than most protocols though… First we send UDP multicast hello packets to discover other neighbors. Once two routers decide to become neighbors, they build the neighbor adjacency using a TCP

connection. This connection is then used for the exchange of label information.

Normally a loopback interface is used for the neighbor adjacency. Here’s an example:

The two routers above will send multicast hello packets on their FastEthernet interfaces. Within this hello

The two routers above will send multicast hello packets on their FastEthernet interfaces. Within this hello packet, they will advertise a transport IP address. This IP address is then used to establish the TCP connection between the two routers. Here’s what the hello packet looks like in wireshark:

In the capture above you can see a couple of interesting things:

The hello packets are sent to multicast address 224.0.0.2 using source/destination UDP port

646.

Each router has a unique ID called the LSR (Label Switch Router) ID. This is similar to

how most protocols select an ID, by default it will select the highest IP address on a loopback interface. If you don’t have any loopback interfaces then we will use the highest IP address on a physical interface. At the bottom you find the transport address. This is what we use to build the actual TCP connection. Like the LSR ID, the router selected the IP address on the loopback interface as the transport address.

Make sure that the IP address that LDP has selected for the transport address is advertised in your routing protocol. Otherwise your routers will be able to hear each others hello packets but they can’t form a neighbor adjacency since the transport address(es) are unreachable.

This is different compared to how routing protocols like OSPF or EIGRP form neighbor adjacencies. For example, when you run OSPF then your routers will form neighbor adjacencies on all interfaces that run OSPF:

LDP will only form a single neighbor adjacency, no matter how many interfaces you have iny CEF tutorial first before you continue. " id="pdf-obj-23-2" src="pdf-obj-23-2.jpg">

LDP will only form a single neighbor adjacency, no matter how many interfaces you have in between your routers:

LDP will only form a single neighbor adjacency, no matter how many interfaces you have iny CEF tutorial first before you continue. " id="pdf-obj-23-6" src="pdf-obj-23-6.jpg">

LDP is a bit similar to BGP when you use the loopback interfaces for the neighbor adjacency. When we use BGP we have to use the update-source command to select the source, LDP does it automatically.

So once our LDP routers have become neighbors, how do we exchange label information? To explain this, let’s do a quick review of how normal routing uses the RIB and FIB. If you have no idea what these two are then I recommend you to read my CEF tutorial first before you continue.

With normal routing, we use routing protocols like EIGRP, OSPF or BGP to learn prefixes from

With normal routing, we use routing protocols like EIGRP, OSPF or BGP to learn prefixes from other routers. These are all stored in the RIB (Routing Information Base), this is your routing table. The information in the RIB is used to build the FIB (Forwarding Information Base) which is what we use for actual forwarding of IP packet. These tables are all used for IP packets but for MPLS we use something else:

When we use LDP, we locally generate a label for each prefix that we can find in the RIB. This information is then added to the LIB (Label Information Base). The information in the LIB is used to build the LFIB (Label Forwarding Information Base). When the router has to forward a packet with a MPLS label on it, it will use the LFIB for forwarding decisions. The LIB is similar to the RIB but it's used to store labels for prefixes. The LFIB is similar to the FIB, it's used for actual forwarding of MPLS packets.

Two routers that have formed a LDP neighbor adjacency will exchange the label information in their LIBs to tell each other what label values to use for different prefixes.

All routers running LDP will now know what label values to use when they switch a

All routers running LDP will now know what label values to use when they switch a MPLS packet to their neighbor.

Now you have an idea what LDP is about, let's take a look at it in action. I will also show you the different tables that I just described.

Configuration

I will use the following three routers to demonstrate LDP:

Each router has a loopback interface that we will use for the LDP neighbor adjacency. LDP will select the IP addresses on the loopback interfaces as the LSR

IDs and the transport addresses. We also need the information in the RIB to build the LIB so I'll configure OSPF to advertise all prefixes.

OSPF Configuration

Let's advertise all interfaces:

 

R1(config)#router ospf 1

 

R1(config-router)#network 192.168.12.0 0.0.0.255 area 0 R1(config-router)#network 1.1.1.1 0.0.0.0 area 0 R2(config)#router ospf 1 R2(config-router)#network 192.168.12.0 0.0.0.255 area 0 R2(config-router)#network 192.168.23.0 0.0.0.255 area 0 R2(config-router)#network 2.2.2.2 0.0.0.0 area 0 R3(config)#router ospf 1 R3(config-router)#network 192.168.23.0 0.0.0.255 area 0

 
 

R3(config-router)#network 3.3.3.3 0.0.0.0 area 0

That's all we need.

LDP Configuration

There are two ways to configure LDP:

On the interface level with the mpls ip command.

Globally under the OSPF process with the mpls ldp autoconfig command.

It doesn't matter much which one you pick, by default LDP will create a label for each prefix. I'll enable it on the interfaces this time:

 

R1(config)#interface FastEthernet 0/0

 

R1(config-if)#mpls ip R2(config)#interface FastEthernet 0/0 R2(config-if)#mpls ip R2(config)#interface FastEthernet 0/1 R2(config-if)#mpls ip R3(config)#interface FastEthernet 0/0

 
 

R3(config-if)#mpls ip

After a few seconds you will see a message on the consoles telling you that the neighbor is up:

R1#

%LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP

That's all you have to do to enable LDP. Let's verify our work!

Verification

The messages on the console(s) revealed to us that we have a neighbor adjacency but it still might be useful to check some things yourself.

LDP Neighbor Adjacency

First let's check if LDP is enabled on the interface:

 

R1#show mpls interfaces

 

Interface Operational

IP

Tunnel

BGP Static

   

FastEthernet0/0

Yes (ldp)

No

No

No

Yes

R2#show mpls interfaces Interface Operational

IP

Tunnel

BGP Static

FastEthernet0/0

Yes (ldp)

No

No

No

Yes

FastEthernet0/1

Yes (ldp)

No

No

No

Yes

R3#show mpls interfaces Interface Operational

IP

Tunnel

BGP Static

 

FastEthernet0/0

Yes (ldp)

No

No

No

Yes

The show mpls interfaces command is a quick way to see if LDP is enabled or not. It tells us what interfaces are enabled and if they are operational or not. The next thing to check is if we have LDP neighbors or not:

 

R2#show mpls ldp neighbor

 

Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0 TCP connection: 3.3.3.3.40724 - 2.2.2.2.646

 

State: Oper; Msgs sent/rcvd: 32/32; Downstream Up time: 00:20:12

LDP discovery sources:

FastEthernet0/1, Src IP addr: 192.168.23.3

Addresses bound to peer LDP Ident:

 

192.168.23.3

192.168.34.3

3.3.3.3

 

Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0

 
 

TCP connection: 1.1.1.1.646 - 2.2.2.2.46288

 
 

State: Oper; Msgs sent/rcvd: 26/26; Downstream Up time: 00:16:37

 

LDP discovery sources:

FastEthernet0/0, Src IP addr: 192.168.12.1

Addresses bound to peer LDP Ident:

 

1.1.1.1

192.168.12.1

Above you see the output of R2, here's what you see:

R2 and R3 have become neighbors:

 

o

R2 uses 2.2.2.2 as its LSR ID, R3 uses 3.3.3.3 as the LSR ID.

R2 uses 2.2.2.2 as its LSR ID, R1 uses 1.1.1.1 as the LSR ID.

o

R2 and R3 have formed a TCP connection using 2.2.2.2 and 3.3.3.3 as the transport

o

addresses. Discovery (hello packets) was done using the FastEthernet0/1 interface.

R1 and R2 have become neighbors:

 

o

o

R1 and R2 have formed a TCP connection using 2.2.2.2 and 1.1.1.1 as the transport

o

addresses. Discovery (hello packets) was done using the FastEthernet0/0 interface.

Now we have confirmed that we have LDP neighbors, let's look at the labels.

LDP Control Plane

When you use LDP, all routers will start assigning labels with label value 16. This might be a bit annoying if you are new to MPLS as some routers will use the same label value. To make it easier to read the different tables I will configure each router to use different label values. Here's how to do this:

 

R1(config)#mpls label range 100 199

 

R2(config)#mpls label range 200 299

 
 

R3(config)#mpls label range 300 399

When you use this command you will have to reload the routers, clearing the neighbor adjacency is not enough. Let's take a look at some labels. Since the LIB is built with information from the RIB, we will start with the routing table. Here's R1:

 

1.0.0.0/32 is subnetted, 1 subnets

 

C

1.1.1.1 is directly connected, Loopback0

 

O

2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/2] via 192.168.12.2, 00:36:02,

FastEthernet0/0

3.0.0.0/32 is subnetted, 1 subnets

O

3.3.3.3 [110/3] via 192.168.12.2, 00:36:02,

FastEthernet0/0

192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks

C

192.168.12.0/24 is directly connected, FastEthernet0/0

L

192.168.12.1/32 is directly connected, FastEthernet0/0

 

O

192.168.23.0/24 [110/2] via 192.168.12.2, 00:36:02,

 

FastEthernet0/0

Above you can see the prefixes in the routing table. Here's what the LIB looks like:

 

R1#show mpls ldp bindings

 

lib entry: 1.1.1.1/32, rev 4 local binding: label: imp-null

 

remote binding: lsr: 2.2.2.2:0, label: 200 lib entry: 2.2.2.2/32, rev 6

local binding:

label: 100

remote binding: lsr: 2.2.2.2:0, label: imp-null

lib entry: 3.3.3.3/32, rev 10

local binding:

label: 102

remote binding: lsr: 2.2.2.2:0, label: 201

lib entry: 192.168.12.0/24, rev 2

local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 192.168.23.0/24, rev 8

local binding:

label: 101

 

remote binding: lsr: 2.2.2.2:0, label: imp-null

 

Above you can see the LIB of R1. Let's walk through some of the things we see here:

The first entry is for 1.1.1.1/32, the loopback interface of R1. This router doesn't generate a

R2.

label value for this entry since it's directly connected. You can see however that R2 has advertised to R1 that it uses label value 200 for this prefix. The second entry is for 2.2.2.2/32. R1 has chosen label value 100 for this entry, we can also

see that R2 doesn't use a label for this prefix. This makes sense since it's directly connected for

The third entry for 3.3.3.3/32 has a local label value of 102. R2 is using label value 201 for

this entry. The fourth entry is 192.168.12.0/24. We don't use a label for this entry since it's directly connected. R2 also doesn't use a label value since it's directly connected there as well.

The fifth entry is for 192.168.23.0/24, R1 uses label value 101 for this one.

Now let's take a look at the LFIB, that's what we will actually use when we forward MPLS packets:

 

R1#show mpls forwarding-table

 
 

Local

Outgoing

Prefix

Bytes Label

Outgoing

 

Next Hop

Label

Label

or Tunnel Id

Switched

interface

  • 100 Pop Label 2.2.2.2/32

0

Fa0/0

192.168.12.2

  • 101 192.168.23.0/24 0

Pop Label

 

Fa0/0

192.168.12.2

 
  • 102 3.3.3.3/32

201

0

Fa0/0

192.168.12.2

The LFIB is much smaller, keep in mind that this is similar to the CEF table that we use for IP forwarding. There is no entry for 1.1.1.1 /32 or 192.168.12.0 /24 here since we don't have a label for these prefixes. When we want to reach 3.3.3.3 /32 then we will add label value 201 to the MPLS header before we send it to R2.

When R1 receives something for 2.2.2.2/32 or 192.168.23.0/24 then we will "pop the label" before we forward it to R2. This is called penultimate hop popping. I'll explain this in more detail in another post, it's done to save R2 some time by already removing the MPLS header. Let me also show you the RIB, LIB and LFIB of R2 and R3:

 

R2#show ip route

 

O

1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/2] via 192.168.12.1, 00:44:37,

 

FastEthernet0/0

2.0.0.0/32 is subnetted, 1 subnets

C

2.2.2.2 is directly connected, Loopback0

O

3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/2] via 192.168.23.3, 02:55:40,

FastEthernet0/1

192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks

  • C 192.168.12.0/24 is directly connected, FastEthernet0/0

 
  • L 192.168.12.2/32 is directly connected, FastEthernet0/0

 
 

192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks

 
 
  • C 192.168.23.0/24 is directly connected, FastEthernet0/1

 
  • L 192.168.23.2/32 is directly connected, FastEthernet0/1 R2#show mpls ldp bindings

lib entry: 1.1.1.1/32, rev 8

 

local binding:

label: 200

remote binding: lsr: 3.3.3.3:0, label: 301 remote binding: lsr: 1.1.1.1:0, label: imp-null lib entry: 2.2.2.2/32, rev 6 local binding: label: imp-null remote binding: lsr: 3.3.3.3:0, label: 300 remote binding: lsr: 1.1.1.1:0, label: 100 lib entry: 3.3.3.3/32, rev 10

 

local binding:

label: 201

remote binding: lsr: 3.3.3.3:0, label: imp-null remote binding: lsr: 1.1.1.1:0, label: 102 lib entry: 192.168.12.0/24, rev 2 local binding: label: imp-null remote binding: lsr: 3.3.3.3:0, label: 302 remote binding: lsr: 1.1.1.1:0, label: imp-null lib entry: 192.168.23.0/24, rev 4 local binding: label: imp-null remote binding: lsr: 3.3.3.3:0, label: imp-null remote binding: lsr: 1.1.1.1:0, label: 101

 

lib entry: 192.168.34.0/24, rev 11 remote binding: lsr: 3.3.3.3:0, label: imp-null R2#show mpls forwarding-table

Local

Outgoing

Prefix

Bytes Label

Outgoing

Next Hop

Label

Label

or Tunnel Id

Switched

interface

  • 200 Pop Label 1.1.1.1/32

0

Fa0/0

192.168.12.1

 
  • 201 Pop Label 3.3.3.3/32

126

Fa0/1

192.168.23.3

And here's R3:

 

R3#show ip route

 

O

1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/3] via 192.168.23.2, 00:45:50,

 

FastEthernet0/0

2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/2] via 192.168.23.2, 02:57:05,

 

FastEthernet0/0

 

3.0.0.0/32 is subnetted, 1 subnets

 

C

3.3.3.3 is directly connected, Loopback0

 
 

O

192.168.12.0/24 [110/2] via 192.168.23.2, 00:45:50,

 

FastEthernet0/0

 
 

192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks

  • C 192.168.23.0/24 is directly connected, FastEthernet0/0

  • L 192.168.23.3/32 is directly connected, FastEthernet0/0

 

192.168.34.0/24 is variably subnetted, 2 subnets, 2 masks

  • C 192.168.34.0/24 is directly connected, FastEthernet0/1

  • L 192.168.34.3/32 is directly connected, FastEthernet0/1 R3#show mpls ldp bindings

lib entry: 1.1.1.1/32, rev 10

 
 

local binding:

label: 301

remote binding: lsr: 2.2.2.2:0, label: 200 lib entry: 2.2.2.2/32, rev 8

 
 

local binding:

label: 300

remote binding: lsr: 2.2.2.2:0, label: imp-null

 

lib entry: 3.3.3.3/32, rev 6 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: 201 lib entry: 192.168.12.0/24, rev 12

 

local binding:

label: 302

remote binding: lsr: 2.2.2.2:0, label: imp-null

 

lib entry: 192.168.23.0/24, rev 2 local binding: label: imp-null

 

remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 192.168.34.0/24, rev 4 local binding: label: imp-null R3#show mpls forwarding-table

 

Local Outgoing Prefix Next Hop

Bytes Label

Outgoing

Label

Label

or Tunnel Id

Switched

interface

  • 300 Pop Label 2.2.2.2/32

0

Fa0/0

192.168.23.2

 
  • 301 200

1.1.1.1/32

0

Fa0/0

192.168.23.2

 
 
  • 302 Pop Label 192.168.12.0/24

0

Fa0/0

192.168.23.2

 

LDP Data Plane

All these tables allow us to check the control plane but what about the data plane? We can use a quick traceroute to see if we are using label switching:

 

R1#traceroute 3.3.3.3 source 1.1.1.1

 

Type escape sequence to abort.

 
 

Tracing the route to 3.3.3.3

 

VRF info: (vrf in name/id, vrf out name/id)

 
  • 1 192.168.12.2 [MPLS: Label 201 Exp 0] 0 msec 0 msec 4 msec

 
 
  • 2 192.168.23.3 0 msec 0 msec *

When you use traceroute on your MPLS devices then you can see the labels that we use. The path that we use here is called the LSP (Label Switched Path).

Conclusion

You have now learned how LDP uses multicast to send hello packets to discover other LDP routers. You have seen how we establish a neighbor adjacency using a TCP connection and the transport addresses in the hello packet.

We also discussed the different tables that we use for IP and MPLS forwarding. Last but not least, you have seen some of the labels in action. I can recommend you to boot up some routers yourself, enable LDP and then take a look at it yourself.

In the next lessons we will look at VRFs and MPLS VPN. If you have any questions, feel free to leave a comment!

Rate this Lesson:

MPLS LDP Label Filtering Example

8 votes

Once you enable MPLS on the interfaces between the routers and LDP neighbor adjacencies have been formed, a label will be advertised for each network. With LDP however we can configure filters to decide what networks should get a label and which ones shouldn’t be tagged. I’ll use the following topology to demonstrate this:

Above we have 3 routers and each router has 2 loopback interfaces so that we have plenty of networks to play with. Before we enable MPLS we’ll configure OSPF so that all networks are advertised:

 

R1,R2,R3:

 

(config)#router ospf 1

 
 

(config-router)#network 0.0.0.0 255.255.255.255 area 0

We’ll do this the easy way and activate OSPF on all interfaces. Now let’s enable MPLS on the FastEthernet interfaces:

 

R1(config)#interface fastEthernet 0/0

 

R1(config-if)#mpls ip R2(config)#interface fastEthernet 0/0 R2(config-if)#mpls ip

 

R2(config-if)#exit

R2(config)#interface fastEthernet 0/1 R2(config-if)#mpls ip R3(config)#interface fastEthernet 0/0

 

R3(config-if)#mpls ip

Let’s check if we have LDP neighbors:

 

R2#show mpls ldp neighbor | include Peer

 

Peer LDP Ident: 11.11.11.11:0; Local LDP Ident 22.22.22.22:0

 
 

Peer LDP Ident: 33.33.33.33:0; Local LDP Ident 22.22.22.22:0

So far so good, now let’s take a look at the LDP labels that have been generated:

 

R1#show mpls forwarding-table

 
 

Local Outgoing

Prefix

Bytes tag Outgoing

Next Hop

 

tag

tag or VC

or Tunnel Id

switched interface

  • 16 2.2.2.2/32

Pop tag

0

Fa0/0

192.168.12.2

  • 17 33.33.33.33/32

17

0

Fa0/0

192.168.12.2

  • 18 3.3.3.3/32

18

0

Fa0/0

192.168.12.2

  • 19 22.22.22.22/32

Pop tag

0

Fa0/0

192.168.12.2

  • 20 192.168.23.0/24

Pop tag

0

Fa0/0

192.168.12.2

R2#show mpls forwarding-table

 

Local Outgoing

Prefix

Bytes tag Outgoing

Next Hop

tag

tag or VC

or Tunnel Id

switched interface

  • 16 1.1.1.1/32

Pop tag

0

Fa0/0

192.168.12.1

  • 17 33.33.33.33/32

Pop tag

0

Fa0/1

192.168.23.3

 
  • 18 3.3.3.3/32

Pop tag

0

Fa0/1

192.168.23.3

 
  • 19 Pop tag

11.11.11.11/32

0

Fa0/0

192.168.12.1

 

R3#show mpls forwarding-table

   

Local Outgoing

Prefix

Bytes tag Outgoing

Next Hop

tag

tag or VC

or Tunnel Id

switched interface

  • 16 192.168.12.0/24 0

Pop tag

 

Fa0/0

192.168.23.2

  • 17 16

1.1.1.1/32

0

Fa0/0

192.168.23.2

  • 18 Pop tag

2.2.2.2/32

0

Fa0/0

192.168.23.2

  • 19 22.22.22.22/32

Pop tag

0

Fa0/0

192.168.23.2

 
  • 20 11.11.11.11/32

19

0

Fa0/0

192.168.23.2

For all networks a label has been generated by LDP. Now let’s configure filtering so that we only generate labels for the loopback 0 interfaces. This is how you do it:

 

R1(config)#access-list 1 permit 1.1.1.1 0.0.0.0

 

R1(config)#no mpls ldp advertise-labels R1(config)#mpls ldp advertise-labels for 1 R2(config)#access-list 1 permit 2.2.2.2 0.0.0.0 R2(config)#no mpls ldp advertise-labels R2(config)#mpls ldp advertise-labels for 1 R3(config)#access-list 1 permit 3.3.3.3 0.0.0.0 R3(config)#no mpls ldp advertise-labels

 
 

R3(config)#mpls ldp advertise-labels for 1

First use no mpls ldp advertise-labels to disable the advertisement of all labels. Secondly use thempls ldp advertise-labels for command and refer to an access-list or prefix-list to choose what networks should have a label.

Be careful, if you forget to use the no mpls ldp advertise-labels command you will discover that LDP is STILL advertising a label for each network ...

Let's verify our work:

 

R1#show mpls forwarding-table

 
 

Local Outgoing

Prefix

Bytes tag Outgoing

Next Hop

 

tag

tag or VC

or Tunnel Id

switched interface

 
  • 16 2.2.2.2/32

Pop tag

0

Fa0/0

192.168.12.2

 
 
  • 17 33.33.33.33/32

Untagged

0

Fa0/0

192.168.12.2

 
  • 18 3.3.3.3/32

Untagged

0

Fa0/0

 

192.168.12.2

  • 19 22.22.22.22/32

Untagged

0

Fa0/0

192.168.12.2

  • 20 192.168.23.0/24

Untagged

0

Fa0/0

192.168.12.2

R2#show mpls forwarding-table

 

Local Outgoing

Prefix

Bytes tag Outgoing

Next Hop

tag

tag or VC

or Tunnel Id

switched interface

  • 16 1.1.1.1/32

Pop tag

0

Fa0/0

192.168.12.1

  • 17 Untagged

33.33.33.33/32

0

Fa0/1

192.168.23.3

  • 18 Pop tag

3.3.3.3/32

0

Fa0/1

192.168.23.3

  • 19 Untagged

11.11.11.11/32

0

Fa0/0

192.168.12.1

R3#show mpls forwarding-table

 

Local Outgoing

Prefix

Bytes tag Outgoing

Next Hop

tag

tag or VC

or Tunnel Id

switched interface

  • 16 192.168.12.0/24 0

Untagged

 

Fa0/0

192.168.23.2

  • 17 1.1.1.1/32

Untagged

0

Fa0/0

192.168.23.2

  • 18 Pop tag

2.2.2.2/32

0

Fa0/0

192.168.23.2

  • 19 22.22.22.22/32

Untagged

0

Fa0/0

192.168.23.2

 
  • 20 11.11.11.11/32

Untagged

0

Fa0/0

192.168.23.2

Above you can see that only network 1.1.1.1/32, 2.2.2.2/32 and 3.3.3.3/32 now have a label when advertised to a LDP neighbor. That's all I wanted to show you, if you have any questions feel free to leave a comment!

Rate this Lesson:

VRF Lite Configuration on Cisco IOS

11 votes

In this lesson you will learn about VRFs (Virtual Routing and Forwarding). By

default a router uses asingle global routing table that contains all the directly connected networks and prefixes that it learned through static or dynamic routing protocols. VRFs are like VLANs for routers, instead of using a single global routing table we can use multiple virtual routing tables. Each interface of the router is assigned to a different VRF.

VRFs are commonly used for MPLS deployments, when we use VRFs without MPLS then we call it VRF lite. That’s what we will focus on in this lesson. Let’s take a look at an example topology:

In the topology above we have one ISP router and two customers called “Red” and “Blue”.

In the topology above we have one ISP router and two customers called “Red” and “Blue”. Each customer has two sites and those are connected to the ISP router. The ISP router has only one global routing table so if we connect everything like the topology above, this is what the routing table will look like:

 

ISP#show ip route connected

 
  • C 192.168.4.0/24 is directly connected, FastEthernet3/0

 
  • C 192.168.1.0/24 is directly connected, FastEthernet0/0

  • C 192.168.2.0/24 is directly connected, FastEthernet1/0

 
  • C 192.168.3.0/24 is directly connected, FastEthernet2/0

The ISP router has a single global routing table that has all 4 directly connected networks. Let’s use VRFs to change this, I want to create a seperate routing table for customer “Blue” and “Red”. First we have to create these VRFs:

 

ISP(config)#ip vrf Red

 

ISP(config-vrf)#exit ISP(config)#ip vrf Blue

 
 

ISP(config-vrf)#exit

Globally we create the VRFs, one for each customer. Our next step is to add the interfaces of the ISP router to the correct VRF. Here’s how:

 

ISP(config)#interface FastEthernet 0/0

 

ISP(config-if)#ip vrf forwarding Blue % Interface FastEthernet0/0 IP address 192.168.1.254 removed due to enabling VRF Blue

 
 

ISP(config-if)#ip address 192.168.1.254 255.255.255.0

On the interface level we use the ip vrf forwarding command to assign the interface to the correct VRF. Once you do this , you’ll have to add the IP address again. Let’s configure the remaining interfaces:

 

ISP(config)#interface FastEthernet 1/0

 

ISP(config-if)#ip vrf forwarding Red ISP(config-if)#ip address 192.168.2.254 255.255.255.0

 

ISP(config)#interface FastEthernet 2/0 ISP(config-if)#ip vrf forwarding Blue ISP(config-if)#ip address 192.168.3.254 255.255.255.0

ISP(config)#interface FastEthernet 3/0 ISP(config-if)#ip vrf forwarding Red

 

ISP(config-if)#ip address 192.168.4.254 255.255.255.0

All interfaces are now configured. There’s a useful command you can use to see all the VRFs and their interfaces:

 

ISP#show ip vrf

 

Name

Default RD

Interfaces

 

Blue

Fa0/0

Fa2/0

Red

Fa1/0

 

Fa3/0

Our VRFs are configured, let’s take a look at the global routing table of the ISP router:

ISP#show ip route connected

The global routing table has no entries, this is because all interfaces were added to a VRF. Let’s check the VRF routing tables:

 

ISP#show ip route vrf Blue connected

 
  • C 192.168.1.0/24 is directly connected, FastEthernet0/0

 
  • C 192.168.3.0/24 is directly connected, FastEthernet2/0

ISP#show ip route vrf Red connected

  • C 192.168.4.0/24 is directly connected, FastEthernet3/0

 
  • C 192.168.2.0/24 is directly connected, FastEthernet1/0

We use the show ip route command but you’ll need to specify which VRF you want to look at. As you can see, each VRF has its own routing table with the interfaces that we configured earlier.

If you want to do something on the router like sending a ping then you’ll have to specify which VRF you want to use. By default it will use the global routing table. Here’s an example how to send a ping:

 

ISP#ping vrf Blue 192.168.1.1

 

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

 

!!!!!

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

That’s easy enough, just don’t forget to specify the correct VRF. The same thing applies to routing (protocols). For example if you want to configure a static route you’ll have to specify the correct VRF. Take a look at the example below:

Router Blue1 has a loopback interface with IP address 1.1.1.1 /32. Let’s create a static route

Router Blue1 has a loopback interface with IP address 1.1.1.1 /32. Let’s create a static route on the ISP router so that we can reach it:

ISP(config)#ip route vrf Blue 1.1.1.1 255.255.255.255 192.168.1.1

We use the same ip route command but I specified to what VRF the static route belongs. Let’s see if this works:

 

ISP#ping vrf Blue 1.1.1.1

 

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

 

!!!!!

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/24/52 ms

Easy enough, the ping works. What about routing protocols? We can use OSPF, EIGRP, BGP…no problem at all. Let’s look at an example for OSPF:

Customer “Blue” and “Red” both want to use OSPF to advertise their networks. Since we use VRFs, everything is seperated. Let’s start with the OSPF configuration for customer Blue:

 

Blue1(config)#router ospf 1

 

Blue1(config-router)#network 192.168.1.0 0.0.0.255 area 0 Blue1(config-router)#network 1.1.1.1 0.0.0.0 area 0 Blue2(config)#router ospf 1 Blue2(config-router)#network 192.168.3.0 0.0.0.255 area 0

 
 

Blue2(config-router)#network 3.3.3.3 0.0.0.0 area 0

The OSPF configuration for the customer routers is pretty straight-forward. On the ISP router, we’ll have to specify what VRF we want to use:

 

ISP(config)#router ospf 1 vrf Blue

 

ISP(config-router)#network 192.168.1.0 0.0.0.255 area 0

 
 

ISP(config-router)#network 192.168.3.0 0.0.0.255 area 0

We configure OSPF process 1 and specify the VRF that we want to use, that’s all there is to it. Let’s do the same for customer Red:

 

Red1(config)#router ospf 1

 

Red1(config-router)#network 192.168.2.0 0.0.0.255 area 0 Red1(config-router)#network 2.2.2.2 0.0.0.0 area 0 Red2(config)#router ospf 1 Red2(config-router)#network 192.168.4.0 0.0.0.255 area 0 Red2(config-router)#network 4.4.4.4 0.0.0.0 area 0 ISP(config)#router ospf 2 vrf Red ISP(config-router)#network 192.168.2.0 0.0.0.255 area 0

 
 

ISP(config-router)#network 192.168.4.0 0.0.0.255 area 0

The configuration is similar, I had to use another process ID on the ISP router since the first one is used for customer Blue. Here’s what the VRF routing tables on the ISP router look like now:

 

ISP#show ip route vrf Blue ospf

 
 

Routing Table: Blue

 

1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/2] via 192.168.1.1, 00:00:24, FastEthernet0/0 3.0.0.0/32 is subnetted, 1 subnets O 3.3.3.3 [110/2] via 192.168.3.3, 00:00:24, FastEthernet2/0 ISP#show ip route vrf Red ospf

O

Routing Table: Red

O

2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/2] via 192.168.2.2, 00:00:19, FastEthernet1/0 4.0.0.0/32 is subnetted, 1 subnets

 

O

4.4.4.4 [110/2] via 192.168.4.4, 00:00:19, FastEthernet3/0

Two seperate routing tables with the prefixes from each VRF, this is looking good.

This is what VRF lite is about, it has one downside though…it’s not a scalable solution. In our example we only used a single ISP router but what if we want to use VRFs and multiple ISP routers? That’s something we’ll discuss in the EVN (Easy Virtual

If you have any questions, feel free to leave a comment!

Rate this Lesson:

MPLS Layer 3 VPN Explained

12 votes

In previous lessons I explained the basics of MPLS:

VRF

In this lesson we will look at MPLS L3 VPNs and we will build upon the things you learned in previous lessons. By now you should know what MPLS is about. What about the L3 VPN part? Here’s what it is about:

Layer 3: the service provider will participate in routing with the customer. The customer will

run OSPF, EIGRP, BGP or any other routing protocol with the service provider, these routes can be shared with other sites of the customer. VPN: routing information from one customer is completely separated from other customers and tunneled over the service provider MPLS network.

Let’s look at an example:

Above we have two customers connected to a service provider network. Customer A and B each have two sites and you can see that they are using the same IP ranges.

Customer A might use OSPF between their sites and customer B could use EIGRP between their sites. Everything from these customers is completely separated by the service provider.

In this lesson you will learn everything that is required to build a MPLS L3 VPN network. Let’s get started!

VRF (Virtual Routing and Forwarding)

Let’s start with VRFs. This is the first step in separating traffic from different customers. Instead of using a single global routing table, we use multiple routing tables. Each customer of the service provider will use a different VRF. Let’s take a closer look:

Customer A might use OSPF between their sites and customer B could use EIGRP between their

Above we have our PE1 router with the two customer sites. Each customer will use a different VRF so the overlapping address space is no problem. Now you might be wondering, why don’t we use VRFs everywhere instead of MPLS? We could but there’s one downside to using VRFs. Take a look at the following picture:

The problem with VRFs is that you have to create them everywhere. When our goal is to have connectivity between CE1 and CE3 then we will have to add a VRF on the PE1, P and PE2 router. Also, all the service provider routes will have to participate with routing. For example, when customer A wants to run OSPF between their two sites then it means that we have to configure OSPF on the PE1, P and PE2 router of the service provider for their VRF.

When customer B wants to run EIGRP between their sites, we have to participate…

we’ll have to configure EIGRP on all service provider routers for the VRF of customer

B.

This is not a scalable solution so it’s not going to happen. Instead, we will configure the VRFs only on the PE routers. The core of the service provider network (P router) will only do switching based on labels. To share information about VRFs between PE routers, we will use BGP.

MP-BGP (Multi Protocol BGP)

We will use BGP between the PE routers so that they can share information from the VRFs. Here’s how it works:

One of the CE routers advertises something to the PE router, this can be done through OSPF,

EIGRP, BGP or any other routing protocol (static routing is also possible). The PE router uses a VRF for the customer so it will store everything it learns in the routing

table of the customer’s VRF. The PE router will then redistribute everything in BGP.

The PE router will advertise to to the other PE router through iBGP.

There’s a couple of problems though. First of all, our two customers are using overlapping address space. Let’s say that our PE1 router is advertising 192.168.1.0 / 24 from customer A to the PE2 router on the other side. Here’s what happens:

The PE2 router will learn 192.168.1.0 /24 from the PE1 router but it has no clue to what customer it will belong. There is no way to differentiate if something belongs to customer A or B.

What we need is something to make all prefixes that we learn unique.

RD (Route Distinguisher)

To fix this issue, we will use a RD (Route Distinguisher). We will add something to the prefix of the customer so that it will become unique:

The PE2 router will learn 192.168.1.0 /24 from the PE1 router but it has no clue

The RD is a 8 byte (64 bit) field. You can use any value you want but typically we use the ASN:NN format where ASN is the service provider’s AS number and NN is a number we pick that identifies the site of the customer.

The RD and the prefix combined is what we call a VPNv4 route. We now have a method to differentiate between the different prefixes of our customers. Here’s an example:

The RD is a 8 byte (64 bit) field. You can use any value you want

Let’s say that we use RD 123:10 for customer A and RD 123:20 for customer B. By adding these values, we have unique VPNv4 routes.

How do we advertise these VPNv4 routes? That’s what we need MP-BGP for.

MP-BGP supports IPv4 unicast/multicast, IPv6 unicast/multicast and it has support for VPNv4 routes. To exchange VPNv4 routes, MP-BGP uses a new NLRI (Network Layer Reachability Information)format that has the following attributes:

RD (Route Distinguisher)

IPv4 prefix

Next Hop

VPN Label

This is how PE routers exchange VPNv4 routes with each other. This NRL also has an attribute called the VPN label, we’ll get back to this one later in this lesson.

RT (Route Target)

When a PE router learns these VPNv4 routes, what will it do with it? Take a look at the picture below:

Our PE2 router has learned the two VPNv4 routes, one for each customer. You might think that the PE2 router will automatically export each VPNv4 route in the correct customer VRF but that’s not going to happen.

We use something called a RT (Route Target) to decide in which VRF we import and export VPNv4 routes.

The RT is a 8 byte value that uses the same format as the RD (ASN:NN). It's advertised between PE routers by using a BGP extended community value. For each VRF that we configure, we tell it what RTs we want to import and export. Here's an example:

Let me explain the picture above:

Both PE routers are configured to use a VRF called "CustA"for customer A.

When PE1 receives a prefix from CE1, it will add RD 123:10 to it to create a unique VPNv4

route. PE1 is configured to add RT 123:1 to all VPNv4 routes for VRF CustA.

PE1 will advertise the VPNv4 route to PE2.

PE2 is configured to export all VPNv4 routes that use RT 123:1 into VRF CustA.

When PE2 receives the VPNv4 route, it will redistribute it into the VRF so that CE3 will learn the prefix.

The end result will be that CE3 will learn prefix 192.168.1.0 /24 that was advertised by CE1.

Since the RD and RT use the same format, many students confuse these two. Normally we use the same value for these two but to emphasize that the RD and RT are two different things, I used 123:10 for the RD and 123:1 for the RT.

Now let me show you the picture with our two customers again:

In the picture above you can see that the PE routers are importing and exporting everything from customer A with RT value 123:1. This allows CE1 and CE3 to learn everything from each other. We do the same thing for customer B but we use RT 123:2 for VRF CustB.

CE2 and CE4 will be able to learn everything from each other.

The RT gives us a lot of control over our VPNv4 routes. Do you want to give customer B access to the networks behind CE3 of customer A? Just import and export some RTs and it's done.

Do you want to build a hub and spoke topology for a third customer? No problem, we can do this by importing and exporting some RTs. The service provider can also use this to offer "shared services" like Internet access.

Transport and VPN Label

Everything that we just discussed about the VRFs, MP-BGP, RD and RT occurs on the control plane. On the data plane, we still have a problem. Let me give you an example:

In the picture above I have added a couple of extra P routers so that we have a nice example of how the routers in the service provider network forward traffic. In the example, the CE1 router from the customer is sending an IP packet with source address 192.168.1.1 and destination 192.168.2.2 to the PE1 router.

The PE1 router will add a transport label to the IP packet and our MPLS packet will be label switched all the way to P3 which pops the label (penultimiate hop popping) so that PE2 receives the IP packet. In the header of this IP packet, there's nothing that will help PE2 decide where to forward it to. To fix this problem, we will add a second label to the IP packet called the VPN label. Besides the RT, the PE1 router will also advertise a VPN label to the PE2 router. Take a look at the example below:

Here's what happens:

The CE1 router sends an IP packet to the PE1 router.

The PE1 router will first add a VPN label to the IP packet, in this example we'll pick number

The PE1 router also adds a transport label to it and it will be forwarded to the P1 router.

The packet makes it to the P3 router, which pops the transport label.

PE2 sees VPN label 21 and knows that this belongs to the RT of the VRF that connects to CE3. It pops the label and forwards the IP packet to CE3.

Conclusion

You have now seen all components that are used in MPLS VPNs. With all the pieces together, it's quite a complex story. In the next lesson I will show you the configuration of everything that I explained above and we will take a look at the different PE-CE scenarios where we use OSPF, EIGRP, BGP, etc between the customer and provider edge.

I hope you enjoyed this lesson, if you have any questions feel free to leave a comment.

Rate this Lesson:

MPLS Layer 3 VPN Configuration

13 votes

In this lesson we’ll take a look how to configure a MPLS Layer 3 VPN PE-CE scenario. Here’s the topology I will use:

Above we have five routers where AS 234 is the service provider. There’s one customer with

Above we have five routers where AS 234 is the service provider. There’s one customer with two sites, AS 1 and AS 5. Our customer wants to exchange 1.1.1.1 /32

and 5.5.5.5 /32 between its sites using BGP. To achieve this, we’ll have to do a couple of things:

Configure IGP and LDP within the service provider network.

Configure VRFs on the PE routers.

Configure IBGP between the PE routers.

Configure BGP between the PE and CE routers.

There are a lot of difference pieces in the MPLS puzzle to make this work. Instead of configuring everything at once and praying that it will work, we’ll build this network step-by-step. At each step, I’ll show you how to verify that it’s working before we continue with the next step.

Having said that, let’s get started!

Configuration

IGP and LDP

First we will configure the service provider network. On the PE1, P and PE2 routers we will create a loopback interface that will be advertised in OSPF. LDP will then uses the addresses as the transport address for the TCP connection. Let’s add those interfaces and enable OSPF:

 

PE1(config)#interface loopback 0

 

PE1(config-if)#ip address 2.2.2.2 255.255.255.255 P(config)#interface loopback 0 P(config-if)#ip address 3.3.3.3 255.255.255.255 PE2(config)#interface loopback 0

 
 

PE2(config-if)#ip address 4.4.4.4 255.255.255.255

Now we will configure OSPF to advertise all interfaces in the service provider network:

 

PE1(config)#router ospf 1

 

PE1(config-router)#network 192.168.23.0 0.0.0.255 area 0

 
 

PE1(config-router)#network 2.2.2.2 0.0.0.0 area 0

 

P(config)#router ospf 1

 

P(config-router)#network 192.168.23.0 0.0.0.255 area 0 P(config-router)#network 192.168.34.0 0.0.0.255 area 0 P(config-router)#network 3.3.3.3 0.0.0.0 area 0 PE2(config)#router ospf 1 PE2(config-router)#network 192.168.34.0 0.0.0.255 area 0

 
 

PE2(config-router)#network 4.4.4.4 0.0.0.0 area 0

And let’s enable LDP on all internal interfaces:

 

PE1(config)#interface FastEthernet 0/1

 

PE1(config-if)#mpls ip P(config)#interface FastEthernet 0/0 P(config-if)#mpls ip

 

P(config)#interface FastEthernet 0/1 P(config-if)#mpls ip PE2(config)#interface FastEthernet 0/0

 

PE2(config-if)#mpls ip

That takes care of that. Let’s see if MPLS is enabled:

 

PE1#show mpls interfaces

 

Interface Operational

IP

Tunnel

BGP Static

   

FastEthernet0/1

Yes (ldp)

No

No

No

Yes

P#show mpls interfaces Interface Operational

IP

Tunnel

BGP Static

FastEthernet0/0

Yes (ldp)

No

No

No

Yes

FastEthernet0/1

Yes (ldp)

No

No

No

Yes

PE2#show mpls interfaces

Interface

IP

Tunnel

BGP Static

 

Operational

 

FastEthernet0/0

Yes (ldp)

No

No

No

Yes

That’s looking good to me. Do we have any LDP neighbors?

 

P#show mpls ldp neighbor

 

Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0 TCP connection: 2.2.2.2.646 - 3.3.3.3.55065 State: Oper; Msgs sent/rcvd: 10/11; Downstream Up time: 00:02:39

 
 

LDP discovery sources:

 

FastEthernet0/0, Src IP addr: 192.168.23.2

 
 

Addresses bound to peer LDP Ident:

   

192.168.12.2

192.168.23.2

2.2.2.2

Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 3.3.3.3:0

TCP connection: 4.4.4.4.52817 - 3.3.3.3.646 State: Oper; Msgs sent/rcvd: 10/11; Downstream Up time: 00:02:02 LDP discovery sources:

FastEthernet0/1, Src IP addr: 192.168.34.4 Addresses bound to peer LDP Ident:

 

192.168.34.4

192.168.45.4

4.4.4.4

Our P router in the middle has two neighbors so we know that LDP is working. Just to be sure, let’s check if we have connectivity between PE1 and PE2:

 

PE1#ping 4.4.4.4 source loopback 0

 

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

 

Packet sent with a source address of 2.2.2.2 !!!!!

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

A quick ping tells us that it’s working. Are we switching based on labels though? Let’s do a trace to find out:

 

PE1#traceroute 4.4.4.4 source loopback 0

 

Type escape sequence to abort. Tracing the route to 4.4.4.4 VRF info: (vrf in name/id, vrf out name/id)

 
  • 1 192.168.23.3 [MPLS: Label 17 Exp 0] 0 msec 0 msec 4 msec

 
  • 2 192.168.34.4 0 msec 0 msec *

Above you can see that we are using a label for the packet from PE1 to PE2. The P router is popping the label (penultimate hop popping) so PE1 receives a normal IP packet. So far, this is looking good.

VRF on the PE routers

Since we want our customer routes separated from the service provider’s routes, we’ll have to create some VRFs. Here’s how it’s done:

PE1(config)#ip vrf CUSTOMER

First I will create a VRF called CUSTOMER. The next step will be configuring a RD (Route Distinguisher):

PE1(config-vrf)#rd ? ASN:nn or IP-address:nn VPN Route Distinguisher

The RD is to make sure that all prefixes are unique. The customer prefix + RD together are a VPNv4 route. I’ll pick something simple:

PE1(config-vrf)#rd 1:1

Our RD will be 1:1. The next item to configure is the RT (Route Target). This defines where we will import and export our VPNv4 routes. I want to make sure that all routes from CE1 and CE2 will be exchanged:

PE1(config-vrf)#route-target both 1:1

I will use RT value 1:1 and use parameter both. This means that all routes of this VRF will be imported and exported.

I used the same value (1:1) for the RD and RT, keep in mind that these are two different things… don’t mix them up!

Here’s what the VRF now looks like:

 

PE1#show run | begin vrf

 

ip vrf CUSTOMER rd 1:1 route-target export 1:1

 
 

route-target import 1:1

After creating the VRF globally, we have to assign the interface that is facing the customer to the VRF:

 

PE1(config)#interface FastEthernet 0/0

 

PE1(config-if)#ip vrf forwarding CUSTOMER

 
 

% Interface FastEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF CUSTOMER

Once you add an interface to a VRF, Cisco IOS will remove its IP address. Let’s add it again:

PE1(config-if)#ip address 192.168.12.2 255.255.255.0

The VRF configuration of PE1 is now complete. We’ll configure the exact same thing on PE2:

 

PE2(config)#ip vrf CUSTOMER

 

PE2(config-vrf)#rd 1:1 PE2(config-vrf)#route-target export 1:1 PE2(config-vrf)#route-target import 1:1

 

PE2(config)#interface FastEthernet 0/1 PE2(config-if)#ip vrf forwarding CUSTOMER

 

PE2(config-if)#ip address 192.168.45.4 255.255.255.0

The VRFs are now configured. If you want to reach the CE1 or CE2 routers then you’ll have to use the VRFs from now on:

 

PE1#ping vrf CUSTOMER 192.168.12.1

 

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:

 

!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms PE2#ping vrf CUSTOMER 192.168.45.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.45.5, timeout is 2 seconds:

!!!!!

 

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Great our VRFs are operational!

IBGP Configuration on PE1 and PE2

PE1 and PE2 will have to exchange VPNv4 routes through IBGP. When you configure iBGP, your routers will only exchange IPv4 unicast routes by default. Since we need the PE routers to exchange VPNv4 routes, we’ll have to activate an additional address-family:

 

PE1(config)#router bgp 234

 

PE1(config-router)#neighbor 4.4.4.4 remote-as 234 PE1(config-router)#neighbor 4.4.4.4 update-source loopback 0 PE1(config-router)#address-family vpnv4

 
 

PE1(config-router-af)#neighbor 4.4.4.4 activate

In the configuration above I'm sourcing the iBGP updates from the loopback interface. We also enabled the VPNv4 address-family, this will allow the router to exchange those VPNv4 routes. When you activate the VPNv4 address-family, the router will do one more thing for you:

 

PE1#show run | section bgp

 

router bgp 234 bgp log-neighbor-changes neighbor 4.4.4.4 remote-as 234 neighbor 4.4.4.4 update-source Loopback0 ! address-family vpnv4 neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended

 
 

exit-address-family

Above you can see that the router automatically added the send-community extended command. This command is required and should never be removed since we use a community to advertise the route-target. The configuration of PE1 is complete, let's configure the same thing on PE2:

 

PE2(config)#router bgp 234

 

PE2(config-router)#neighbor 2.2.2.2 remote-as 234 PE2(config-router)#neighbor 2.2.2.2 update-source loopback 0

 
 

PE2(config-router)#address-family vpnv4

PE2(config-router-af)#neighbor 2.2.2.2 activate

The iBGP configuration of the PE routers is now complete. There's one more thing we could do ...

Right now our routers will be able to exchange IPv4 unicast prefixes and VPNv4 routes. In our example however, the PE routers will only be used to exchange VPNv4 routes so we can disable the address-family for IPv4 unicast. Here's how you can do this:

 

PE1(config)#router bgp 234

 

PE1(config-router)#address-family ipv4 PE1(config-router-af)#no neighbor 4.4.4.4 activate PE2(config)#router bgp 234 PE2(config-router)#address-family ipv4

 
 

PE2(config-router-af)#no neighbor 2.2.2.2 activate

This will disable the IPv4 unicast address-family. Let me show you the complete BGP configuration one more time:

 

PE1#show run | section bgp

 

router bgp 234 bgp log-neighbor-changes neighbor 4.4.4.4 remote-as 234 neighbor 4.4.4.4 update-source Loopback0 ! address-family ipv4 no neighbor 4.4.4.4 activate exit-address-family ! address-family vpnv4 neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended

 
 

exit-address-family

With this BGP configuration, we will use IPv4 to establish the neighbor adjacency but we won't exchange IPv4 prefixes. The only thing we will exchange are VPNv4 routes.

Before we continue we should check if IBGP is working or not. You'll need to use some different commands however, here's why:

PE1#show ip bgp summary

The show ip bgp summary command won't work since it is used to check IPv4 unicast prefixes. Here's the command you need to use:

 

PE1#show bgp vpnv4 unicast all summary

 
 

BGP router identifier 2.2.2.2, local AS number 234 BGP table version is 1, main routing table version 1

   

Neighbor

V

AS MsgRcvd MsgSent

TblVer

InQ OutQ

Up/Down State/PfxRcd

 
  • 4.4.4.4 234

4

7

7

1

0

0

00:03:03

0

PE2#show bgp vpnv4 unicast all summary BGP router identifier 4.4.4.4, local AS number 234 BGP table version is 1, main routing table version 1

 

Neighbor

V

AS MsgRcvd MsgSent

TblVer

InQ OutQ

Up/Down State/PfxRcd

 
 
  • 2.2.2.2 234

4

8

8

1

0

0

00:04:00

0

You need to use the show bgp vpnv4 command to look at anything that is related to the VPNv4 address-family. Above you can see that PE1 and PE2 have become neighbors, nothing has been exchanged yet since we don't have any VPNv4 routes right now.

EBGP on PE and CE

The last piece of the puzzle is exchanging routes between the PE and CE routers. In this example, we'll use EBGP. Let's start with the CE routers:

 

CE1(config)#interface loopback 0

 

CE1(config-if)#ip address 1.1.1.1 255.255.255.255

 

CE1(config)#router bgp 1 CE1(config-router)#neighbor 192.168.12.2 remote-as 234

 

CE1(config-router)#network 1.1.1.1 mask 255.255.255.255

And we'll do something similar on CE2:

 

CE2(config)#interface loopback 0

 

CE2(config-if)#ip address 5.5.5.5 255.255.255.255

 

CE2(config)#router bgp 5 CE2(config-router)#neighbor 192.168.45.4 remote-as 234

 

CE2(config-router)#network 5.5.5.5 mask 255.255.255.255

The configuration of the CE routers is straight forward, this is plain and simple eBGP. Let's configure the PE routers:

The interface that connects to the CE1 router is assigned to the VRF. This means we'll have to create an address-family in BGP for this VRF:

 

PE1(config)#router bgp 234

 

PE1(config-router)#address-family ipv4 vrf CUSTOMER

 
 

PE1(config-router-af)#neighbor 192.168.12.1 remote-as 1

Let's find out if we have established a BPG neighbor adjacency with the CE1 router:

 

PE1#show bgp vpnv4 unicast vrf CUSTOMER summary

 
 

BGP router identifier 2.2.2.2, local AS number 234 BGP table version is 2, main routing table version 2

   
  • 1 network entries using 160 bytes of memory

 
  • 1 path entries using 56 bytes of memory

2/1 BGP path/bestpath attribute entries using 272 bytes of memory

  • 1 BGP AS-PATH entries using 24 bytes of memory

 
  • 1 BGP extended community entries using 24 bytes of memory

 
  • 0 BGP route-map cache entries using 0 bytes of memory

 
  • 0 BGP filter-list cache entries using 0 bytes of memory

BGP using 536 total bytes of memory BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

 

Neighbor

V

AS MsgRcvd MsgSent

TblVer

InQ OutQ

Up/Down State/PfxRcd

 
 

192.168.12.1

4

1

13

12

2

0

0

00:07:31

1

Great, we have become neighbors and we received one prefix. Let's take a closer look to see what we have learned:

 

BGP table version is 2, local router ID is 2.2.2.2

 
 

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

 

r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? - incomplete

Network

Next Hop

Metric LocPrf Weight Path

Route Distinguisher: 1:1 (default for vrf CUSTOMER)

 
 

*> 1.1.1.1/32

192.168.12.1

0

0

1

i

Above you can see that we have learned prefix 1.1.1.1 /32 and we will use RD 1:1. These two values together are our VPNv4 route.

Let's configure PE2 to become neighbors with CE2:

 

PE2(config)#router bgp 234

 

PE2(config-router)#address-family ipv4 vrf CUSTOMER

 
 

PE2(config-router-af)#neighbor 192.168.45.5 remote-as 5

Let's see if they have become neighbors:

 

PE2#show bgp vpnv4 unicast vrf CUSTOMER summary

 
 

BGP router identifier 4.4.4.4, local AS number 234 BGP table version is 4, main routing table version 4

   
  • 2 network entries using 320 bytes of memory

 
  • 2 path entries using 112 bytes of memory

3/2 BGP path/bestpath attribute entries using 408 bytes of memory

  • 2 BGP AS-PATH entries using 48 bytes of memory

 
  • 1 BGP extended community entries using 24 bytes of memory

 
  • 0 BGP route-map cache entries using 0 bytes of memory

 
  • 0 BGP filter-list cache entries using 0 bytes of memory

BGP using 912 total bytes of memory BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs