Solved: Redistribution EIGRP_2_BGP more

Steve Coady · ‎12-05-2013

Jon

I have implementyed the first 2 statements for eigrp

sMc

Jon Marshall · ‎12-05-2013

Steve

if internet going back across the AVPN cloud is fine then we do not need to run EIGRP down the GRE tunnels. You already have that working. Just keep the same config you have now and we can concentrate on the AVPN cloud connectivity.

Keep the statics in sites 1 - 4 and let the return traffic from site 5 go via the AVPN cloud. Then we are halfway there.

I understood that the return path had to be the GRE tunnel but if it isn't lets keep it as simple as possible.

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Steve

In sites 1 - 4 you have one L3 switch connected to one WAN router - is that correct ?

If so, no point in EIGRP, just have a default route on the L3 switch pointing to the WAN router.

Site 5 - where is the internet connection in relation to the L3 switch/WAN router.

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Steve

I am confused by the fact that site 5 already knows how to get back to the other sites as your traceroute proved. So you must be advertising site 1 - 4 subnets into BGP already.

So what isn't working ? I thought we were trying to get the new sites online with the rest of the AVPN cloud but it looks like that is already the case.

Have i missed something ?

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Steve

So you have full network connectivity now but just not using EIGRP is that correct ?

I am happy to help but am struggling to see why the pressing need to "go live" if connectivity is already working. As you can see from our thread (even accounting for my stupidity) it is a complex issue once you start redistributing etc because of a separate internet connection at site 5.

Like i say, happy to help but what do they think they will gain by going to EIGRP ?

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Because I was told I had to implement EIGRP!?!

Okay, EIGRP it is then

Before you bring up EIGRP can you remove any "redistribute eigrp ..." statements you have under the BGP config as we need to get EIGRP between the new sites working first.

So back to where we were. Can you bring up EIGRP between the new sites.

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

No problem.

So for each new site you need to -

1) on the L3 switch add network statements for each site subnet + the subnet link from the L3 switch to the WAN router.

2) on the WAN router add network statements for the subnet link to the L3 switch and the gre tunnel.

3) don't remove any statics yet. The statics are a failsafe ie. they will be used because they have a lower AD than EIGRP so we can then check routing tables to check that EIGRP is there.

And just in case you missed it, please remove from the BGP config the redistribute eigrp command.

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Steve

No problem, we will get there.

By the way when you reply can you reply to the last reponse otherwise it makes it confusing to read.

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Yes, use "network ..." statements under EIGRP.

If someone else is working on the L3 switch this is gong to make it difficult. We need them to advertise the L3 subnets with EIGRP so we can see the routes coming through.

You can't really do this in isolation.

By the way, they want EIGRP but did they insist on EIGRP to BGP redistribution as well ?

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Steve

No problem, it is 1:00 in the morning here in the UK so it's getting a bit late.

I know this is not your doing and i understand you are forced into this but i'm not sure they realise that it is more complex than it perhaps first appears.

You haven't wasted my time at all and if you need further help later on just come back. I apologise if we spent a long time on discussing it before getting to the config, especially as part of that was due to a false assumption by me, but if we had got it wrong we could have had your entire network routing into one of the new sites and i'm sure that would not have gone down too well.

I have to do a similiar sort of thing in my last job where we ran EIGRP internally and BGP to MPLS and we needed to influence traffic to take a certain path which it wouldn't normally choose and the config can get very messy and it's easy to make a mistake and have unforseen consequences. The last thing i wanted was to just write a load of config for you without understanding exactly what we were trying to achieve.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

Can't they supply you with the config they used ? That is the reason to do it in a lab ie. to verify a config to be used on the production devices.

I was thinking about this today, and it's really difficult for you to configure because they don't seem to have told you how they want traffic to flow ie.

1) should all new site non internet traffic use AVPN or GRE tunnels

2) is it okay for internet to go out via GRE but back across AVPN cloud

3) are you concerned with redundancy ie. if a sites GRE tunnel fails then should it try to use AVPN or the other way round.

I'm not going to go on but i cannot see how anyone can configure something without knowing the path the traffic has to take.

Anyway advice -

1) Number one most important point. If you are going to use EIGRP between new sites via GRE and you are redsitributing EIGRP into BGP you absolutely have to only advertise each new sites subnets into BGP. So site 1 redistributes it's own subnets into BGP on site 1 WAN router. But nothing else including the default route it is learning from site 5 via the GRE tunnel.

As i have covered before using site 1 as an example, site 1 receives destinations to all networks (new and existing sites) via BGP. It redistributes these into EIGRP. These get advertised to site 5 via GRE tunnel. Site 5 is redistributing EIGRP into BGP so without filters site 5 will advertise every single network in all your sites back into the AVPN cloud. It works the other way round as well ie. site 1 receives alll routes via EIGRP from site 5.

So unless they are doing some filtering within the AVPN cloud (which i doubt) you could end up wit a real mess and lose network connectivity. So only redistribute into BGP the local sites subnets.

2) Following on from 1). Site 1 will also receives EIGRP routes for the other new sites via EIGRP. Again same as 1) without filters it will advertise them out. Now you may find traffic for another new site comes in via site 1 and has to go via the GRE tunnel. So again another reason to only advertise out each sites local subnet

3) Whether you need to filter the new sites traffic in from BGP depends on how you want non internet new site traffic to go via the AVPN cloud or the GRE tunnels.

4) Filter out the default route from BGP at new sites. Because you using EIGRP and therefore probably receiving a redistribute static default from site 5 in site 1 for example that route will have an AD of 170. BGP will have an AD of 20 so site 1 would use the AVPN cloud for unknown traffic ie. internet traffic.

Just read your last post. If you remove the network statements from EIGRP then EIGRP will not start up up on the GRE or WAN to L3 switch interfaces. So you will not be running EIGRP unless you are using something like "redistibute connected" under the EIGRP config on the WAN router.

Anyway, that's enough for now i think. No 1) is the major one to avoid because this could affect your entire AVPN cloud.

Good luck.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

Useful commands for what you are doing -

EIGRP

=====

"debug ip eigrp" will show what is happening if you are having trouble getting neighbors to establish adjancencies

"sh ip eigrp neigh" will show the EIGRP neighbors this device has

"sh ip eigrp topology" will show you all the routes learned via EIGRP not just the ones in the route table.

BGP

====

two key ones you will need -

"sh ip bgp neigbor x.x.x.x advertised-routes" x.x.x.x is the IP of the peer device. This will show what you are actually advertising from your BGP router. Very important if you are contrtolling which EIGRP routes you are going to redistribute into BGP.

"sh ip bgp neighbor x.x.x.x received-routes" - shows routes on your BGP router received from BGP peer.

Then the obvious one "sh ip route"

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

They are advertising an aggregate instead of specific subnets.

Advertising where, on the BGP router to the AVPN cloud ?

Does this mean you can summarise each new sites subnets with an aggregate address ?

My WAN router eigrp statement looks like this (Site_4):

router eigrp 10

network 10.42.21.101 0.0.0.0

That will start EIGRP on the interface with the IP address of 10.42.21.101. But i understood you have 2 interfaces on the WAN router that needs to run EIGRP ie. the WAN -> L3 switch link and the GRE tunnel ?

neighbor 172.16.a.2 distribute-list 10 in

what does access-list 10 look like ? ie. you are filtering routes received from BGP

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

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

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

ip route 0.0.0.0 0.0.0.0 10.254.0.9

I don't know what the above are doing ?

Are you using a common tag between the new sites ie. in your config you are using tag 61111, is this the same tag used in the other new sites.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

The requirement for this new acquistion sites was to segment their traffic from ours. The

neighbor 172.16.a.2 distribute-list 10 in statement refers to an ACL that blocks my subnets from being accepted by their BGP process. I have a similar ACL blocking their subnets from my sites.

You should probably have mentioned that before as it is quite important information

So if you filtering all the existing sites subnets from being redsitributed into EIGRP all that stuff i kept going on about ie. point 1) in my post today is not an issue because the new sites will never have your existing sites subnets in their EIGRP routing tables.

I appreciate you want answers and not more questions but if i just give you a config without understanding exactly what should happen i could break your network. The above bit of info is a very good example. So can you please answer each of the following points -

1) access-list 10 covers every single subnet for the existing sites connected to the AVPN cloud ?

when you say segment you mean -

2) no traffic between new sites and existing sites

3) internet traffic to go via GRE tunnel

4) non internet new site traffic - can it use the AVPN cloud or not ?

If so it should be fairly easy based on the fact you do not want the new sites to talk to the existing sites. I was assuming you needed that communication but it appears you don't.

Depending on your answers to the above the only tricky thing may be the return traffic from the internet. Does it need to be forced back down the GRE tunnel or can it use the AVPN cloud.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

No problem, just wanted you to understand why i have to keep asking questions ?

Much easier now.

Only remaining question (for the moment) is -

Yes. Internet traffic for the new sites only to go across the GRE tunnel.

Can you just confirm whether that includes both ways ? Definitely out to the internet has to go via GRE tunnel but return traffic ?

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

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

What problems could arise by allowing internet traffic to go back across the AVPN?

It is asymmetric because outbound and inbound are using different paths. The main problem with asymmetric routing is if you have a firewall or other device that needs to see the whole connection. But you don't because the traffic on it's return has already been through the firewall.

If site 1 loses it's AVPN connection but not the GRE tunnel it would still work because site 1, for example, no longer advertises it's routes to the AVPN cloud so site 5 would automatically use the GRE tunnel. So it should work <-- same router so irrelevant.

Up to you really and what the policy is meant to be.

Also the ACL 10 identifies every subnet on my side because at some later date, their sites may need to communicate with specific subnets on my side ant various sites. This was we could remove that specific statement to allow communications.

This makes sense. If you want to be able to do this though then we do need to think about filtering when redistributing EIGRP into BGP at the new sites. Basically at each new site we need an access list that defines that sites subnets. We then use that to restrict what routes are being redistributed into BGP. The same way you are using the distribute list in your BGP config at the moment.

If we do that there is not really a requirement for tags because you have very strict control of which routes are being redistributed. I need to have a quick think about this because using tags is easier in terms of config but the issue is that, again using site 1 as an example, the EIGRP routes for sites 1 subnets do not have a tag associated with them to filter on.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

If I lose AVPN link to site 1, I will also lose the GRE tunnel becuase the tunnel uses the AVPN link to get across. The GRE tunnels is not for redundacy, just for segmenattion.

Yes of course it would, my mistake.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

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

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

You need to be able to do a "sh ip route" on the WAN router and see EIGRP internal routes for all your sites subnets. If you are already doing BGP to EIGRP redistribution you will see EIGRP routes but they should all be external EIGRP ie. you should see an EX for each route so don't confuse these with the internal routes.

Once you see those routes you can add the redistribute EIGRP and remove the network commands. Before you do either -

1) "sh ip bgp neighbor x.x.x.x advertised-routes"

the routes you should see will be the ones beig advertised by the network commands under BGP.

2) when you remove the network commands and add EIGRP to BGP redistribution you then need to do -

clear ip bgp x.x.x.x soft out

3) then you should run 1) again and see if you are seeing the routes being advertised.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

Sorry, i missed this one.

One other question. My bgp currently has redistribute static command. I would want to remove that since the only static would be the Tunnel default gateway, correct?

Yes you do.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

You should add "no auto-summary" to the EIGRP config. Other than that it's fine as long as 10.40.x.101 is the interface connecting to L3 switch.

If you are not seeing routes then do "sh ip eigrp neighbor" on the WAN router. It should show one neighbor and that should be the L3 switch.

Regarding bgp redistribute-internal. It is used to redistribute IBGP into an IGP. I am a little worried they had to use that to get it to work because i can't see any IBGP anywhere. Your peering with the AVPN cloud is EBGP from your config and this is what you would expect when connecting to an MPLS network. I just can't see where IBGP would be used in your setup.

You know i've got this horrible feeling after all this they are going to tell you they actually wanted a completely different setup and you need to do it again.

One last thing. It's 23.00 here in the UK. How long do you need me around in case you have any problems ? If you do want me around that's fine just say, just want a rough idea.

Jon

View solution in original post

Jon Marshall · ‎12-06-2013

Steve

Sorry but i'm shattered so i'm signing off now. I hope it goes alright. I'll check in tomorrow to see how it's going or went.

Hope it goes well.

Jon

View solution in original post

Jon Marshall · ‎12-07-2013

Steve

Great news. Not sure why the management subnet was not showing up unless it is not connected or was not covered by a network statement under EIGRP config as this should have been advertised by the L3 switch.

Many thanks for all the ratings and glad we got there in the end.

Jon

View solution in original post

Jon Marshall · ‎12-05-2013

Steve

if internet going back across the AVPN cloud is fine then we do not need to run EIGRP down the GRE tunnels. You already have that working. Just keep the same config you have now and we can concentrate on the AVPN cloud connectivity.

Keep the statics in sites 1 - 4 and let the return traffic from site 5 go via the AVPN cloud. Then we are halfway there.

I understood that the return path had to be the GRE tunnel but if it isn't lets keep it as simple as possible.

Jon

Jon Marshall · ‎12-05-2013

Steve

In sites 1 - 4 you have one L3 switch connected to one WAN router - is that correct ?

If so, no point in EIGRP, just have a default route on the L3 switch pointing to the WAN router.

Site 5 - where is the internet connection in relation to the L3 switch/WAN router.

Jon

Steve Coady · ‎12-05-2013

Jon

Site_1 - 4 have 1 L3 switch to one WAN router

Because I was told I had to implement EIGRP!?!

New acquisition, new sites, their own network team!!

Working on fulll integration

AVPN Cloud> AVPN Site_5 router > L3 switch > Firewall>Router (probably)>Internet

sMc

Jon Marshall · ‎12-05-2013

Because I was told I had to implement EIGRP!?!

Okay, EIGRP it is then

Before you bring up EIGRP can you remove any "redistribute eigrp ..." statements you have under the BGP config as we need to get EIGRP between the new sites working first.

So back to where we were. Can you bring up EIGRP between the new sites.

Jon

Steve Coady · ‎12-05-2013

Jon

I have removed the residtribute eigrp statements.

I have to admit, I was impatient and configured the following commands on each of rthe WAN routers

conf t

route-map BGP-to-EIGRP permit 10

set tag 61111

!

route-map EIGRP-to-BGP deny 10

match tag 61111

!

route-map EIGRP-to-BGP permit 20

match ip address any

!

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

!

key chain KEY

key 1

key-string hdstripencrypt

!

router bgp 61111

redistribute eigrp 10 route-map EIGRP-to-BGP

bgp redistribute-internal

!

int Gi0/0

ip authentication mode eigrp 10 md5

ip authentication key-chain eigrp 10 KEY

ip hello-interval eigrp 10 5

ip hold-time eigrp 10 15

end

sMc

Jon Marshall · ‎12-05-2013

Steve

No problem, we will get there.

By the way when you reply can you reply to the last reponse otherwise it makes it confusing to read.

Jon

Jon Marshall · ‎12-05-2013

Steve

I am confused by the fact that site 5 already knows how to get back to the other sites as your traceroute proved. So you must be advertising site 1 - 4 subnets into BGP already.

So what isn't working ? I thought we were trying to get the new sites online with the rest of the AVPN cloud but it looks like that is already the case.

Have i missed something ?

Jon

Steve Coady · ‎12-05-2013

Jon

I have network statements under BGP for each subnet at each site.

Site_3

router bgp 61111

no bgp log-neighbor-changes

bgp redistribute-internal

network 10.41.a.0 mask 255.255.255.0

network 10.41.b.0 mask 255.255.255.0

network 10.41.c.0 mask 255.255.255.0

network 10.41.d.0 mask 255.255.255.0

network 10.41.e.0 mask 255.255.255.0

network 10.41.f.0 mask 255.255.255.0

network 10.41.g.0 mask 255.255.255.0

network 10.41.h.0 mask 255.255.255.0

network 10.41.i.0 mask 255.255.255.0

network 10.41.j.0 mask 255.255.255.0

network 10.41.t.0 mask 255.255.255.0

network 10.41.u.0 mask 255.255.255.0

network 10.41.v.0 mask 255.255.255.0

network 10.41.w.0 mask 255.255.255.0

network 10.41.x.0 mask 255.255.255.0

network 10.41.y.0 mask 255.255.255.0

network 10.41.z.0 mask 255.255.255.0

redistribute static

redistribute eigrp 10 route-map EIGRP-to-BGP

neighbor 172.16.a.2 remote-as 11111

neighbor 172.16.a.2 distribute-list 10 in

!

ip route 10.41.a.0 255.255.255.0 10.41.b.1 track 2 - Once the redistrib config is in place, do I need to remove this statement?

ip route 10.41.b.0 255.255.255.0 10.41.b.1 track 2

ip route 10.41.c.0 255.255.255.0 10.41.b.1 track 2

ip route 0.0.0.0 0.0.0.0 10.254.0.13

We were using statics b4. They wanted to implement eigrp and then redistribute. With the tunnelsI was not surte what needed toi be done and the "go live" for this networkmerger is tomorrow night. With a last minute change, I needed some guidance so I did not cause any issues.

sMc

Jon Marshall · ‎12-05-2013

Steve

So you have full network connectivity now but just not using EIGRP is that correct ?

I am happy to help but am struggling to see why the pressing need to "go live" if connectivity is already working. As you can see from our thread (even accounting for my stupidity) it is a complex issue once you start redistributing etc because of a separate internet connection at site 5.

Like i say, happy to help but what do they think they will gain by going to EIGRP ?

Jon

Steve Coady · ‎12-05-2013

Jon

The "go live" has cascading effect. Other critical functions have to swing over. End of calendar year brings renewal of certain contracts they would rather not have to renew (Circuits etc...)

sMc

Steve Coady · ‎12-05-2013

Jon

They just had to have eigrp!

It is a complexs issue. Thank you for your time and patienjce.

Also, this is Phase_1 of a 3-Phase integration

sMc

Jon Marshall · ‎12-05-2013

No problem.

So for each new site you need to -

1) on the L3 switch add network statements for each site subnet + the subnet link from the L3 switch to the WAN router.

2) on the WAN router add network statements for the subnet link to the L3 switch and the gre tunnel.

3) don't remove any statics yet. The statics are a failsafe ie. they will be used because they have a lower AD than EIGRP so we can then check routing tables to check that EIGRP is there.

And just in case you missed it, please remove from the BGP config the redistribute eigrp command.

Jon

Steve Coady · ‎12-05-2013

Jon

I do not have access to their L3 switch. There is someone there working on this, I am told.

"on the WAN router add network statements for the subnet links to the L3 switch and the gre tunnel" Not sure I understand this.

Router eigrp

network ......

or something else

sMc

Jon Marshall · ‎12-05-2013

Yes, use "network ..." statements under EIGRP.

If someone else is working on the L3 switch this is gong to make it difficult. We need them to advertise the L3 subnets with EIGRP so we can see the routes coming through.

You can't really do this in isolation.

By the way, they want EIGRP but did they insist on EIGRP to BGP redistribution as well ?

Jon