Mailing List Archive: Ideas on failure detection for a peering exchange shared between two routers.

Ideas on failure detection for a peering exchange shared between two routers.

Mar 2, 2021, 1:06 PM

Post #1 of 5 (900 views)

I've run into a corner case with a peering exchange that has me a little stumped for a solution that doesn't require redesigning the whole thing:

Two MX80 routers participate in the same peering exchange. (A Primary and Secondary) Each has an interface configured in the same IP network within that IX. During a random bad event (maintenance error or fiber failure within the IX) the primary router loses access to everything on the IX network but it's link stays up. The secondary router is not impacted by the event. When this happens BGP on the primary router detects the loss of connectivity to its peers and updates all of its routes based on the BGP table from the secondary router. But because the peering link on the primary router is still UP/UP, the forwarding table says the next-hop is available via the bad interface. Here is an example of a Google route being learned on the IX:

34.84.0.0/14 *[BGP/170] 1d 02:06:40, MED 0, localpref 220, from 172.xx.xx.49
AS path: 15169 I, validation-state: unverified
> to 19x.xx.x.113 via xe-0/0/2.0

Any way to work around this scenario?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Ideas on failure detection for a peering exchange shared between two routers. [ In reply to ]

me at geordish

Mar 2, 2021, 1:21 PM

Post #2 of 5 (900 views)

Permalink

Advertise the routes to the rest of your network using next hop self. This
way the next hop is the loopback address of your routers, rather than the
peering LAN itself.

Regards,
Dave

On Tue, 2 Mar 2021 at 21:08, Jonathan Call <lordsith49@hotmail.com> wrote:

> I've run into a corner case with a peering exchange that has me a little
> stumped for a solution that doesn't require redesigning the whole thing:
>
> Two MX80 routers participate in the same peering exchange. (A Primary and
> Secondary) Each has an interface configured in the same IP network within
> that IX. During a random bad event (maintenance error or fiber failure
> within the IX) the primary router loses access to everything on the IX
> network but it's link stays up. The secondary router is not impacted by the
> event. When this happens BGP on the primary router detects the loss of
> connectivity to its peers and updates all of its routes based on the BGP
> table from the secondary router. But because the peering link on the
> primary router is still UP/UP, the forwarding table says the next-hop is
> available via the bad interface. Here is an example of a Google route being
> learned on the IX:
>
> 34.84.0.0/14 *[BGP/170] 1d 02:06:40, MED 0, localpref 220, from
> 172.xx.xx.49
> AS path: 15169 I, validation-state: unverified
> > to 19x.xx.x.113 via xe-0/0/2.0
>
> Any way to work around this scenario?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Ideas on failure detection for a peering exchange shared between two routers. [ In reply to ]

gert at greenie

Mar 2, 2021, 1:29 PM

Post #3 of 5 (900 views)

Permalink

Hi,

On Tue, Mar 02, 2021 at 09:06:22PM +0000, Jonathan Call wrote:
> Two MX80 routers participate in the same peering exchange. (A
> Primary and Secondary) Each has an interface configured in the same
> IP network within that IX. During a random bad event (maintenance
> error or fiber failure within the IX) the primary router loses
> access to everything on the IX network but it's link stays up. The
> secondary router is not impacted by the event. When this happens
> BGP on the primary router detects the loss of connectivity to its
> peers and updates all of its routes based on the BGP table from the
> secondary router. But because the peering link on the primary router
> is still UP/UP, the forwarding table says the next-hop is available
> via the bad interface. Here is an example of a Google route being
> learned on the IX:

next-hop-self

(aka "have the other IXP router set its loopback IP as next-hop when
sending the prefix via iBGP")

Note: some people recommend always using next-hop-self, but there are
situations when you don't want it, and I do not want to start that particular
discussion now :-) - it improves *this* situation, and it also saves you
from having to carry the IXP LAN in your internal routing.

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Re: Ideas on failure detection for a peering exchange shared between two routers. [ In reply to ]

ch at ntrv

Mar 2, 2021, 1:31 PM

Post #4 of 5 (900 views)

Permalink

> Any way to work around this scenario?

Most IX's would have some sort of IP address available that can be
used as L3 target for tracking if $remote end (the ix lan) is
reachable.

Juniper RPM (Real-Time Performance Monitoring) seems to be the
equivalent of Cisco's IP SLA feature.

Worth looking into?

--
Chriztoffer

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Ideas on failure detection for a peering exchange shared between two routers. [ In reply to ]

ch at ntrv

Mar 2, 2021, 1:35 PM

Post #5 of 5 (900 views)

Permalink

> Advertise the routes to the rest of your network using next-hop-self. This
> way the next hop is the loopback address of your routers, rather than the
> peering LAN itself.

Indeed. With this approach, you would also be able to avoid having to
redistribute the IX LAN prefix into your internal network from your
border routers. :)

Avoiding redistribution of the IX Local Area Network prefix _into_
your network also lessens the chance of accidentally leaking the IX
LAN prefix into the DFZ with your Autonomous System Number as the
origin of a potentially invalid (IX LAN) prefix announcement.

--
Chriztoffer

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Mailing List Archive

Mailing List Archive

Attached Files: