Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > BGP & EIGRP Routing Issue

Reply
Thread Tools

BGP & EIGRP Routing Issue

 
 
Darren Green
Guest
Posts: n/a
 
      11-09-2007
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

 
Reply With Quote
 
 
 
 
headsetadapter.com
Guest
Posts: n/a
 
      11-09-2007
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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
>



 
Reply With Quote
 
 
 
 
Merv
Guest
Posts: n/a
 
      11-10-2007

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


 
Reply With Quote
 
Trendkill
Guest
Posts: n/a
 
      11-11-2007
On Nov 10, 3:48 am, Merv <(E-Mail Removed)> 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.

 
Reply With Quote
 
Merv
Guest
Posts: n/a
 
      11-11-2007

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


 
Reply With Quote
 
Trendkill
Guest
Posts: n/a
 
      11-11-2007
On Nov 11, 8:39 am, Merv <(E-Mail Removed)> 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.

 
Reply With Quote
 
Merv
Guest
Posts: n/a
 
      11-11-2007
On Nov 11, 9:34 am, Trendkill <(E-Mail Removed)> wrote:
> On Nov 11, 8:39 am, Merv <(E-Mail Removed)> 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.


 
Reply With Quote
 
Trendkill
Guest
Posts: n/a
 
      11-11-2007
On Nov 11, 10:04 am, Merv <(E-Mail Removed)> wrote:
> On Nov 11, 9:34 am, Trendkill <(E-Mail Removed)> wrote:
>
>
>
> > On Nov 11, 8:39 am, Merv <(E-Mail Removed)> 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.

 
Reply With Quote
 
Merv
Guest
Posts: n/a
 
      11-11-2007
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.

 
Reply With Quote
 
Trendkill
Guest
Posts: n/a
 
      11-11-2007
On Nov 11, 1:16 pm, Merv <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
bgp redistribution into Eigrp ciscokid Cisco 2 06-25-2012 10:41 AM
Routing Problems With Bgp And Eigrp Cisco 3825 Poisoning72 Cisco 1 10-06-2011 03:19 PM
Newbie route redistribution eigrp into bgp question Sean.Evershed@gmail.com Cisco 3 06-25-2009 10:18 AM
BGP/EIGRP routing MC Cisco 5 04-18-2007 08:53 PM
EIGRP, Want to prevent any EIGRP traffic to a interface BG Cisco 3 02-09-2006 08:05 PM



Advertisments