BGP & EIGRP Routing Issue

Discussion in 'Cisco' started by Darren Green, Nov 9, 2007.

  1. Darren Green

    Darren Green Guest

    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 Green, Nov 9, 2007
    #1
    1. Advertising

  2. 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:...
    > 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
    >
     
    headsetadapter.com, Nov 9, 2007
    #2
    1. Advertising

  3. Darren Green

    Merv Guest

    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
     
    Merv, Nov 10, 2007
    #3
  4. Darren Green

    Trendkill Guest

    On Nov 10, 3:48 am, Merv <> 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.
     
    Trendkill, Nov 11, 2007
    #4
  5. Darren Green

    Merv Guest

    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
     
    Merv, Nov 11, 2007
    #5
  6. Darren Green

    Trendkill Guest

    On Nov 11, 8:39 am, Merv <> 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.
     
    Trendkill, Nov 11, 2007
    #6
  7. Darren Green

    Merv Guest

    On Nov 11, 9:34 am, Trendkill <> wrote:
    > On Nov 11, 8:39 am, Merv <> 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.
     
    Merv, Nov 11, 2007
    #7
  8. Darren Green

    Trendkill Guest

    On Nov 11, 10:04 am, Merv <> wrote:
    > On Nov 11, 9:34 am, Trendkill <> wrote:
    >
    >
    >
    > > On Nov 11, 8:39 am, Merv <> 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.
     
    Trendkill, Nov 11, 2007
    #8
  9. Darren Green

    Merv Guest

    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.
     
    Merv, Nov 11, 2007
    #9
  10. Darren Green

    Trendkill Guest

    On Nov 11, 1:16 pm, Merv <> 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.
     
    Trendkill, Nov 11, 2007
    #10
  11. Darren Green

    Merv Guest

    Clearly if there are other exit points then the more specific routes
    need to be propogated.


    BTW I did not say to point default at the MPLS PE routers but just
    advertise (i.e. originate) default (i.e. points it to null0 on teh BGP
    routers

    More specific routes are held by CE routers that are running BGP. So
    once traffic arrive at these routers it will be handled as it is
    today.
     
    Merv, Nov 11, 2007
    #11
  12. Darren Green

    Trendkill Guest

    On Nov 11, 1:47 pm, Merv <> wrote:
    > Clearly if there are other exit points then the more specific routes
    > need to be propogated.
    >
    > BTW I did not say to point default at the MPLS PE routers but just
    > advertise (i.e. originate) default (i.e. points it to null0 on teh BGP
    > routers
    >
    > More specific routes are held by CE routers that are running BGP. So
    > once traffic arrive at these routers it will be handled as it is
    > today.


    Yes, I agree. Just didn't want to assume too much without the data.
    Never can gauge the knowledge of everyone on here, some take
    everything verbatim. Either way, appreciate the help, and congrats on
    your #2 post status now :).
     
    Trendkill, Nov 11, 2007
    #12
  13. Darren Green

    Darren Green Guest

    On 11 Nov, 13:39, Merv <> 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


    Hi Merv,

    Thanks to you & Trendkill for the follow up posts.

    I see the value in iBGP, however, I inherited the network from another
    engineer who is no longer with my company. The roll out is approx 90%
    complete and downtime is a real issue.

    The BGP routes are redistributed into EIGRP by our L3 switches and
    then handed off on the internal side to some customer 6509's that run
    EIGRP (the customers original routing protocol of choice). When I do
    the re-distribution I add prefix lists to ensure the client doesn't
    accidentally advertise these routes back to me.

    For the 3-4 x routes I learn in EIGRP from the backup 3560 I still
    have a valid next hop when I do a show ip bgp XXXXX for the same
    network. The route is in the BGP table but not in the routing table.
    Bounce the interface between the 3560's (Gig 0/3) and the routes come
    back in BGP.

    I followed a Cisco BGP troubleshooting guide and it's suggestion is
    that I raise a TAC case which I aim to do tomorrow.

    The reason this is an issue is that the customer sees the traffic on
    the link coming into the Secondary 3560. From here it's re-distributed
    and pushed to the primary 3560 in EIGRP. Whilst this is OK this link
    is supposed to be a failover link.

    Remote Site
    |
    cloud
    | |
    primary---secondary
    | |
    Transit Lan
    |
    Customer Lan

    Regards

    Darren
     
    Darren Green, Nov 11, 2007
    #13
  14. Darren Green

    Trendkill Guest

    On Nov 11, 4:43 pm, Darren Green <> wrote:
    > On 11 Nov, 13:39, Merv <> 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

    >
    > Hi Merv,
    >
    > Thanks to you & Trendkill for the follow up posts.
    >
    > I see the value in iBGP, however, I inherited the network from another
    > engineer who is no longer with my company. The roll out is approx 90%
    > complete and downtime is a real issue.
    >
    > The BGP routes are redistributed into EIGRP by our L3 switches and
    > then handed off on the internal side to some customer 6509's that run
    > EIGRP (the customers original routing protocol of choice). When I do
    > the re-distribution I add prefix lists to ensure the client doesn't
    > accidentally advertise these routes back to me.
    >
    > For the 3-4 x routes I learn in EIGRP from the backup 3560 I still
    > have a valid next hop when I do a show ip bgp XXXXX for the same
    > network. The route is in the BGP table but not in the routing table.
    > Bounce the interface between the 3560's (Gig 0/3) and the routes come
    > back in BGP.
    >
    > I followed a Cisco BGP troubleshooting guide and it's suggestion is
    > that I raise a TAC case which I aim to do tomorrow.
    >
    > The reason this is an issue is that the customer sees the traffic on
    > the link coming into the Secondary 3560. From here it's re-distributed
    > and pushed to the primary 3560 in EIGRP. Whilst this is OK this link
    > is supposed to be a failover link.
    >
    > Remote Site
    > |
    > cloud
    > | |
    > primary---secondary
    > | |
    > Transit Lan
    > |
    > Customer Lan
    >
    > Regards
    >
    > Darren


    Same mask on both routes (the one from eigrp, and the one in bgp after
    you bounce the backbone)? Can you not redistro into eigrp but filter
    it back to just 0.0.0.0, or do you have other ingress/egress on other
    routers further back? You don't want to put in a filter list in eigrp
    (between the two cores) to avoid problems if one of the wan links
    really does go down, but you may have other options to keep eigrp
    clean. Both 3560s are the same AS I would presume? What code are you
    running? I'm also assuming you do not have any peering in between the
    two 3560s per Merv's questions, which means that core1 must either
    have a better match (via mask) to router 2 via eigrp, or something is
    up with code if I am understanding the architecture right. Also, is
    the peer/next hop address the same for both 3560s in bgp?

    If you open a case, let us know what you find.
     
    Trendkill, Nov 11, 2007
    #14
  15. Darren Green

    Darren Green Guest

    On 11 Nov, 18:30, Trendkill <> wrote:
    > On Nov 11, 1:16 pm, Merv <> 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.


    The actual Internet breakout isn't in yet but will be shortly.

    The plan is to deliver a resillient Internet connection split across 2
    x Co-Lo cation facilities from the MPLS cloud.

    The issue here is with a seperate Data Centre where the BGP is re-
    distributed into EIGRP for the client core. This data centre connects
    back to the client HQ via a couple of Ethernet circuits. The client
    wants to be able to see all the routes in EIGRP so they know what's
    up /down.

    Remote Site
    |
    MPLS cloud--------------internet
    | |
    primary---secondary
    | |
    Data Centre LAN
    | |
    customer LAN

    I believe this is an IOS bug and aim to open a TAC case with Cisco
    tomorrow.

    Regards

    Darren
     
    Darren Green, Nov 11, 2007
    #15
  16. Darren Green

    Darren Green Guest

    On 11 Nov, 21:54, Trendkill <> wrote:
    > On Nov 11, 4:43 pm, Darren Green <> wrote:
    >
    >
    >
    >
    >
    > > On 11 Nov, 13:39, Merv <> 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

    >
    > > Hi Merv,

    >
    > > Thanks to you & Trendkill for the follow up posts.

    >
    > > I see the value in iBGP, however, I inherited the network from another
    > > engineer who is no longer with my company. The roll out is approx 90%
    > > complete and downtime is a real issue.

    >
    > > The BGP routes are redistributed into EIGRP by our L3 switches and
    > > then handed off on the internal side to some customer 6509's that run
    > > EIGRP (the customers original routing protocol of choice). When I do
    > > the re-distribution I add prefix lists to ensure the client doesn't
    > > accidentally advertise these routes back to me.

    >
    > > For the 3-4 x routes I learn in EIGRP from the backup 3560 I still
    > > have a valid next hop when I do a show ip bgp XXXXX for the same
    > > network. The route is in the BGP table but not in the routing table.
    > > Bounce the interface between the 3560's (Gig 0/3) and the routes come
    > > back in BGP.

    >
    > > I followed a Cisco BGP troubleshooting guide and it's suggestion is
    > > that I raise a TAC case which I aim to do tomorrow.

    >
    > > The reason this is an issue is that the customer sees the traffic on
    > > the link coming into the Secondary 3560. From here it's re-distributed
    > > and pushed to the primary 3560 in EIGRP. Whilst this is OK this link
    > > is supposed to be a failover link.

    >
    > > Remote Site
    > > |
    > > cloud
    > > | |
    > > primary---secondary
    > > | |
    > > Transit Lan
    > > |
    > > Customer Lan

    >
    > > Regards

    >
    > > Darren

    >
    > Same mask on both routes (the one from eigrp, and the one in bgp after
    > you bounce the backbone)? Can you not redistro into eigrp but filter
    > it back to just 0.0.0.0, or do you have other ingress/egress on other
    > routers further back? You don't want to put in a filter list in eigrp
    > (between the two cores) to avoid problems if one of the wan links
    > really does go down, but you may have other options to keep eigrp
    > clean. Both 3560s are the same AS I would presume? What code are you
    > running? I'm also assuming you do not have any peering in between the
    > two 3560s per Merv's questions, which means that core1 must either
    > have a better match (via mask) to router 2 via eigrp, or something is
    > up with code if I am understanding the architecture right. Also, is
    > the peer/next hop address the same for both 3560s in bgp?
    >
    > If you open a case, let us know what you find.- Hide quoted text -
    >
    > - Show quoted text -


    Same mask for both EIGRP and BGP. Originally I thought that this could
    have been the problem but no so.

    Unfortunately I can't filter EIGRP down to 0.0.0.0 at the back end as
    the customer wants to see the routes being handed over to them.

    Originally, the customer's network consisted of leased lines running
    EIGRP from their HQ to all their sites. We came along and moved the
    sites to MPLS, when doing this we applied router filtering to make
    sure that the customer did not advertise the LAN's on the MPLS back to
    us on the transit network.

    In BGP we don't filter the inbound BGP in the datacenter but we do
    filter the re-distributed routes into EIGRP.

    As an example, an old site on Leased Line say 192.168.1.1 /24 moves to
    MPLS. When this advertisement come in via the 3560's in BGP, we ensure
    via a route-map that this LAN is allowed to be re-distributed into
    EIGRP. Then on the transit side of the 3560'we ensue that it is not re-
    advertised back to us by the client in their EIGRP process.

    Both 3560's are in the same AS but I would need to check the IOS
    versions. There is no iBGP between the 3560's only EIGRP.

    Each 3560 talks to a different Telco eBGP peer in the MPLS cloud. The
    Telco eBGP peers for both routers are in the same AS (just separate
    datacenters for resiliency)

    When I find out what the problem was, I will e-mail an update.

    Thanks for the help, really appreciated.

    Regadrs

    Darren
     
    Darren Green, Nov 11, 2007
    #16
  17. Darren Green

    Al Guest

    On Nov 11, 10:24 pm, Darren Green <> wrote:
    > On 11 Nov, 21:54, Trendkill <> wrote:
    >
    >
    >
    > > On Nov 11, 4:43 pm, Darren Green <> wrote:

    >
    > > > On 11 Nov, 13:39, Merv <> 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

    >
    > > > Hi Merv,

    >
    > > > Thanks to you & Trendkill for the follow up posts.

    >
    > > > I see the value in iBGP, however, I inherited the network from another
    > > > engineer who is no longer with my company. The roll out is approx 90%
    > > > complete and downtime is a real issue.

    >
    > > > The BGP routes are redistributed into EIGRP by our L3 switches and
    > > > then handed off on the internal side to some customer 6509's that run
    > > > EIGRP (the customers original routing protocol of choice). When I do
    > > > the re-distribution I add prefix lists to ensure the client doesn't
    > > > accidentally advertise these routes back to me.

    >
    > > > For the 3-4 x routes I learn in EIGRP from the backup 3560 I still
    > > > have a valid next hop when I do a show ip bgp XXXXX for the same
    > > > network. The route is in the BGP table but not in the routing table.
    > > > Bounce the interface between the 3560's (Gig 0/3) and the routes come
    > > > back in BGP.

    >
    > > > I followed a Cisco BGP troubleshooting guide and it's suggestion is
    > > > that I raise a TAC case which I aim to do tomorrow.

    >
    > > > The reason this is an issue is that the customer sees the traffic on
    > > > the link coming into the Secondary 3560. From here it's re-distributed
    > > > and pushed to the primary 3560 in EIGRP. Whilst this is OK this link
    > > > is supposed to be a failover link.

    >
    > > > Remote Site
    > > > |
    > > > cloud
    > > > | |
    > > > primary---secondary
    > > > | |
    > > > Transit Lan
    > > > |
    > > > Customer Lan

    >
    > > > Regards

    >
    > > > Darren

    >
    > > Same mask on both routes (the one from eigrp, and the one in bgp after
    > > you bounce the backbone)? Can you not redistro into eigrp but filter
    > > it back to just 0.0.0.0, or do you have other ingress/egress on other
    > > routers further back? You don't want to put in a filter list in eigrp
    > > (between the two cores) to avoid problems if one of the wan links
    > > really does go down, but you may have other options to keep eigrp
    > > clean. Both 3560s are the same AS I would presume? What code are you
    > > running? I'm also assuming you do not have any peering in between the
    > > two 3560s per Merv's questions, which means that core1 must either
    > > have a better match (via mask) to router 2 via eigrp, or something is
    > > up with code if I am understanding the architecture right. Also, is
    > > the peer/next hop address the same for both 3560s in bgp?

    >
    > > If you open a case, let us know what you find.- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Same mask for both EIGRP and BGP. Originally I thought that this could
    > have been the problem but no so.
    >
    > Unfortunately I can't filter EIGRP down to 0.0.0.0 at the back end as
    > the customer wants to see the routes being handed over to them.
    >
    > Originally, the customer's network consisted of leased lines running
    > EIGRP from their HQ to all their sites. We came along and moved the
    > sites to MPLS, when doing this we applied router filtering to make
    > sure that the customer did not advertise the LAN's on the MPLS back to
    > us on the transit network.
    >
    > In BGP we don't filter the inbound BGP in the datacenter but we do
    > filter the re-distributed routes into EIGRP.
    >
    > As an example, an old site on Leased Line say 192.168.1.1 /24 moves to
    > MPLS. When this advertisement come in via the 3560's in BGP, we ensure
    > via a route-map that this LAN is allowed to be re-distributed into
    > EIGRP. Then on the transit side of the 3560'we ensue that it is not re-
    > advertised back to us by the client in their EIGRP process.
    >
    > Both 3560's are in the same AS but I would need to check the IOS
    > versions. There is no iBGP between the 3560's only EIGRP.
    >
    > Each 3560 talks to a different Telco eBGP peer in the MPLS cloud. The
    > Telco eBGP peers for both routers are in the same AS (just separate
    > datacenters for resiliency)
    >
    > When I find out what the problem was, I will e-mail an update.
    >
    > Thanks for the help, really appreciated.
    >
    > Regadrs
    >
    > Darren


    I'm no expert in this area (by any means) but when I was reading
    around the subject (for another issue by the way), I came across:

    http://www.cisco.com/en/US/products..._feature_guide09186a008053b5b6.html#wp1067175

    which seems to indicate in some circumstances that routes learned via
    EIGRP are automatically preferred to those learned through BGP. Now I
    have no idea if this applies in this situation, and I have probably
    missed something critical, but thought it worth tossing out there for
    someone to shoot down...?! Would be interested to hear what anyone has
    to say on this.

    Cheers,

    Al
     
    Al, Nov 13, 2007
    #17
  18. Darren Green

    Guest

    On 13 nov, 17:12, Al <> wrote:
    > On Nov 11, 10:24 pm, Darren Green <> wrote:
    >
    >
    >
    >
    >
    > > On 11 Nov, 21:54, Trendkill <> wrote:

    >
    > > > On Nov 11, 4:43 pm, Darren Green <> wrote:

    >
    > > > > On 11 Nov, 13:39, Merv <> 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

    >
    > > > > Hi Merv,

    >
    > > > > Thanks to you & Trendkill for the follow up posts.

    >
    > > > > I see the value in iBGP, however, I inherited the network from another
    > > > > engineer who is no longer with my company. The roll out is approx 90%
    > > > > complete and downtime is a real issue.

    >
    > > > > The BGP routes are redistributed into EIGRP by our L3 switches and
    > > > > then handed off on the internal side to some customer 6509's that run
    > > > > EIGRP (the customers original routing protocol of choice). When I do
    > > > > the re-distribution I add prefix lists to ensure the client doesn't
    > > > > accidentally advertise these routes back to me.

    >
    > > > > For the 3-4 x routes I learn in EIGRP from the backup 3560 I still
    > > > > have a valid next hop when I do a show ip bgp XXXXX for the same
    > > > > network. The route is in the BGP table but not in the routing table.
    > > > > Bounce the interface between the 3560's (Gig 0/3) and the routes come
    > > > > back in BGP.

    >
    > > > > I followed a Cisco BGP troubleshooting guide and it's suggestion is
    > > > > that I raise a TAC case which I aim to do tomorrow.

    >
    > > > > The reason this is an issue is that the customer sees the traffic on
    > > > > the link coming into the Secondary 3560. From here it's re-distributed
    > > > > and pushed to the primary 3560 in EIGRP. Whilst this is OK this link
    > > > > is supposed to be a failover link.

    >
    > > > > Remote Site
    > > > > |
    > > > > cloud
    > > > > | |
    > > > > primary---secondary
    > > > > | |
    > > > > Transit Lan
    > > > > |
    > > > > Customer Lan

    >
    > > > > Regards

    >
    > > > > Darren

    >
    > > > Same mask on both routes (the one from eigrp, and the one in bgp after
    > > > you bounce the backbone)? Can you not redistro into eigrp but filter
    > > > it back to just 0.0.0.0, or do you have other ingress/egress on other
    > > > routers further back? You don't want to put in a filter list in eigrp
    > > > (between the two cores) to avoid problems if one of the wan links
    > > > really does go down, but you may have other options to keep eigrp
    > > > clean. Both 3560s are the same AS I would presume? What code are you
    > > > running? I'm also assuming you do not have any peering in between the
    > > > two 3560s per Merv's questions, which means that core1 must either
    > > > have a better match (via mask) to router 2 via eigrp, or something is
    > > > up with code if I am understanding the architecture right. Also, is
    > > > the peer/next hop address the same for both 3560s in bgp?

    >
    > > > If you open a case, let us know what you find.- Hide quoted text -

    >
    > > > - Show quoted text -

    >
    > > Same mask for both EIGRP and BGP. Originally I thought that this could
    > > have been the problem but no so.

    >
    > > Unfortunately I can't filter EIGRP down to 0.0.0.0 at the back end as
    > > the customer wants to see the routes being handed over to them.

    >
    > > Originally, the customer's network consisted of leased lines running
    > > EIGRP from their HQ to all their sites. We came along and moved the
    > > sites to MPLS, when doing this we applied router filtering to make
    > > sure that the customer did not advertise the LAN's on the MPLS back to
    > > us on the transit network.

    >
    > > In BGP we don't filter the inbound BGP in the datacenter but we do
    > > filter the re-distributed routes into EIGRP.

    >
    > > As an example, an old site on Leased Line say 192.168.1.1 /24 moves to
    > > MPLS. When this advertisement come in via the 3560's in BGP, we ensure
    > > via a route-map that this LAN is allowed to be re-distributed into
    > > EIGRP. Then on the transit side of the 3560'we ensue that it is not re-
    > > advertised back to us by the client in their EIGRP process.

    >
    > > Both 3560's are in the same AS but I would need to check the IOS
    > > versions. There is no iBGP between the 3560's only EIGRP.

    >
    > > Each 3560 talks to a different Telco eBGP peer in the MPLS cloud. The
    > > Telco eBGP peers for both routers are in the same AS (just separate
    > > datacenters for resiliency)

    >
    > > When I find out what the problem was, I will e-mail an update.

    >
    > > Thanks for the help, really appreciated.

    >
    > > Regadrs

    >
    > > Darren

    >
    > I'm no expert in this area (by any means) but when I was reading
    > around the subject (for another issue by the way), I came across:
    >
    > http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_featu...
    >
    > which seems to indicate in some circumstances that routes learned via
    > EIGRP are automatically preferred to those learned through BGP. Now I
    > have no idea if this applies in this situation, and I have probably
    > missed something critical, but thought it worth tossing out there for
    > someone to shoot down...?! Would be interested to hear what anyone has
    > to say on this.
    >
    > Cheers,
    >
    > Al- Ocultar texto entre aspas -
    >
    > - Mostrar texto entre aspas -


    Guys,

    I have the same problem related by Darren. Look the show ip bgp and
    show ip route.

    SPOPA302#sh ip bgp vpnv4 vrf bfe 10.171.28.0
    BGP routing table entry for 8167:10401:10.171.28.0/24, version 6254804
    Paths: (2 available, best #1, table bfe)
    Not advertised to any peer
    7738 65001, imported path from 8167:10398:10.171.28.0/24
    201.10.208.209 (metric 32) from 201.10.208.8 (201.10.208.8)
    Origin incomplete, metric 310, localpref 100, valid, internal,
    best
    Extended Community: RT:8167:10398
    Originator: 201.41.107.252, Cluster list: 0.0.0.14
    Local
    10.249.2.26 from 0.0.0.0 (201.10.240.4)
    Origin incomplete, metric 249344, localpref 95, valid, sourced
    Extended Community: RT:8167:10401 Cost:pre-bestpath:129:249344
    0x8800:0:7738 0x8801:10:36096 0x8802:65285:213248
    0x8803:65285:1500
    0x8804:8167:184091589 0x8805:9:310

    The first route learned from MP-BGP(MPLS) and it is the best, but, the
    other route from EIGRP is installed on routing table:

    SPOPA302#sh ip route vrf bfe 10.171.28.0
    Routing entry for 10.171.28.0/24
    Known via "eigrp 10401", distance 170, metric 249344
    Tag 7738, type external
    Redistributing via eigrp 10401, bgp 8167
    Advertised by bgp 8167 route-map WEIGHT_0
    Last update from 10.249.2.26 on FastEthernet11/37, 03:42:12 ago
    Routing Descriptor Blocks:
    * 10.249.2.26, from 10.249.2.26, 03:42:12 ago, via FastEthernet11/37
    Route metric is 249344, traffic share count is 1
    Total delay is 1410 microseconds, minimum bandwidth is 12004
    Kbit
    Reliability 255/255, minimum MTU 1500 bytes
    Loading 5/255, Hops 5
    Route tag 7738

    I tried to influence de pre-bestpath on the first route, but it did
    not resolve.

    Anyone knows how to solve this.

    Regards,

    Christianno
     
    , Nov 20, 2007
    #18
  19. Darren Green

    Merv Guest

    On Nov 20, 10:50 am, ""
    <> wrote:
    > On 13 nov, 17:12, Al <> wrote:
    >
    >
    >
    > > On Nov 11, 10:24 pm, Darren Green <> wrote:

    >
    > > > On 11 Nov, 21:54, Trendkill <> wrote:

    >
    > > > > On Nov 11, 4:43 pm, Darren Green <> wrote:

    >
    > > > > > On 11 Nov, 13:39, Merv <> 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

    >
    > > > > > Hi Merv,

    >
    > > > > > Thanks to you & Trendkill for the follow up posts.

    >
    > > > > > I see the value in iBGP, however, I inherited the network from another
    > > > > > engineer who is no longer with my company. The roll out is approx 90%
    > > > > > complete and downtime is a real issue.

    >
    > > > > > The BGP routes are redistributed into EIGRP by our L3 switches and
    > > > > > then handed off on the internal side to some customer 6509's that run
    > > > > > EIGRP (the customers original routing protocol of choice). When I do
    > > > > > the re-distribution I add prefix lists to ensure the client doesn't
    > > > > > accidentally advertise these routes back to me.

    >
    > > > > > For the 3-4 x routes I learn in EIGRP from the backup 3560 I still
    > > > > > have a valid next hop when I do a show ip bgp XXXXX for the same
    > > > > > network. The route is in the BGP table but not in the routing table.
    > > > > > Bounce the interface between the 3560's (Gig 0/3) and the routes come
    > > > > > back in BGP.

    >
    > > > > > I followed a Cisco BGP troubleshooting guide and it's suggestion is
    > > > > > that I raise a TAC case which I aim to do tomorrow.

    >
    > > > > > The reason this is an issue is that the customer sees the traffic on
    > > > > > the link coming into the Secondary 3560. From here it's re-distributed
    > > > > > and pushed to the primary 3560 in EIGRP. Whilst this is OK this link
    > > > > > is supposed to be a failover link.

    >
    > > > > > Remote Site
    > > > > > |
    > > > > > cloud
    > > > > > | |
    > > > > > primary---secondary
    > > > > > | |
    > > > > > Transit Lan
    > > > > > |
    > > > > > Customer Lan

    >
    > > > > > Regards

    >
    > > > > > Darren

    >
    > > > > Same mask on both routes (the one from eigrp, and the one in bgp after
    > > > > you bounce the backbone)? Can you not redistro into eigrp but filter
    > > > > it back to just 0.0.0.0, or do you have other ingress/egress on other
    > > > > routers further back? You don't want to put in a filter list in eigrp
    > > > > (between the two cores) to avoid problems if one of the wan links
    > > > > really does go down, but you may have other options to keep eigrp
    > > > > clean. Both 3560s are the same AS I would presume? What code are you
    > > > > running? I'm also assuming you do not have any peering in between the
    > > > > two 3560s per Merv's questions, which means that core1 must either
    > > > > have a better match (via mask) to router 2 via eigrp, or something is
    > > > > up with code if I am understanding the architecture right. Also, is
    > > > > the peer/next hop address the same for both 3560s in bgp?

    >
    > > > > If you open a case, let us know what you find.- Hide quoted text -

    >
    > > > > - Show quoted text -

    >
    > > > Same mask for both EIGRP and BGP. Originally I thought that this could
    > > > have been the problem but no so.

    >
    > > > Unfortunately I can't filter EIGRP down to 0.0.0.0 at the back end as
    > > > the customer wants to see the routes being handed over to them.

    >
    > > > Originally, the customer's network consisted of leased lines running
    > > > EIGRP from their HQ to all their sites. We came along and moved the
    > > > sites to MPLS, when doing this we applied router filtering to make
    > > > sure that the customer did not advertise the LAN's on the MPLS back to
    > > > us on the transit network.

    >
    > > > In BGP we don't filter the inbound BGP in the datacenter but we do
    > > > filter the re-distributed routes into EIGRP.

    >
    > > > As an example, an old site on Leased Line say 192.168.1.1 /24 moves to
    > > > MPLS. When this advertisement come in via the 3560's in BGP, we ensure
    > > > via a route-map that this LAN is allowed to be re-distributed into
    > > > EIGRP. Then on the transit side of the 3560'we ensue that it is not re-
    > > > advertised back to us by the client in their EIGRP process.

    >
    > > > Both 3560's are in the same AS but I would need to check the IOS
    > > > versions. There is no iBGP between the 3560's only EIGRP.

    >
    > > > Each 3560 talks to a different Telco eBGP peer in the MPLS cloud. The
    > > > Telco eBGP peers for both routers are in the same AS (just separate
    > > > datacenters for resiliency)

    >
    > > > When I find out what the problem was, I will e-mail an update.

    >
    > > > Thanks for the help, really appreciated.

    >
    > > > Regadrs

    >
    > > > Darren

    >
    > > I'm no expert in this area (by any means) but when I was reading
    > > around the subject (for another issue by the way), I came across:

    >
    > >http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_featu...

    >
    > > which seems to indicate in some circumstances that routes learned via
    > > EIGRP are automatically preferred to those learned through BGP. Now I
    > > have no idea if this applies in this situation, and I have probably
    > > missed something critical, but thought it worth tossing out there for
    > > someone to shoot down...?! Would be interested to hear what anyone has
    > > to say on this.

    >
    > > Cheers,

    >
    > > Al- Ocultar texto entre aspas -

    >
    > > - Mostrar texto entre aspas -

    >
    > Guys,
    >
    > I have the same problem related by Darren. Look the show ip bgp and
    > show ip route.
    >
    > SPOPA302#sh ip bgp vpnv4 vrf bfe 10.171.28.0
    > BGP routing table entry for 8167:10401:10.171.28.0/24, version 6254804
    > Paths: (2 available, best #1, table bfe)
    > Not advertised to any peer
    > 7738 65001, imported path from 8167:10398:10.171.28.0/24
    > 201.10.208.209 (metric 32) from 201.10.208.8 (201.10.208.8)
    > Origin incomplete, metric 310, localpref 100, valid, internal,
    > best
    > Extended Community: RT:8167:10398
    > Originator: 201.41.107.252, Cluster list: 0.0.0.14
    > Local
    > 10.249.2.26 from 0.0.0.0 (201.10.240.4)
    > Origin incomplete, metric 249344, localpref 95, valid, sourced
    > Extended Community: RT:8167:10401 Cost:pre-bestpath:129:249344
    > 0x8800:0:7738 0x8801:10:36096 0x8802:65285:213248
    > 0x8803:65285:1500
    > 0x8804:8167:184091589 0x8805:9:310
    >
    > The first route learned from MP-BGP(MPLS) and it is the best, but, the
    > other route from EIGRP is installed on routing table:
    >
    > SPOPA302#sh ip route vrf bfe 10.171.28.0
    > Routing entry for 10.171.28.0/24
    > Known via "eigrp 10401", distance 170, metric 249344
    > Tag 7738, type external
    > Redistributing via eigrp 10401, bgp 8167
    > Advertised by bgp 8167 route-map WEIGHT_0
    > Last update from 10.249.2.26 on FastEthernet11/37, 03:42:12 ago
    > Routing Descriptor Blocks:
    > * 10.249.2.26, from 10.249.2.26, 03:42:12 ago, via FastEthernet11/37
    > Route metric is 249344, traffic share count is 1
    > Total delay is 1410 microseconds, minimum bandwidth is 12004
    > Kbit
    > Reliability 255/255, minimum MTU 1500 bytes
    > Loading 5/255, Hops 5
    > Route tag 7738
    >
    > I tried to influence de pre-bestpath on the first route, but it did
    > not resolve.
    >
    > Anyone knows how to solve this.
    >
    > Regards,
    >
    > Christianno
    >




    Best is learned via IBGP which has AD=200

    EIGRP external has AD=170, thus EIGRP wins


    you could lower the Admin Distance of IBGP from 200 to 150

    make sure your are NOT doing mutual redistribution without proper
    route riltering useing route maps
     
    Merv, Nov 20, 2007
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ciscokid

    bgp redistribution into Eigrp

    ciscokid, Nov 22, 2004, in forum: Cisco
    Replies:
    2
    Views:
    25,742
    daricha74
    Jun 25, 2012
  2. Replies:
    3
    Views:
    4,532
  3. BG
    Replies:
    3
    Views:
    6,749
  4. MC

    BGP/EIGRP routing

    MC, Apr 17, 2007, in forum: Cisco
    Replies:
    5
    Views:
    2,889
    John Agosta
    Apr 18, 2007
  5. Poisoning72
    Replies:
    1
    Views:
    2,215
    wattsdr
    Oct 6, 2011
Loading...

Share This Page