«

All,

Hi, any assistance on this would be great, we're all out of ideas at
the moment.

I have 2 x central L3 switches (3560's - Primary & Secondary) running
BGP to a private MPLS cloud. I redistribute BGP (WAN) into EIGRP
(LAN), there is no iBGP.

The above switches are connected to the internal LAN and to each other
via one of their Gig Interfaces.

A number of remote branches connect to the same MPLS cloud and back to
the central site.

At the central site routes to these remote locations are learned via
eBGP with a metric of 20. However, routes to 3-4 branches are learned
in EIGRP by the Primary via the Secondary (AD 170). If I bounce the
Gig link between them everything is OK for a while, then a few days
later, the EIGRP route pops up again.

There is no inbound route filtering on the 3560's as we wanted to see
all routes.

The routes concerned do show in the BGP table with the next hop as the
eBGP peer. For some reason this route is ignored and the EIGRP path is
followed.

Any ideas ?

Regards

Darren

Darren,

Turn on "Route Change Log" on both protocols, or turn on debugging for the
redistribution, and see when it happens.

Good luck,

Mike
CCNP, CCDP, CCSP, Cisco Voice, MCSE W2K, MCSE+I, Security+, etc.
CCIE R&S (in progress), CCIE Voice (in progress)
------
Headset Adapters for Cisco IP Phones
www.ciscoheadsetadapter.com
www.headsetadapter.com


"Darren Green" <> wrote in message
news: ps.com...
> All,
>
> Hi, any assistance on this would be great, we're all out of ideas at
> the moment.
>
> I have 2 x central L3 switches (3560's - Primary & Secondary) running
> BGP to a private MPLS cloud. I redistribute BGP (WAN) into EIGRP
> (LAN), there is no iBGP.
>
> The above switches are connected to the internal LAN and to each other
> via one of their Gig Interfaces.
>
> A number of remote branches connect to the same MPLS cloud and back to
> the central site.
>
> At the central site routes to these remote locations are learned via
> eBGP with a metric of 20. However, routes to 3-4 branches are learned
> in EIGRP by the Primary via the Secondary (AD 170). If I bounce the
> Gig link between them everything is OK for a while, then a few days
> later, the EIGRP route pops up again.
>
> There is no inbound route filtering on the 3560's as we wanted to see
> all routes.
>
> The routes concerned do show in the BGP table with the next hop as the
> eBGP peer. For some reason this route is ignored and the EIGRP path is
> followed.
>
> Any ideas ?
>
> Regards
>
> Darren
>

Setup IBGP to eliminate redistribution in EIGRP; use loopbacks if
there is multiple paths between the two 3560's.

When you redistirbute you lose the the details carried with the BGP
route which can be important for multipath BGP bestpatch route
slection and for other reasons.

Default can atrtact traffic to central MPLS-connected routers so
should not have to redistribute BGP into EIGRP

If redistribution is left in place, lower the IBGP admin distance so
that it is under external EIGRP - ie set to 150

On Nov 10, 3:48 am, Merv <merv.hr...@rogers.com> wrote:
> Setup IBGP to eliminate redistribution in EIGRP; use loopbacks if
> there is multiple paths between the two 3560's.
>
> When you redistirbute you lose the the details carried with the BGP
> route which can be important for multipath BGP bestpatch route
> slection and for other reasons.
>
> Default can atrtact traffic to central MPLS-connected routers so
> should not have to redistribute BGP into EIGRP
>
> If redistribution is left in place, lower the IBGP admin distance so
> that it is under external EIGRP - ie set to 150

I'm not sure why this is a problem. So core 1 routes to core 2 for
some of the branches, which to me is completely healthy unless you are
talking about having backup ISDN links terminating on Core 2 and
therefore want to avoid it. Else you are distributing the bandwidth
and utilization across the cores, which actually makes sense. And if
one fails, the other should pickup the heat. The issue I'm having, is
that if it is true e-bgp peering on both cores to all branches, then
how is eigrp being selected when e-bgp's admin distance is 20.
Something is not quite right.

This may be an IOS bug.

If OP posts his configs then reponders could assess whether there are
any config-related issues.

Personally, I would ditch the redistribution and implement IBGP

On Nov 11, 8:39 am, Merv <merv.hr...@rogers.com> wrote:
> This may be an IOS bug.
>
> If OP posts his configs then reponders could assess whether there are
> any config-related issues.
>
> Personally, I would ditch the redistribution and implement IBGP

I agree, but that only solves this issue, and then you still most
likely have to redistribute bgp into eigrp elsewhere (perhaps at the
next layer of routers). And if he is having some kind of bug issue,
I'm also not sure that would solve it. Regardless, I get the
impression he has to advertise these subnetworks back into his core.
I would consider turning up eigrp all the way through if you can get
away with it, but given that it is mpls, probably not an option.

On Nov 11, 9:34 am, Trendkill <jpma...@gmail.com> wrote:
> On Nov 11, 8:39 am, Merv <merv.hr...@rogers.com> wrote:
>
> > This may be an IOS bug.
>
> > If OP posts his configs then reponders could assess whether there are
> > any config-related issues.
>
> > Personally, I would ditch the redistribution and implement IBGP
>
> I agree, but that only solves this issue, and then you still most
> likely have to redistribute bgp into eigrp elsewhere (perhaps at the
> next layer of routers). And if he is having some kind of bug issue,
> I'm also not sure that would solve it. Regardless, I get the
> impression he has to advertise these subnetworks back into his core.
> I would consider turning up eigrp all the way through if you can get
> away with it, but given that it is mpls, probably not an option.


Assuming that the two routers running EBGP are the only exit points,
then I would think that advertising default via EIGRP would suffice.

On Nov 11, 10:04 am, Merv <merv.hr...@rogers.com> wrote:
> On Nov 11, 9:34 am, Trendkill <jpma...@gmail.com> wrote:
>
>
>
> > On Nov 11, 8:39 am, Merv <merv.hr...@rogers.com> wrote:
>
> > > This may be an IOS bug.
>
> > > If OP posts his configs then reponders could assess whether there are
> > > any config-related issues.
>
> > > Personally, I would ditch the redistribution and implement IBGP
>
> > I agree, but that only solves this issue, and then you still most
> > likely have to redistribute bgp into eigrp elsewhere (perhaps at the
> > next layer of routers). And if he is having some kind of bug issue,
> > I'm also not sure that would solve it. Regardless, I get the
> > impression he has to advertise these subnetworks back into his core.
> > I would consider turning up eigrp all the way through if you can get
> > away with it, but given that it is mpls, probably not an option.
>
> Assuming that the two routers running EBGP are the only exit points,
> then I would think that advertising default via EIGRP would suffice.

Its not exit points, its to branches. If we were talking internet,
this would be much easier. I think this is a retail network of some
kind, and therefore it can get difficult. Although, you may be onto
something. You could use ip summary statements on your routing vlans
to advertise the branch/store networks presuming they are subnetted
nicely and can be summarized. This would allow you to advertise the
bgp networks into eigrp without redistributing, and all you would need
to ensure is that the routers have at least one interface in eigrp in
the summarized range. This could work nicely.

Exit points meaning to the MPLS PE routers.

The OP clearly stated that this issue was occuring on the two central
site routers.

All the other sites have to be reached via those two rCE routers so
any traffic behind i.e. LABNS at the central site. etc) can be drawn
to these routers with default.

On Nov 11, 1:16 pm, Merv <merv.hr...@rogers.com> wrote:
> Exit points meaning to the MPLS PE routers.
>
> The OP clearly stated that this issue was occuring on the two central
> site routers.
>
> All the other sites have to be reached via those two rCE routers so
> any traffic behind i.e. LABNS at the central site. etc) can be drawn
> to these routers with default.

Gotta be careful here, what about the internet? We can assume these
cores are the default route for anything downstream, but the OP did
not specifically say this, and who knows how they are routing for DMZs
or out to the internet. It probably is a safe bet that the cores know
about the default through the proper way, but once you turn that up,
just need to be aware of what else is where. I worked for a very
large retail organization, and we had separate retail routers (for
stores) than for our WAN, and from our core. Additionally, we had
multiple internet connections in various datacenters, and turning up a
summary for 0.0.0.0 if it is not already there may cause issues if the
local internet pipe drops. Default should be redistributed from the
proper protocol, so perhaps he can redistribute that from bgp
(presuming it is there) and nothing else.