Solved: Redistribution EIGRP_2_BGP more - Page 2

Steve Coady · ‎12-05-2013

Jon

I have implementyed the first 2 statements for eigrp

sMc

Steve Coady · ‎12-05-2013

Jon

Here is what they are planning or have implemented on the L3 switch

conf t
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
exit

key chain KEY
key 1
key-string (string)

end

conf t
int fa0/24
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

Yes they wanted redistribution into BGP

sMc

Steve Coady · ‎12-05-2013

Jon

I have advised them I am done for the day. They cannot even validate this due to their current Production network needs.

If I have wasted your time, I sincerely apologize. I know I have benefitted greatly from your help.

I will check this thread tomorrow "go live" day

sMc

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

Steve Coady · ‎12-06-2013

Jon

You stayed up that late just to help?!

"fist bump" Thank you.

It's 08:19 am here in USA. I received an email from my counterparts who stated the config worked in a lab scenario.

I am not sure they could truly create the complexity of this network in a lab, but we will find out tonight.

Any parting thoughts or advice?

sMc

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

Steve Coady · ‎12-06-2013

Jon

Here is what they are planning or have implemented on the L3 switch

conf t
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
exit

They are advertising an aggregate instead of specific subnets.

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

router eigrp 10

network 10.42.21.101 0.0.0.0

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

conf t
int fa0/24
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

Yes they wanted redistribution into BGP

My WAN bgp looks like this:

Site_4

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

neighbor 172.16.a.2 remote-as 11111

neighbor 172.16.a.2 distribute-list 10 in

!

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

The filters are still in place

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

How does this look?

sMc

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

Steve Coady · ‎12-06-2013

Jon

The L3 switch EIGRP has network statements like 192.168.0.0 0.0.255.255 - This is the aggregate I was speaking of. They are not specifically defining their internal vlans.

The (2) interfaces on the WAN. This is where I am confused.

We implemented the tunnels becuase ISP PER was advertsing default route to CE that did not account for ther need

to use a specific site for their internet. This tunnel, we thought would be strictly for 0.0.0.0 default gateway.

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.

Prior to this EIGRP we used the statics to point to their lan interface "to get to 10.42.a x go thru 10.42.b x interface

Each site has it's own BGP AS#. The 61111 is a disguise. There is a common tag amongst every site on the AVPN cloud. I have been referring to that as 11111

sMc

Steve Coady · ‎12-06-2013

Jon

Any specific show commands to use?

Also, I removed the redistribute eigrp from bgp. I should probably put that back.

I was advised by the other team to remove the network statements from under eigrp. That does not make sense to me. Any thoughts on that?

sMc

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

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

Steve Coady · ‎12-06-2013

Jon

sorry, feel foolish.

Yes, ACL 10 covers every single subnet for the existing sites connected to the AVPN cloud.

Yes. No traffic between new and existing sites

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

Yes. Non-internet new traffic can go across the AVPN cloud

sMc

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

Steve Coady · ‎12-06-2013

Jon

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?

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.

sMc

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