cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
975
Views
10
Helpful
9
Replies

EIGRP adress-family

pat1848
Level 1
Level 1

Hi

I've a question about EIGRP. If i configure an adress-familiy in EIGRP to route a vrf, it's not possible to configure two eigrp processes within this family.

I have two neigbors with different AS - how is it possible to redistribute this two processes within the same vrf(address-family)?

Any suggestion?

cheers

patrick

9 Replies 9

attrgautam
Level 5
Level 5

Patrick

I dont think it is possible - you may try configuring 2 different VRF(different RD) for both AS each running a different EIGRP instance for both and having the same route-targets. Not sure if it is elegant, but might just work. Please note that it should be a MPLS-VPN.

If I am correct(Honest, I am not sure) then the connectivity is through BGP and not exactly with EIGRP.

Hi,

To add more details to get it working, you can configure a single instance if you like.

For eg, one global eigrp instance and then you can specify local AS just like in BGP for peering with different AS vrf's.

router eigrp 1

auto-summary

!

address-family ipv4 vrf A

network 10.1.1.0 0.0.0.255

no auto-summary

autonomous-system 10 <---- Local AS

exit-address-family

!

Now each vrf would be routed in its own domain, with any RD or RT.

If you have this challenge at one point and would like to get the routes across you can configure standalone BGP with no peerings.

Configure address-families for each VRF redistribute the respective eigrp into BGP and vice versa, import and export the RT. And you are set to go.

Here is a sample config to make the setup work.

!

ip vrf A

rd 100:1

route-target export 100:1

route-target import 100:1

route-target import 100:2

!

ip vrf B

rd 100:2

route-target export 100:2

route-target import 100:2

route-target import 100:1

!

router bgp 1

no synchronization

bgp log-neighbor-changes

no auto-summary

!

address-family ipv4 vrf B

redistribute eigrp 20

no synchronization

exit-address-family

!

address-family ipv4 vrf A

redistribute eigrp 10

no synchronization

exit-address-family

!

router eigrp 1

auto-summary

!

address-family ipv4 vrf B

redistribute bgp 1 metric 10000 100 255 1 1500

network 20.1.1.0 0.0.0.255

no auto-summary

autonomous-system 20

exit-address-family

!

address-family ipv4 vrf A

redistribute bgp 1 metric 10000 100 255 1 1500

network 10.1.1.0 0.0.0.255

no auto-summary

autonomous-system 10

exit-address-family

!

HTH-Cheers,

Swaroop

Hi Swaroop

I may have to admit, that i have just VRF Lite. It's probably in the wrong discussion forum. So there's no MPLS and i have just one VRF Instance which is peering to two EIGRP routers in different autonomous systems. I think it's not possible because i can't configure two autonoumos-systems in a adress-familiy.

cheers

patrick

You are right...This will not be possible without MPLS as you configure only one autonomous system. Unless you run 2 EIGRP instances like this

router eigrp 100

address-family ipv4 vrf A

autonomous system 50

redistribute eigrp 40

router eigrp 200

address-family ipv4 vrf A

autonomous system 40

But sadly this doesnt work, so you may need to turn on MPLS :(

Gautam, the sample config given does not need MPLS enabled on any interfaces neither LDP or VPNV4 BGP peerings.

And also as given in your config you cannot assign the same VRF to 2 Eigrp processes.

Patrick, From your first post I got it that you are trying to implement Vrf-Lite (without MPLS/LDP on any interfaces or MPBGP peering)

Thats the reason I gave a sample config to make things clearer. If you go ahead and implement the config as given modfying your VRF names and RT's and AS's it will just simply work, without MPLS enabled on any interfaces.

Give the config a try to avoid confusion.

HTH-Cheers,

Swaroop

Hi swaroop

I'm sorry i didn't recognize your solution for the first time... i just read quickly through... you are right, in this case it's possible..

I'll have a try

Thanks a lot

Sure Patrick, do give it a try...if there is any problem with the implementation i would be glad to help.

you would see the other EIGRP AS routes as external in each EIGRP AS with this method, which is consistent with what would have been achieved with redistrbuting different EIGRP AS routes into each other.

HTH-Cheers,

Swaroop

Swaroop

That was certainly new for me. Thanks. I went back to 4364 and this is what it told me

'

4.3.6. Route Distribution Among VRFs in a Single PE

It is possible to distribute routes from one VRF to another, even if

both VRFs are in the same PE, even though in this case one cannot say

that the route has been distributed by BGP. Nevertheless, the

decision to distribute a particular route from one VRF to another

within a single PE is the same decision that would be made if the

VRFs were on different PEs. That is, it depends on the Route Target

attribute that is assigned to the route (or would be assigned if the

route were distributed by BGP), and the import target of the second

VRF.

"

So it should work for Patrick.

Gautam,

What the 4.3.6 sections means is if 2 VRF are on a same PE then there is obviosuly no BGP running back to back to the same PE,

(No BGP peering from PE1 to PE1) so we cannot say that it is distributed by BGP (for eg: like in PE1 to PE2).

But Never the less the route distribution is totally dependent upon Route Targets (for which again BGP is required even though its standalone with no peerings) as the route distribution is dependent upon the assigned/configured route-targets and the import target in the other VRF on the same PE.

So we introduced a standalone BGP to make the RT function work and help distribute routes from one VRF to other.

(as the same VRF cannot be configured in 2 different EIGRP processes with different AS's)

I would be glad to clarfiy further, as much as i understand.

HTH-Cheers,

Swaroop

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: