Routing

Hi,

We currently had a great working setup with our MX routers each connected to their own ISP and providing an ECMP default path to our public facing devices. Here was the layout, l3 only:

   DEV1 (ASN21)            DEV2 (ASN22)
   3.3.3.11/26             3.3.3.12/26
        |                       |
        -------------------------
        |                       |
    3.3.3.1/26              3.3.3.2/26
   3.3.3.254/31------------3.3.3.255/31
    R1 (ASN11)              R2 (ASN11)
    1.1.1.2/31              2.2.2.2/31
        |                       |
    1.1.1.1/31             2.2.2.1/31
   ISP-A (ASN1)            ISP-B (ASN2)

And here was the export policy from the routers, from R1:

set logical-systems internet policy-options policy-statement export-public term default-ispa from protocol bgp
set logical-systems internet policy-options policy-statement export-public term default-ispa from as-path ispa
set logical-systems internet policy-options policy-statement export-public term default-ispa from route-filter 0.0.0.0/0 exact
set logical-systems internet policy-options policy-statement export-public term default-ispa then metric 10
set logical-systems internet policy-options policy-statement export-public term default-ispa then accept
set logical-systems internet policy-options policy-statement export-public term default-ispb from protocol bgp
set logical-systems internet policy-options policy-statement export-public term default-ispb from as-path ispb
set logical-systems internet policy-options policy-statement export-public term default-ispb from route-filter 0.0.0.0/0 exact
set logical-systems internet policy-options policy-statement export-public term default-ispb then metric 20
set logical-systems internet policy-options policy-statement export-public term default-ispb then accept
set logical-systems internet policy-options policy-statement export-public term else then reject

Both ISPs send us the full Internet table + the default route and R1 and R2 also exchange full Internet table + default route. This allows us to ensure that although the ISPs sent us a full Internet table we only redistribute the default route *if* it is receveid, which validates BGP peering, and also allows to prevent any traffic blackholing while the routing tables are being synchronized. It also allowed us to use uptimal route selection between each ISP from either router. Also, it allowed us to keep optimized redundancy as the MED would be equal if the route was coming from the directly connected ISP, but if that connection was lost, it would still be able to advertise a default route to the DEVs if it was being received from the other router, but with an increased MED.

Now for the new problem at hand... We have a new device in our public facing network that *cannot* accept ECMP with different AS-PATHs. Our current route advertisement, when both ISPs were available, was AS11, AS1 from R1 and AS11, AS2 from R2. Now we need to find a way to have an exact same AS-PATH to that new DEV, example DEV2 from the above layout and ideally while keeping the 

We tried to generate a default route based on the same redistribution priority and the route is properly generated, but it will never be redistributed as it's not active in the routing table, as per the example below:

R1# run show route 0.0.0.0 logical-system internet all

inet.0: 637819 destinations, 1130616 routes (637819 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[BGP/170] 1w2d 18:22:18, localpref 100
                      AS path: 11 I, validation-state: unverified
                    > to 1.1.1.1 via ge-0/1/0.0
                    [BGP/170] 1d 15:13:00, MED 100, localpref 100, from 3.3.3.255
                      AS path: 12 I, validation-state: unverified
                    > to 10.1.1.21 via ge-0/0/1.0
                      to 10.1.1.37 via ge-0/1/1.0
                    [Aggregate] 00:00:13
                      Reject

The only way we managed to redistribute the route with equal paths, was to redistribute a static route, but then the problem was that it would always have precedence over the BGP received routes, which means that if the BGP session to the ISP was to go down, but not the link, our routing would be screwed as we would still advertise the route to the DEV devices, but we would blackhole the traffic...

Is there any way that this could actually be achieved? I don't think we can actually manipulate the AS-PATH (which I know is not a good idea, but in this case would not be a big problem...) and as-override would skew outbound traffic, so I am out of inspiration at this moment.

Thanks for any suggestion!

Hello,

Not an answer to Your exact question but if You ask Your ISPs to send You two halves of default (0/1 and 128/1) instead of 0/0, then You can have Your 0/0 route active in the table (as static/aggregate) and be eligible for BGP export to that exotic device.

On side note, aggregates with Reject next-hop are really bad practice for several reasons, You should always strive to nail down Your summaries/default as static discards.

HTH

Thx

Alex

Thanks for the suggestion, it is indeed a good idea if they are willing to do so. I'm not sure if there was an official way to achieve what I wanted, but it would be a good alternative. The other similar solution I had thought of was to have at least one guaranteed route by the provider, such as the loopback of the peering device, so that I could generate the default based on that, and not depend on any "public" route validation, nor any other internal subnet of theirs, *in case* they made any routing changes, but this would be even more efficient. I know that the default is generated directly by the peer, so that was an easy validation and granted me ideal routing, but as long as my second router is up and connected with the other ISP, I could have it also send me those two /1s.

My last "in-house" idea was with different logical systems on the MX redistributing routes through a different protocol, but that added complexity that I was trying to avoid.

Thanks

Hello,

Ok, let's reverse the situation - can Your exotic device handle 0/1 + 128/1 with equal AS_PATHs?

You can add 0/1 + 128/1 as aggregate discards with NULL/custom AS_PATH based on specific BGP routes received from Your providers. 

HTH

Thx

Alex

That would actually be much simpler! I'll give that a test and confirm, but it should indeed work very well! 🙂

And the device is not that exotic, unfortunately. Just a commercial LB stuck with ZebOS limitations... Few options left to guess!

Thanks

Hello,

Assuming this ZebOS can handle 0/1+128/1 with equal AS_PATHs, You may need to deny installation of 0/1+128/1 in the FIB to prevent blackholing in case one of Your routers loses its ISP connection. You can do it with forwarding-table policy:

policy-options {
    policy-statement DENY-INSTALL-INTO-FIB {
        term NO-0/1 {
            from { protocol aggregate;
		   route 0/1 exact; }
            then reject;
        }
        term NO-128/1 {
            from { protocol aggregate;
	           route 128/1 exact; }
            then reject;
        }
    }
}
routing-options {
    forwarding-table {
        export [ DENY-INSTALL-INTO-FIB  LOAD-BALANCE ]; ## if LOAD-BALANCE policy already exists
    }
}

HTH

Thanks

Alex

Thanks for that head's up. It turns out that it *somewhat* works.

Officially, it works well at this point and it does install both aggregate routes in the device's routing table. The really weird thing is that officially from ZebOS' point of view, only 0.0.0.0/1 is accepted and installed, even though both routers send 0.0.0.0/1 and 128.0.0.0/1, yet in the device's routing table, I see 0.0.0.0/0 with both routers as a destination, and it can properly communicate with IPs in the upper /1 range.

For some reason, it doesn't want to accept the 128.0.0.0/1 route, as when it's the only route advertised by one of our routers, it does't install anything. I don't understand why or how at this point, but that's another troubleshooting issue that I'm currently trying to figure out.

I have to figure this out, as I'd rather not have a weird state and it's definitely the most efficient solution so far.

Thanks a lot for it!

Hello,

---

@Siegfried wrote:

 

 

For some reason, it doesn't want to accept the 128.0.0.0/1 route, as when it's the only route advertised by one of our routers, it does't install anything.

---

Yeah, I recall seeing same behaviour with VxWorks OS back in 2006-ish.

You may want to try /2, /3 as well. Internet is small - only 7 routes with /3 netmasks 

0/3
32/3
64/3
96/3
128/3
160/3
192/3

HTH

Thanks

Alex