cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3094
Views
0
Helpful
61
Replies

Redistribution EIGRP_2_BGP more

Steve Coady
Level 1
Level 1

Jon

I have implementyed the first 2 statements for eigrp

sMc
61 Replies 61

Steve

Sorry, forgot to answer -

If return traffic can go across the AVPN, wouldn't that be easiest/best.

It would be easier because on the WAN router at site 5  it has EIGRP internal routes to site 1, for example, with AD 90 and BGP learned routes to site 1 via the AVPN cloud. It would naturally choose the AVPN cloud.

Jon

Jon

This what I have configured at Site_4

Please review and advise.

Site_4# sh run

!

key chain KEY

key 1

  key-string (string)

!

interface Tunnel0

description GRE2_Site_5

ip address 10.254.0.10 255.255.255.252

ip mtu 1400

ip tcp adjust-mss 1360

tunnel source 172.16.42.5    Site_4 WAN ip

tunnel destination 172.16.41.1    Site_5 WAN ip

!

interface GigabitEthernet0/0

description Triplefin_Scottsdale_LAN

ip address 10.42.b.101 255.255.255.0

no ip redirects

no ip proxy-arp

ip authentication mode eigrp 10 md5

ip authentication key-chain eigrp 10 KEY

ip flow ingress

duplex full

speed 1000

!

router eigrp 10

network 10.42.b.101 0.0.0.0

redistribute bgp 64551 metric 10000 10 255 1 1500 route-map BGP-to-EIGRP

Do I need network statements here????

!

router bgp 61111

no bgp log-neighbor-changes

bgp redistribute-internal

network 10.42.a.0 mask 255.255.255.0

network 10.42.b.0 mask 255.255.255.0

network 10.42.c.0 mask 255.255.255.0

network 10.42.d.0 mask 255.255.255.0

network 10.42.e.0 mask 255.255.255.0

network 10.42.f.0 mask 255.255.255.0

network 10.42.g.0 mask 255.255.255.0

network 10.42.h.0 mask 255.255.255.0

network 10.42.i.0 mask 255.255.255.0

network 10.42.j.0 mask 255.255.255.0

network 10.42.t.0 mask 255.255.255.0

network 10.42.u.0 mask 255.255.255.0

network 10.42.v.0 mask 255.255.255.0

network 10.42.w.0 mask 255.255.255.0

network 10.42.x.0 mask 255.255.255.0

network 10.42.y.0 mask 255.255.255.0

network 10.42.z.0 mask 255.255.255.0

redistribute static

Do i need to add the redistribute eigrp route-map here???

neighbor 172.16.42.6 remote-as 11111

neighbor 172.16.42.6 distribute-list 10 in

!

ip route 10.42.a.0 255.255.255.0 10.42.b.2 track 2

ip route 10.42.b.0 255.255.255.0 10.42.b.2 track 2

ip route 10.42.c.0 255.255.255.0 10.42.b.2 track 2

ip route 0.0.0.0 0.0.0.0 10.254.0.9

!

!

route-map BGP-to-EIGRP permit 10

set tag 64551

!

route-map EIGRP-to-BGP deny 10

match tag 64551

!

route-map EIGRP-to-BGP permit 20

match ip address any

!

!

sMc

Jon

Please review and advise above config for Site_4 at your earliest convenience.

sMc

Steve

Can i just ask one question.

The requirement to use EIGRP is fine, not questioning that. But that is EIGRP within each new site and for redistribution to and from EIGRP.

Is part of that requirement to also run EIGRP down the GRE tunnels ?

Jon

Jon

I do not think so. It was never stated to make sure EIGRP runs down the tunnel.

If we have EIGRP running down the tunnel and across BGP, that sounds like it would cause problems.

The tunnel was specifically implemented to provide the 0.0.0.0 back to the internet for these 5 sites.

sMc

Steve

Do I need network statements here????

You will need to include the GRE tunnel in a network statement.

redistribute static

I suspect you won't need this if it is just for statics pointing back to the LAN switch

Do i need to add the redistribute eigrp route-map here???

You will need to remove all the network statements from BGP.

route-map BGP-to-EIGRP permit 10

set tag 64551

!

route-map EIGRP-to-BGP deny 10

match tag 64551

!

route-map EIGRP-to-BGP permit 20

match ip address any

!

I'm not sure you need to use tags at all. If you do i would use a common tag. The issue is that site 4 learns routes from BGP and redistributes them into EIGRP and tags them with 64551. It then sends these routes down the GRE tunnels so when site 1, for example, receives these, it could, if you were using a different tag allow them to be readvertised back out the AVPN cloud.

I say might because i can't test it and i don't think they would anyway. It's to do with EIGRP internal vs external routes but it would be too long to explain (unless you really need me to).

However the last entry "permit ip address any"  should be changed. If you don't what happens is site 1 receives internal EIGRP routes from site 4. These routes are not the one redistributed from BGP, these routes are the internal EIGRP routes for site 4. Site 1 then redistributes these into BGP. So site 1 is saying to get to site 4 come to me. So is site 4, but so are sites 2, 3 and 5.

So what i would do, although i'm still not entirely sure of the whole requirements is use an access-list in that last statment which is an acl containing only site 4's subnets. That way you are sure only site 4 is advertising it's own subnets to the AVPN cloud. If you do this the tag but becomes less relevant but probably still worth keeping.

Jon

Jon

So Eigrp config should look like?:

           router eigrp 10

            network 10.42.b.101 0.0.0.0

            redistribute bgp 64551 metric 10000 10 255 1 1500 route-map BGP-to-EIGRP

            redistribute static

Each site has it's own tags corresponding to the BGP AS# for that site. What problems will this cause?

Why do I need to remove all the network statemenst from BGP?

sMc

Steve

You need a "network" statement in the EIGRP config for the GRE tunnel but please see my last post about is it really needed ?

Tags, only what i have described in terms of possible redistribution ?

You need to remove the BGP network statements because you are redistributing EIGRP into BGP. Those network statements are presumably for the site 4s internal networks. You don't need them if you are advertising them into EIGRP and then redistributing EIGRP into BGP.

But don't just remove them until you have the full config ready as well as having full EIGRP routes for site 4 otherwise you will cut it off.

Jon

Jon

I have the statics for the LAN segments and I have the static for the 0.0.0.0 across the tunnel

To use the redistribute static would it be better to remove the statics about the LAN segments and only keep the tunnel statement?

The EIGRP on the WAN router is supposed to send the EIGRP on the L3 switch the default gateway. That is why i have the network 10.42.x.101 0.0.0.0 in my WAN router EIGRP config statement.

Leaving the BGP network statements and using the route-map statements I already have will cause problems after EIGRP comes up?  Is it disruptive or just inefficient?

sMc

Steve

I have the statics for the LAN segments and I have the static for the 0.0.0.0 across the tunnel

To use the redistribute static would it be better to remove the statics about the LAN segments and only keep the tunnel statement?

If you are keeping the tunnel statement why are you using EIGRP down the tunnels ?

I am really trying to help here but virtually every post seems to contradict the last. I have worked in large organisations myself and i understand the pressures but i simply cannot understand why, if they have tested this in a lab, they then did not give you the config. I also cannot understand why they have not told you how traffic should flow in and out of the new sites.

Basically it seems to be that they have tested it, decided on how traffic will flow and then just told you to implement it without any details.

You cannot configure any network devices without understanding what it is you are trying to achieve.

I still have no idea of what role EIGRP is meant to play in this and i feel like i am redesigning your network on the fly. I cannot make decisions about how traffic should flow within your network, that's not for me to.do. So when you ask if something should be removed or added it's not as simple as saying yes or no because you have to understand that each change we make can have significant effects on how traffic flows, how routing decisions are made etc.

I can't just say yes or no and leave you to deal with the consequences because i just won't do that.

I am more than happy to help you out, l  really am, and i suspect this whole issue is not of your making.  So i'm not abandoning you but there is only so much i can do.

Jon

Jon

EIGRP is not going to be used across the tunnel. Only on the AVPN.

sMc

Steve

Assuming we can use statics down the GRE tunnel -

Site_4# sh run

!

key chain KEY

key 1

key-string (string)

!

interface Tunnel0

description GRE2_Site_5

ip address 10.254.0.10 255.255.255.252

ip mtu 1400

ip tcp adjust-mss 1360

tunnel source 172.16.42.5 Site_4 WAN ip

tunnel destination 172.16.41.1 Site_5 WAN ip

!

interface GigabitEthernet0/0

description Triplefin_Scottsdale_LAN

ip address 10.42.b.101 255.255.255.0

no ip redirects

no ip proxy-arp

ip authentication mode eigrp 10 md5

ip authentication key-chain eigrp 10 KEY

ip flow ingress

duplex full

speed 1000

!

router eigrp 10

network 10.42.b.101 0.0.0.0

redistribute bgp 64551 metric 10000 10 255 1 1500 route-map BGP-to-EIGRP

no auto-summary

 

!

router bgp 61111

no bgp log-neighbor-changes

bgp redistribute-internal

redistribute eigrp 10 route-map EIGRP-to-BGP

neighbor 172.16.42.6 remote-as 11111

neighbor 172.16.42.6 distribute-list 10 in

!

ip route 0.0.0.0 0.0.0.0 10.254.0.9

route-map BGP-to-EIGRP permit 10

set tag 64551

!

route-map EIGRP-to-BGP deny 10

match tag 64551

!

route-map EIGRP-to-BGP permit 20

match route-type internal    

If we use statics down the tunnel then you you can use the above. The route map uses your tags which probably aren't needed but it won't hurt. The last statement matches all internal EIGRP (AD 90) which because we are using statics will only be routes for site 4s internal networks.

No need to add GRE tunnel IP under the EIGRP config.

No need for static routes to LAN switch as you should get them from EIGRP.

You can replicate this config on all sites but site 5 is still a problem.

In site 5 we need statics for each of the other new sites pointing to the correct GRE tunnel. So there are a fair few statics you need on the site 5 WAN router.

If you do this we now have traffic in the reverse of before ie.

1) traffic to internet 

site1 -> GRE -> site 5 -> internet

internet -> site 5 -> GRE tunnel

so that works fine.

2) non internet traffic

site 1 -> sites 2, 3, 4

site 1 -> AVPN cloud -> sites 2,3,4

sites 2,3,4 -> AVPN cloud site 1

sites 1,2,3,4 -> AVPN cloud -> site 5

** site 5 -> GRE tunnel -> sites 1,2,3,4

** this is the only one with asymmetric traffic.

 

Jon

Steve

Site 5 can use the same config but in addition you need static routes for each of the new sites.  If you need help i can have a look at subnets and see if they can be summarised so you can cut down on the number of static routes you need to add.

Note you could actually just redistribute EIGRP into BGP without a route map and vice versa but i don't know whether you wanted to do something with those tags so that's why i simply added the last statement to the EIGRP-to-BGP route map.

Jon

Jon

Since we won't be implementing EIGRP down the GRE tunnel why would we need the statics if BGP already knows where the local subnets comes from?

L3 LAN switch is advertising their local subnets to AVPN router EIGRP

      router eigrp 10
      no auto-summary
      eigrp stub connected static
      network 10.0.0.0 0.255.255.255
      network 172.16.0.0 0.0.240.255
      network 192.168.0.0 0.0.255.255

AVPN router EIGRP config redistributes the routes received from L3 EIGRP into BGP

       router eigrp 10

       no auto-summary

       Network 10.41.x.x (LAN Gi0/0) 0.0.0.0

       Redistribute BGP 61111

       redistribute bgp 61111 metric 10000 10 255 1 1500 route-map BGP-to-EIGRP

        router bgp 64551

        no bgp log-neighbor-changes

        bgp redistribute-internal - Does this command replace all the Network commands?

        redistribute eigrp 10 route-map EIGRP-to-BGP

        neighbor 172.16.42.6 remote-as 13979

        neighbor 172.16.42.6 distribute-list 10 in

Any route not in the route table get sent across the GRE tunnel

         ip route 0.0.0.0 0.0.0.0 10.254.0.9

The default route is only static needed because all LAN subnets are learned via EIGRP and redistributed via BGP.

sMc

Steve

Technically you don't need the statics at site 5 but this would mean asymmetric traffic for internet connectivity to site 5 ie.

internet traffic

==========

sites 1,2,3,4 -> GRE tunnel (because of static default route) -> site 5 -> internet

internet -> site 5 -. AVPN cloud -> sites 1,2,3,4

non internet traffic between sites

========================

would all go via the AVPN cloud ie outbound and inbound would not use the GRE tunnel.

If this segmentation is acceptable then you are right, why bother with statics at site 5 ?

If you decided that was okay then yes the config supplied would achieve that. Just make sure you have default route in sites 1 - 4 pointing down the GRE tunnel to site 5. That would be it.

bgp redistribute-internal - Does this command replace all the Network commands?

No it's nothing to do with the EIGRP internal routes. Not even sure why it was there as it is to do with IBGP not EBGP and your'e not using IBGP as far as i can see.

The thing that replaces all the "network ..." statements is the EIGRP into BGP redistribution. So instead of manually configuring them you simply redistribute the EIGRP internal routes into BGP.

Like i said i don't even believe in this setup you need the route maps because you don't get a redistribution loop on the same router but i can't see the harm in having them and it's always a good idea to tagg routes with mutual redistribution.

I apologise for my rather strong post a while back and i wasn't having a go at you, more i was just getting frustrated with the task you seem to have been assigned without the proper information.

When are you looking to make the changes and do you know if they have setup EIGRP on the L3 switches yet ?

Jon

Review Cisco Networking products for a $25 gift card