How to form EIGRP Adjacency between global routing table and routing table of a vrf-lite

[yuchenglai]

Hey everyone,

I was wondering if anyone knows how to form EIGRP adjacencies between the global routing table and routing table of a vrf-lite on a 6500 running 12.2(33)SXI2a code.

For example, please the consider current configuration which currently provides no capability to form EIGRP adjacencies between the global routing table and the routing table of vrf ALPHA:

router eigrp 500

!

address-family ipv4 vrf ALPHA
  autonomous-system 501
  network 10.0.16.0 0.0.7.255
  network 10.0..24.0 0.0.3.255
  network 10.0.28.0 0.0.1.255
  network 10.0.30.0
  no auto-summary
exit-address-family
!

To form adjacencies between the global routing table and the routing table of vrf ALPHA, does "autonomous-system 501" need to be changed to "autonomous-system 500" under "address-family ipv4 vrf ALPHA"?

[Giuseppe Larosa · Accepted solution]

Hello David,

if you want to build an EIGRP adjacency in VRF and in GRT you need:

two SVIs bridged in some way  (for example a transparent context in a FWSM)

the same EIGRP AS number so autonomous-system ASN must match AS number on other SVI

one SVI needs to have a modified MAC address  (all SVIs on one device use the same MAC address this is a key point)

example

interface Vlan617
description GRT<->VRF
>>>> mac-address 000e.843b.e3c2
mtu 1520
ip address 10.x.y.1 255.255.255.240

the other SVI in VRF has an ip address in the same IP subnet

interface vlan 620

ip vrf forw vrf1

ip address 10.x.y.2 255.255.255.240

!

some other tuning are needed on FWSM if you are using it or you use just a cable between two ports one in vlan X and one in vlan Y?

Hope to help

Giuseppe

[yuchenglai]

Giuseppe,

To expand your sample configuration to reflect the 3 prerequisite you mentioned that must be met in order to form EIGRP adjacency between Global Routing Table of 6500 and a VRF within it, I have come up with the following configuration.  So now int vlan617 and int vlan620 should now be able to form EIGRP adjacency?

router eigrp 500

network 10.x.y.0 0.0.0.15

!
address-family ipv4 vrf ALPHA
  autonomous-system 501
  network 10.x.y.0 0.0.0.15
  no auto-summary
exit-address-family

interface Vlan617
description GRT<->VRF
mac-address 000e.843b.e3c2
mtu 1520
ip address 10.x.y.1  255.255.255.240

interface vlan 620

ip vrf forwarding ALPHA

ip address 10.x.y.2  255.255.255.240

[Giuseppe Larosa · Accepted solution]

Hello David,

the EIGRP AS number must match to build the adjacency, so you need to use

address-family ipv4 vrf ALPHA
  autonomous-system 500

in order to match with the SVI in global routing table

Hope to help

Giuseppe

[yuchenglai]

Giuseppe,

Thank you for your advice.  I will need to try this out in my lab before implementing on the production network.

Also, what range of mac-addresses would you use to overwrite the BIA mac-address on the interface?  A CCIE once told me I should use mac-addresses in the 4000.xxxx.xxxx range as that was equivalent to RFC 1918 private ip addresses.

[Giuseppe Larosa]

Hello David,

thanks for kind remarks

you need to use a unicast MAC address that means I/G set to 0 ( bit 8 in most significant byte the first to go on wire).

In our network we used a slight modification of BIA in the last significant 3 bytes

I've seen 4000.xxxx.yyyy  used in SNA  DLSW+ networks when a virtual MAC addres is assigned to a resource, so there is a meaning on this.

it is so, consider that ethernet sends the bits of each byte from rightmost (least significant ) to leftmost (most significant)

Second bit sent on wire when set means privately assigned

so 02 on wire means ---> 40

0000 0010 -> 0100 0000 as ethernet MAC = 40

see

http://standards.ieee.org/regauth/groupmac/tutorial.html

Hope to help

Giuseppe

[yuchenglai]

Giuseppe,

After reading http://en.wikipedia.org/wiki/MAC_address and http://standards.ieee.org/regauth/groupmac/tutorial.html, I believe I have a rudimentary grasp on this subject.

If I was to capture traffic on an ethernet network and see a mac-address of 0200:xxxx:yyyy, would this be considered a unicast and locally administered mac-address?

[Giuseppe Larosa]

Hello David,

you are right I have been trapped myself doing explanation in my previous post.

>> If I was to capture traffic on an ethernet network and see a mac-address  of 0200:xxxx:yyyy, would this be considered a unicast and locally  administered mac-address?

yes, the second bit to go on wire on ethernet is bit 1 (second from the right) and this is the U/L bit ( 0 -> universal, 1locally administered)

token ring sends the bits in a different way (canonical format) so in the case of token ring second bit on wire is the second bit from the left.

first bit on wire is the I/G bit (0-> unicast, 1-> multicast group address)

sniffers automatically convert the MAC address in the format we read it that is different then what is seen on wire.

Hope to help

Giuseppe

[yuchenglai]

Giuseppe,

I created vlans 2 & 3 and configured one switch access port to be in vlan 2 and another switch access port to be in vlan 3.  Both of those access ports are on the same module in my 6506.  Then I patched both of those ports together via an ethernet cable.

Of course, I saw native vlan mismatches messages generated regarding those two switch ports.

I was actually able see EIGRP neighbor adjacency form between the SVI for vlan 3 (on global routing table) and SVI for 2 (VRF routing table), but the 6506 also generated the following message:

%DUAL-5-NBRCHANGE:  EIGRP-IPv4 (66) 2: Neighbor 192.168.255.1 (vlan2) is down:  Interface PEER-TERMINATION received

%DUAL-5-NBRCHANGE:  EIGRP-IPv4 (271) 2: Neighbor 192.168.255.2 (vlan3) is down:  retry limit exceeded

After that EIGRP neighbor adjacency would form againi between SVIs for vlan 2 & 3.

The above process of "peer-termination" and reforming of neighbor adjacency between the GRT and the VRF SVIs repeated itself until I changed the mac-address of the SVI for vlan 2 to 0200.0000.0001.  To confirm that changing the mac-address on SVI vlan 2 actually resolved the "peer termination" issue, I reset the mac-address SVI vlan 2 back to factory default with the expectation that I would see the "peer termination" issue again.  Much to my suprise, I did not see the "peer termination" issue after reseting the mac-address of SVI vlan 2 back to factory default.  So I am now wondering what caused the "peer termination" issue?