BGP Prevent Transit AS

By default BGP will advertise all prefixes to EBGP (External BGP) neighbors. This means that if you are multi-homed (connected to two or more ISPs) that you might become a transit AS. Let me show you an example:

R1 is connected to ISP1 and ISP2 and each router is in a different AS (Autonomous System). Since R1 is multi-homed it’s possible that the ISPs will use R1 to reach each other. In order to prevent this we’ll have to ensure that R1 only advertises prefixes from its own autonomous system.

As far as I know there are 4 methods how you can prevent becoming a transit AS:

• Filter-list with AS PATH access-list.
• No-Export Community.
• Prefix-list Filtering
• Distribute-list Filtering

Prefix-lists or distribute-lists will work but it’s not a very scalable solution if  you have thousands of prefixes in your BGP table. The filter-list and no-export community work very well since you only have to configure them once and it will not matter if new prefixes show up. First we’ll configure BGP on each router:

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R1(config-router)#neighbor 192.168.13.3 remote-as 3

ISP1(config)#router bgp 2
ISP1(config-router)#neighbor 192.168.12.1 remote-as 1

ISP2(config)#router bgp 3
ISP2(config-router)#neighbor 192.168.13.1 remote-as 1

The commands above will configure EBGP (External BGP) between R1 – ISP1 and R1 – ISP2. To make sure we have something to look at, I’ll advertise the loopback interfaces in BGP on each router:

R1(config)#router bgp 1
R1(config-router)#network 1.1.1.0 mask 255.255.255.0

ISP1(config)#router bgp 2
ISP1(config-router)#network 2.2.2.0 mask 255.255.255.0

ISP2(config)#router bgp 3
ISP2(config-router)#network 3.3.3.0 mask 255.255.255.0

With the networks advertised, let’s take a look at the BGP table of ISP1 and ISP2 to see what they have learned:

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       192.168.12.1                           0 1 3 i

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.13.1             0             0 1 i
*> 2.2.2.0/24       192.168.13.1                           0 1 2 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

The ISP routers have learned about each other networks and they will use R1 as the next hop. We now have everything in place to play with the different filtering techniques.

Filter-list with AS PATH access-list

Using an filter-list with the AS PATH access-list is probably the most convenient solution. It will ensure that you will always only advertise prefixes from your own autonomous system. Here’s how to do it:

R1(config)#ip as-path access-list 1 permit ^$

R1(config-router)#neighbor 192.168.12.2 filter-list 1 out
R1(config-router)#neighbor 192.168.13.3 filter-list 1 out

The ^$ regular expression ensures that we will only advertise locally originated prefixes. We’ll have to apply this filter to both ISPs.

Keep in mind that BGP is slow…if you are doing labs, it’s best to speed things up withclear ip bgp *

Let’s verify our configuration:

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 2.2.2.0/24       192.168.12.2             0             0 2 i
*> 3.3.3.0/24       192.168.13.3             0             0 3 i

R1 still knows about the prefixes from the ISP routers. What about ISP1 and ISP2?

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.13.1             0             0 1 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

ISP1 and ISP2 only know about the 1.1.1.0 /24 network. Excellent, we are no longer a transit AS! On to the next method…

No-Export Community

Using the no-export community will also work pretty well. We will configure R1 so that prefixes from the ISP routers will be tagged with the no-export community. This ensures that the prefixes from those routers will be known within AS 1 but won’t be advertised to other routers.

R1(config)#route-map NO-EXPORT
R1(config-route-map)#set community no-export

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map NO-EXPORT in
R1(config-router)#neighbor 192.168.13.3 route-map NO-EXPORT in

I’m only using one router in AS 1, if you have other routers and are running IBGP (Internal BGP) then don’t forget to send communities to those routers with theneighbor <ip> send-community command.

Let’s see what ISP1 and ISP2 think about our configuration:

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.13.1             0             0 1 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

They only know about network 1.1.1.0 /24. Onto the next method!

Prefix-List Filtering

Using a prefix-list we can determine what prefixes are advertised to our BGP neighbors. This works fine but it’s not a good solution to prevent becoming a transit AS. Each time you add new prefixes you’ll have to reconfigure the prefix-list. Anyway let me show you how it works:

R1(config)#ip prefix-list NO-TRANSIT permit 1.1.1.0/24

R1(config-router)#neighbor 192.168.12.2 prefix-list NO-TRANSIT out 
R1(config-router)#neighbor 192.168.13.3 prefix-list NO-TRANSIT out

The prefix-list above will only advertise 1.1.1.0 /24 to the ISP routers. Let’s verify the configuration:

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.13.1             0             0 1 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

The prefix-list is working as it should, onto the last exercise!

Distribute-list Filtering

This method is similar to using the prefix-list but this time we’ll use an access-list.

R1(config)#ip access-list standard NO-TRANSIT
R1(config-std-nacl)#permit 1.1.1.0 0.0.0.255

R1(config-router)#neighbor 192.168.12.2 distribute-list NO-TRANSIT out
R1(config-router)#neighbor 192.168.13.3 distribute-list NO-TRANSIT out

Time to check the ISPs:

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.13.1             0             0 1 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

That’s all there is to it. I hope this has been helpful for you, if you know of any other methods to prevent becoming a BGP transit AS please leave a comment!

Configuring Basic MPLS TE Tunnels

This article will assume a familiarity with basic MPLS concepts and configurations and will focus on setting up and maintaining TE tunnels for MPLS.

One of the inherent benefits of MPLS is the fact that it relies on labels to forward traffic throughout the cloud. The nature of these labels is such that they can be stacked upon one another to define a very specific route the frame should take. Routing protocols with MPLS TE extensions exist, such as OSPF-TE and ISIS-TE as well. These protocols allow for dynamic “contstraint-based routing” dependent on the current load of links throughout the network. I will not discuss these protocols in today’s post, and rather focus on manual TE tunnels only. You can look forward to future posts regarding these protocols though.

Below is a diagram of the lab we’ll be using in this post.

The four core routers are doing the bulk of the functionality while the two outside routers are simply there to provide pingable hosts. In this topography there are two distinct paths through the core, the top path and the bottom path. We will experiment with steering traffic across said paths.

The tunnels in this lab are created to and from the head-ends (R0 and R3) while R1 and R2 simply act as interim hops. It’s important to note that tunnels are unidirectional also, so if you want a round-trip tunnel you’ll need to create two, one sourced at the head-end and one sourced at the tail-end.

This next part will assume MPLS and IGP functionality within the core, if you’re having trouble with that part, the full configs can be found at the bottom of the post.

First we’ll establish a tunnel from R0 to R3:

mpls traffic-eng tunnels
!
interface Tunnel2
 ip unnumbered Loopback0
 tunnel destination 172.16.255.13
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng priority 2 2
 tunnel mpls traffic-eng bandwidth  158
 tunnel mpls traffic-eng path-option 1 explicit name BOTTOM
!
ip explicit-path name BOTTOM enable
 next-address 172.16.1.2
 next-address 172.16.3.2

As you can see, the tunnel is created by a standard tunnel interface and passed a few MPLS TE-specific parameters. One such parameter is the explicit path, referenced as BOTTOM. Under the entry for the ip explicit-path above you can see each next-hop specifically defined. These next-hop addresses are the addresses of the closest interface on each interim router (only one interim and the tail-end in this case). Assuming the path is valid, we can see how the tunnel looks by the show mpls traffic-eng tunnels command:

Name: R0_t2                               (Tunnel2) Destination: 172.16.255.13
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected

    path option 1, type explicit BOTTOM (Basis for Setup, path weight 2)

  Config Parameters:
    Bandwidth: 158      kbps (Global)  Priority: 2  2   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute:  enabled   LockDown: disabled  Loadshare: 158      bw-based
    auto-bw: disabled

  InLabel  :  -
  OutLabel : GigabitEthernet2/0, 16
  RSVP Signalling Info:
       Src 172.16.255.10, Dst 172.16.255.13, Tun_Id 2, Tun_Instance 12
    RSVP Path Info:
      My Address: 172.16.1.1
      Explicit Route: 172.16.1.2 172.16.3.1 172.16.3.2 172.16.255.13
      Record Route:  NONE
      Tspec: ave rate=158 kbits, burst=1000 bytes, peak rate=158 kbits
    RSVP Resv Info:
      Record Route:  NONE
      Fspec: ave rate=158 kbits, burst=1000 bytes, peak rate=158 kbits
  History:
    Tunnel:
      Time since created: 52 minutes, 53 seconds
      Time since path change: 52 minutes, 44 seconds
    Current LSP:
      Uptime: 52 minutes, 45 seconds

We can see that it has an explicit route defined and can also see each hop along the way. Tunnels are signaled with RSVP one hop at a time. First, an RSVP PATH message is sent from the head-end to the tail-end and inspected/modified by the interim routers. When the interim routers receive the RSVP PATH message, they check the EXPLICIT_ROUTE field to see if any of their interfaces are part of it. If so, they remove their IP from the EXPLICIT_ROUTE, add it to the RECORD_ROUTE, add the TE LSP to their database, and pass the RSVP PATH message along to the next hop. The tail-end router then crafts an RSVP RESV packet to acknowledge the creation of the tunnel and allocate labels along the way. It’s important to note that the label-allocation process is not done by LDP in this case, but by the RSVP RESV packet on the way back to the head-end. A packet capture of an RSVP TEAR, PATH, and RESV transaction can be found at the end of the post, save the file and change the extension to .pcap (it is .txt to stop WordPress from complaining). At this time we’ll create the second tunnel from R3 back to R0 to create a bidirectional path:

mpls traffic-eng tunnels
!
interface Tunnel2
 ip unnumbered Loopback0
 tunnel destination 172.16.255.10
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng priority 2 2
 tunnel mpls traffic-eng bandwidth  158
 tunnel mpls traffic-eng path-option 1 explicit name BOTTOM
!
ip explicit-path name BOTTOM enable
 next-address 172.16.3.1
 next-address 172.16.1.1

After the creation of the second tunnel, you will be able to see it in the MPLS TE tunnel database on R0 (and vice-versa). You can also see tunnels from the interim routers, here is how it looks from R2:

 R2#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     172.16.255.10 2 [12] 0      Gi1/0      172.16.3.2
17     Pop tag     172.16.255.13 2 [8] 0      Gi2/0      172.16.1.1
--output omitted--
22     Pop tag     172.16.255.10/32  0          Gi2/0      172.16.1.1
24     Pop tag     172.16.255.13/32  0          Gi1/0      172.16.3.2
R2#show mpls forwarding-table lsp-tunnel
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     172.16.255.10 2 [12] 0      Gi1/0      172.16.3.2
17     Pop tag     172.16.255.13 2 [8] 0      Gi2/0      172.16.1.1
R2#

As we can see, the tunnel has been properly created and signaled. There are a variety of ways in which traffic can be forwarded into the tunnel, in my example I’m using Autoroute. Autoroute announces downstream subnets as directly-accessible through the tunnel. You can also disable Autoroute and forward traffic into tunnels manually, based on QoS values, or from particular MPLS VPNs. It’s important to keep in mind that while this example doesn’t utilize MPLS VPNs, it’s just as easy to augment MPLS VPN functionality with MPLS TE tunnels.

R0#show ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 172.16.255.13 on Tunnel2, 01:42:12 ago
  Routing Descriptor Blocks:
  * 172.16.255.13, from 172.16.255.13, 01:42:12 ago, via Tunnel2
      Route metric is 3, traffic share count is 1

R0#

With that being said, let’s try a ping from R4 to R5, it should go through the tunnel.

R4#ping 10.10.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/15/32 ms
R4#
--switch to R2--
R2#show mpls forwarding-table lsp-tunnel
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     172.16.255.10 2 [12] 570        Gi1/0      172.16.3.2
17     Pop tag     172.16.255.13 2 [8] 570        Gi2/0      172.16.1.1
R2#

We can see that the ping succeeds and the byte counter on R2 increments for the tunnel. We now have a successfully-functioning MPLS TE tunnel, let’s see how we can switch the path. First, we’ll create a second explicit route on R0 for the top path:

ip explicit-path name TOP enable
 next-address 172.16.0.2
 next-address 172.16.2.2

We can then yank the old one from the tunnel and add the new one. At this point, RSVP immediately sends a TEAR from head to tail, brings the tunnel down, and signals a new one via R1. Now R1 carries the tunnel from R0 to R3, and R2 carries the tunnel back from R3 to R0. That means traffic to R5 will take the top, and response traffic will take the bottom. Let’s try a ping to see the counters increase on the interim routers:

R4#ping 10.10.1.2 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.10.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 8/14/24 ms
R4#
--switch to R1--
R1#show mpls forwarding-table lsp-tunnel
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
23     Pop tag     172.16.255.10 2 [13] 51870      Gi2/0      172.16.2.2
R1#
--switch to R2--
R2#show mpls forwarding-table lsp-tunnel
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
17     Pop tag     172.16.255.13 2 [8] 52440      Gi2/0      172.16.1.1
R2#

We can see that the packets take a circular route, but everything is working as expected!

You can also add priorities to the explicit paths, that way, if the IGP loses connectivity among any of the tunnel members, it will switch to the next-highest priority (1 being the lowest).

This barely scratches the surface of what is capable with TE tunnels in MPLS. If you’re interested in this sort of thing, I encourage you to check out their different functionality. A few other very cool topics for TE tunnels are interim-terminated tunnels and Fast Reroute. Interim-terminated tunnels allow a tunnel to end on a P router (in MPLS VPN terminology), and Fast Reroute allows the avoidance of a failed device or link with virtually no packet-loss. Below are the full configs of each router.

MPLS QOS

BGP Path Manipulation + Goofy Mnemonic

BGP Path Manipulation + Goofy Mnemonic

Filed under: BGP,Cisco,Cisco Certification,Personal — cciepursuit @ 12:12 pm 
Tags: BGP, CCIE, Certification, Cisco, Cisco Certification, Study Aids

When altering BGP path selection, it is a good idea to have the following table committed to memory:

Method	Direction Applied	Direction Affected	Best Metric
Weight	Inbound	Outbound	Highest
Local Preference	Inbound	Outbound	Highest
AS Path	Outbound	Inbound	Shortest
MED (metric)	Outbound	Inbound	Lowest

This table shows the four most common BGP path manipulation attributes in order of preference (here’s a mnemonic to memorize all of the BGP attributes).  Whenever I am tasked with BGP path manipulation in the lab I quickly recreate the above table with the following mnemonic:

“When applying in London in April, make love.”

W = Weight
A = applied (April reminds me of showers which reminds me of London, so this helps recreate the mnemonic as well)
I = inbound
L = Local Preference
I = inbound
A = AS Path
M = MED (London makes me think of sex for reasons I’ll keep to myself  )
L = lowest

You’re probably thinking “Nice. But that doesn’t look like the entire table to me is represented in that stupid phrase.” And you’re right.  

I write out the table first with the headers only:

Method	Direction Applied	Direction Affected	Best Metric

Then I write ‘Weight’.  The “applying” bit just reminds me that the second header should be “Direction Applied” and not “Direction Affected“.  If you mix up those two headers, then you are in for a very bad experience.  

Method	Direction Applied	Direction Affected	Best Metric
Weight

“In” means inbound (under Direction Applied).  With just this bit of information I can fill in the rest of the “Direction” fields because I know that the first two attributes are applied inbound.  That means the that the last two attributes are applied outbound.  Since the “Direction Affected” is the opposite of the “Direction Applied”, it’s a snap to fill in that information as well.

Method	Direction Applied	Direction Affected	Best Metric
Weight	Inbound	Outbound
	Inbound	Outbound
	Outbound	Inbound
	Outbound	Inbound

So we’re left with ‘London in April, make love’.  ‘London’ = local preference.  ‘in’ is another reminder that Local_Pref is applied inbound (and it makes the goofy sentence flow better).  ‘April’ = AS Path and ‘make’ = MED.

Method	Direction Applied	Direction Affected	Best Metric
Weight	Inbound	Outbound
Local Preference	Inbound	Outbound
AS Path	Outbound	Inbound
MED	Outbound	Inbound

Now all we need is to fill in the ‘Best Metric’ column.  I assume that the highest metric is always the best metric except in the case of the last two attributes.  In this case, ‘love’ = lowest (for MED).  I know that the shortest AS Path is the best (no need to memorize that as it’s pretty logical). 

So now I have the whole table:

Method	Direction Applied	Direction Affected	Best Metric
Weight	Inbound	Outbound	Highest
Local Preference	Inbound	Outbound	Highest
AS Path	Outbound	Inbound	Shortest
MED	Outbound	Inbound	Lowest

So thanks for crawling into my mind.  Pretty empty huh? The exit is through my ears.  

You can create your own mnemonic (I’m sure that mine is not the best) and add more or less detail as needed.  After you are able to recreate this table a couple of times, you’ll find that you won’t need to use the mnemonic, but it’s nice to have it in case you need it.

Route Leaking in MPLS/VPN Networks

Contents

Introduction 
Prerequisites 
      Requirements 
      Components Used 
      Conventions 
Configure 
      Route Leaking from a Global Routing Table into a VRF and Route Leaking from a VRF into a Global Routing Table 
      Route Leaking Between Different VRFs 
Troubleshoot 
Cisco Support Community - Featured Conversations 
Related Information 

 Document ID: 47807

Introduction

This document provides sample configurations for route leaking in an MPLS/VPN environment.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions .

Configure

This sections contains these two configuration examples:

• Route leaking from a global routing table into a VPN routing/forwarding instance (VRF) and route leaking from a VRF into a global routing table
• Route leaking between different VRFs

Note: To find additional information about the commands in this document, use the Command Lookup Tool (registeredcustomers only) .

Route Leaking from a Global Routing Table into a VRF and Route Leaking from a VRF into a Global Routing Table

This configuration describes route leaking from a global routing table into a VRF and route leaking from a VRF into a global routing table.

Network Diagram

This configuration uses this network setup:

Configuration

In this example, a Network Management System (NMS) station located in a VRF is accessed from the global routing table. The provider edge (PE) routers and provider (P) routers have to export the netflow information to an NMS station (10.0.2.2) in a VRF. 10.0.2.2 is reachable via a VRF interface on PE-4.

To access 10.0.2.0/30 from the global table, a static route to 10.0.2.0/30 that points out of the VRF interface is introduced on the PE-4. This static route is then redistributed via Interior Gateway Protocol (IGP) to all PE and P routers. This ensures that all PE and P routers can reach 10.0.2.0/30 via PE-4.

A static VRF route is also added. The static VRF route points to the subnet in the global network that sends the traffic to this NMS station. Without this addition, the PE-4 drops traffic, from the NMS station, that is received on the VRF interface; and the PE-4 sends the ICMP: host unreachable rcv message to the NMS station.

This section uses this configuration:

• PE-4

PE-4
! ip cef ! ip vrf vpn2 rd 200:1 route-target export 200:1 route-target import 200:1 ! interface Serial1/0 ip address 10.1.2.5 255.255.255.252 no ip directed-broadcast ! interface Serial2/0 ip vrf forwarding vpn2 ip address 10.0.2.1 255.255.255.0 no ip directed-broadcast ! ip classless ip route 10.0.2.0 255.255.255.252 Serial2/0 ip route vrf vpn2 10.1.2.4 255.255.255.252 Serial1/0 !

The static routes can now be redistributed into any IGP to be announced network-wide. The same applies if the VRF interface is a LAN interface (for example, Ethernet). The exact configuration command for that is:

ip route 10.0.2.0 255.255.255.252 Ethernet2/0 10.0.2.2

Note: The IP address configured after the interface name is only used by Address Resolution Protocol (ARP), to know what address to resolve.
Note: For 4500 series switches, you must configure static ARP entries in the VRF tables for the respective next hop addresses.

Note: By default, Cisco IOS® software accepts static VRF routes as configured. This might compromise security because it might introduce route leaking between different VRFs. You can use the no ip route static inter-vrf command to prevent the installation of such static VRF routes. Refer to MPLS Virtual Private Networks (VPNs) for more information on the no ip route static inter-vrf command.

Verify

This section provides information to confirm that your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

• show ip route 10.0.2.0—Displays a specified IP address routing entry.
• show ip route vrf vpn2 10.1.2.4—Displays a specified IP address VRF routing entry.

PE-4# show ip route 10.0.2.0

Routing entry for 10.0.2.0/30
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Serial2/0
Route metric is 0, traffic share count is 1

PE-4# show ip route vrf vpn2 10.1.2.4

Routing entry for 10.1.2.4/30
Known via "static", distance 1, metric 0 (connected)
Redistributing via bgp 1
Advertised by bgp 1
Routing Descriptor Blocks:
* directly connected, via Serial1/0
Route metric is 0, traffic share count is 1

Route Leaking Between Different VRFs

This configuration describes route leaking between different VRFs.

Network Diagram

This configuration uses this network diagram:

Configuration

You can not configure two static routes to advertise each prefix between the VRFs, because this method is not supported—packets will not be routed by the router. To achieve route leaking between VRFs, you must use the import functionality of route-target and enable Border Gateway Protocol (BGP) on the router. No BGP neighbor is required.

This section uses this configuration:

• PE-4

PE-4

! ip vrf vpn1 rd 100:1 route-target export 100:1 route-target import 100:1 route-target import 200:1 ! ip vrf vpn2 rd 200:1 route-target export 200:1 route-target import 200:1 route-target import 100:1 ! interface Serial1/0 ip vrf forwarding vpn1 ip address 10.1.2.5 255.255.255.252 no ip directed-broadcast ! interface Serial2/0 ip vrf forwarding vpn2 ip address 10.0.2.1 255.255.255.0 no ip directed-broadcast router bgp 1 ! address-family ipv4 vrf vpn2 redistribute connected ! address-family ipv4 vrf vpn1 redistribute connected !

Verify

This section provides information to troubleshoot your configuration.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

• show ip bgp vpnv4 all—Displays all VPNv4 prefixes that are learned via BGP.

PE-4# show ip bgp vpnv4 all

BGP table version is 13, local router ID is 7.0.0.4
Status codes: s suppressed, d damped, h history, * valid,
> best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf vpn1)
*> 10.0.2.0/24 0.0.0.0 0 32768 ?
*> 10.1.2.4/30 0.0.0.0 0 32768 ?
Route Distinguisher: 200:1 (default for vrf vpn2)
*> 10.0.2.0/24 0.0.0.0 0 32768 ?
*> 10.1.2.4/30 0.0.0.0 0 32768 ?

Note: The other way of leaking routes between VRFs is to connect together two Ethernet interfaces on the PE-4 router and associate each Ethernet interface with one of the VRFs. You also must configure static ARP entries in the VRF tables for the respective next hop addresses. However, this is not a recommended solution for route leaking between VRFs; the previously described BGP technique is the recommended solution.

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Cisco Support Community - Featured Conversations

Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.