fryguypa

Archive for October, 2010|Monthly archive page

Multi-VRF redistribution (a.k.a. route leaking between VRFs)

In Uncategorized on October 28, 2010 at 13:31

I was trying to figure out how to redistribute routes between some VRFs for a project that I am working on.  I won’t get into details of the project or specifics, but ultimately the goal was to be able to leak routes between the VRFs so that we can gain access to the management ports on some devices.  Since VRFs are separate routing tables that co-exist within the same router and cannot see each other, getting communication between them can be difficult at best.

Using some the features of PE routers, you can overcome this limitation by using BGP to redistribute between them.

Below is the diagram that we will be using for this config.  What we will do is configure R3 to redistribute routes between VRF RED and VRF BLUE to enable connectivity.

R7 and R8 are just basic configs like you would do on an ordinary router

Basic R7 Configuration:
!
interface Loopback0
ip address 10.1.7.7 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.37.7 255.255.255.0
!
router eigrp 100
network 10.0.0.0
no auto-summary
!

Basic R8 Configuration:
!
interface Loopback0
ip address 10.1.8.8 255.255.255.0
!
interface FastEthernet0/1
ip address 10.1.38.8 255.255.255.0
!
router eigrp 200
network 10.0.0.0
no auto-summary
!

Now when it comes to R3, we need to be a little creative.  Here we will place the interfaces in the appropriate VRFs and configure EIGRP and BGP.
Note:  Fa0/0 will be in VRF BLUE and Fa0/1 will be in VRF RED

R3 Configuration items:

We will define VRF RED and BLUE here and also assign it an RD (route distinguisher) to ID these routes
Link – http://en.wikipedia.org/wiki/Route_distinguisher

VRF BLUE will have a RD of 1:1 and VRF RED will have a RD of 1:2.
The command route-target will allow us to import and export based on the RD assigned to a given network.

ip vrf BLUE
rd 1:1
route-target export 1:1
route-target import 1:1
route-target import 1:2

ip vrf RED
rd 1:2
route-target export 1:2
route-target import 1:2
route-target import 1:1

Next step is to configure the interfaces in the appropriate VRFs

interface FastEthernet0/0
ip vrf forwarding BLUE
ip address 10.1.37.3 255.255.255.0

interface FastEthernet0/1
ip vrf forwarding RED
ip address 10.1.38.3 255.255.255.0

Since this router will be running EIGRP under different VRFs, we will need to great a top-level AS and then get into the address-family commands to configure the VRF EIGRP AS

router eigrp 1
no auto-summary
!
address-family ipv4 vrf RED ! <- This will allow us to configure EIGRP for VRF RED
network 10.1.38.3 0.0.0.0
no auto-summary
autonomous-system 200 !<- This is the EIGRP AS number for VRF RED
exit-address-family
!
address-family ipv4 vrf BLUE !<- This will allow us to configure EIGRP for VRF BLUE
network 10.1.37.3 0.0.0.0
no auto-summary
autonomous-system 100 !<- This is the EIGRP AS number for VRF BLUE
exit-address-family
!

The next step is going to be to configure a lone BGP session where we can redistribute and place the routes in a VPNV4 environment.  Basically we are creating a lone SP network where VPNV4 routes are “exchanged”.  You do not need a neighbor for this, just a BGP session configured and IPV4 VRF families.
router bgp 1
no synchronization
bgp log-neighbor-changes
no auto-summary
!
address-family ipv4 vrf RED !<- Here we will configure BGP for VRF RED and redistribute routes learned from EIGRP in
redistribute eigrp 200
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf BLUE !<-  Here we configure BGP for VRF BLUE and then redistribute routes learned from EIGRP in
redistribute connected
redistribute eigrp 100
no auto-summary
no synchronization
exit-address-family
!

Lastly we will need to configure EIGRP to redistribute BGP learned routes:

router eigrp 1
!
address-family ipv4 vrf VRF2
redistribute bgp 1 metric 1 1 1 1 1500
exit-address-family
!
address-family ipv4 vrf VRF1
redistribute bgp 1 metric 1 1 1 1 1500
exit-address-family

Once you have done that, R7 can now ping R8

R7#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
D EX    10.1.8.0 [170/2560002816] via 10.1.37.3, 02:26:05, FastEthernet0/3
C       10.1.7.0 is directly connected, Loopback0
D EX    10.1.38.0 [170/2560002816] via 10.1.37.3, 02:26:05, FastEthernet0/3
C       10.1.37.0 is directly connected, FastEthernet0/3

R7-#p 10.1.8.8 so l0

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

A route distinguisher is an address qualifer used only within a single internet service provider‘s Multi-Protocol Label Switching (MPLS) network. It is used to distinguish the distinct Virtual Private Network (VPN) routes of separate customers who connect to the provider.

The route distinguisher is an 8-byte field prefixed to the customer’s Internet Protocol address (IPv4). The resulting 12-byte field is a unique “VPN-IPv4” address. There is a more detailed description in RFC 4364[1]. At the edge of an MPLS provider’s network, a router which connects to a customer’s network is called a Provider Edge (PE) router. Similarly, the customer’s edge router at the other end of the connection is called a Customer Edge (CE) router. Within an MPLS network, a PE router needs to be configured to associate each route distinguisher with routes which lead to a particular CE router. The PE router may be configured to associate all routes leading to the same CE router with the same route distinguisher, or it may be configured to associate different routes with different route distinguishers, even if they lead to the same CE router.

Th

Advertisements

Static ARP entries on NX-OS

In Nexus on October 28, 2010 at 09:55

Oh the joys of Microsoft Network Load Balancing (NLB).  One of the wonderful ways that it is usually configured is using a Multicast MAC address utilizing a Unicast IP address.  Needless to say, most network devices do not like that and thus have problems when devices outside the local LAN attempt to connect to the NLB address.  In order to work around this problem you need to configure a static ARP entry on the gateway so that the devices know how to get to the server.

On IOS, this is not so hard as you configure the a static ARP entry (arp 10.1.1.99 0300.5e11.1111).  That command there on the gateway will usually get things working. You may also need to define where that MAC address lives – and the command to do that would be mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4 This information was obtained from a Cisco document can be found here if you need more information – http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

Now, on the NX-OS it is a little different as you need to configure the static ARP entry under the VLAN interface in order for it to work:

interface Vlan100
no shutdown
description [—-[ Standard VM VLAN ]—-]
no ip redirects
ip address 10.1.1.2/24
ip arp 10.1.1.99 0300.5e11.1111

N7K1# sh ip arp | inc 1111
10.1.1.99       –      0300.5e11.1111   Vlan100

Explanation for the lack of posting lately…

In Uncategorized on October 7, 2010 at 10:06

Well, just wanted to post up what has been g0ing on and the lack of updates.

On Monday (10/4) I sat the CCIE SP lab in RTP  – results I did not pass.  I was not ready, close but need to fill in some gaps. Based on that attempt, I am going to spend some quality time in a training class next month at IPExpert.  Hopefully Marco can fill my head with the knowledge that I need 🙂

Add to that we are going on our yearly trek to Disney on Saturday, things have been busy.

 

I have not abandoned this blog, nowhere near that – just been a little busier with life lately.

 

Jeff

%d bloggers like this: