Mailing List Archive: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table

"next-table" Equivalent for IOS XR - Default Route into Global Routing Table

Aug 28, 2023, 11:48 PM

Post #1 of 12 (505 views)

Hi all.

I've been racking my brain trying to implement an equivalent feature in
IOS XR 6.7.1 similar to Junos' "next-table" feature.

Essentially, I am trying to point all unknown destinations from within a
VRF toward the local global table for resolution. In Junos, it's as easy as:

static {
            route 0.0.0.0/0 next-table inet.0;
        }

rib VRF.inet6.0 {
            static {
                route ::/0 next-table inet6.0;
            }

In IOS XR, we have:

vrf VRF
address-family ipv4 unicast
   0.0.0.0/0 vrf default

vrf VRF
address-family ipv6 unicast
   ::/0 vrf default

The Junos one works straight out of the box.

IOS XR is a bit more petulant.

And if you look at the VRF FIB, the route exists:

    S*   0.0.0.0/0 [1/0] via 0.0.0.0 (nexthop in vrf default), 00:15:06

But CEF says it is a "drop", likely because there is no associated
output interface.

The most I could do was to point the static route out via "vrf default",
but to another PE device that carries the DFZ (with its Loopback address
as the target). This works well, but surely cannot be expected to be a
lasting solution, because the router on which this VRF is configured
already carries the DFZ. So why send the traffic to another PE router
and cause it to handle traffic it should not be handling?

I've given up and just swapped the IOS XR box with a Junos one, and
fixed the issue that way.

But for posterity, has anyone ran into this and came up with a working
solution, or is IOS XR just deficient in this regard? I don't understand
the point of being able to point default to the global table in a VRF,
and then not be able to actually use it. Thanks.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 2:05 AM

Post #2 of 12 (505 views)

Permalink

Would this be a case where vasi-left and vasi-right interfaces are appropriate? Essentially same as an LT in Junos.
Not as elegant for sure, but should function.

Cheers,
Fraser

> On 29 Aug 2023, at 4:48 pm, Mark Tinka via cisco-nsp <cisco-nsp@puck.nether.net> wrote:
>
> Hi all.
>
> I've been racking my brain trying to implement an equivalent feature in IOS XR 6.7.1 similar to Junos' "next-table" feature.
>
> Essentially, I am trying to point all unknown destinations from within a VRF toward the local global table for resolution. In Junos, it's as easy as:
>
> static {
> route 0.0.0.0/0 next-table inet.0;
> }
>
> rib VRF.inet6.0 {
> static {
> route ::/0 next-table inet6.0;
> }
>
> In IOS XR, we have:
>
> vrf VRF
> address-family ipv4 unicast
> 0.0.0.0/0 vrf default
>
> vrf VRF
> address-family ipv6 unicast
> ::/0 vrf default
>
> The Junos one works straight out of the box.
>
> IOS XR is a bit more petulant.
>
> And if you look at the VRF FIB, the route exists:
>
> S* 0.0.0.0/0 [1/0] via 0.0.0.0 (nexthop in vrf default), 00:15:06
>
> But CEF says it is a "drop", likely because there is no associated output interface.
>
> The most I could do was to point the static route out via "vrf default", but to another PE device that carries the DFZ (with its Loopback address as the target). This works well, but surely cannot be expected to be a lasting solution, because the router on which this VRF is configured already carries the DFZ. So why send the traffic to another PE router and cause it to handle traffic it should not be handling?
>
> I've given up and just swapped the IOS XR box with a Junos one, and fixed the issue that way.
>
> But for posterity, has anyone ran into this and came up with a working solution, or is IOS XR just deficient in this regard? I don't understand the point of being able to point default to the global table in a VRF, and then not be able to actually use it. Thanks.
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 2:16 AM

Post #3 of 12 (505 views)

Permalink

On 8/29/23 11:05, Fraser McGlinn wrote:

> Would this be a case where vasi-left and vasi-right interfaces are appropriate? Essentially same as an LT in Junos.
> Not as elegant for sure, but should function.

IIRC, VASI support was only on the MSB (Multi Service Blade) on the XR
12000 platform. There was no support for the ASR9000 (I was working on a
rather ancient ASR9001). If someone with more ASR9000 clue knows if
support is now enabled for that platform, please chime in.

We do use "virtual-router" routing instances in Junos to basically make
a whole new router inside an existing router. But we don't use that
feature too often because it impacts ultimate PFE performance in a way
that a regular "vrf" routing instance does not.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 2:40 AM

Post #4 of 12 (505 views)

Permalink

On 29/08/2023 at 6:48:32 PM, Mark Tinka via cisco-nsp <
cisco-nsp@puck.nether.net> wrote:

> Hi all.
>
> I've been racking my brain trying to implement an equivalent feature in
> IOS XR 6.7.1 similar to Junos' "next-table" feature.
>
> Essentially, I am trying to point all unknown destinations from within a
> VRF toward the local global table for resolution. In Junos, it's as easy
> as:
>
> static {
> route 0.0.0.0/0 next-table inet.0;
> }
>
> rib VRF.inet6.0 {
> static {
> route ::/0 next-table inet6.0;
> }
>
> In IOS XR, we have:
>
> vrf VRF
> address-family ipv4 unicast
> 0.0.0.0/0 vrf default
>
> vrf VRF
> address-family ipv6 unicast
> ::/0 vrf default
>
> The Junos one works straight out of the box.
>
> IOS XR is a bit more petulant.
>
> And if you look at the VRF FIB, the route exists:
>
> S* 0.0.0.0/0 [1/0] via 0.0.0.0 (nexthop in vrf default), 00:15:06
>
> But CEF says it is a "drop", likely because there is no associated
> output interface.
>
> The most I could do was to point the static route out via "vrf default",
> but to another PE device that carries the DFZ (with its Loopback address
> as the target). This works well, but surely cannot be expected to be a
> lasting solution, because the router on which this VRF is configured
> already carries the DFZ. So why send the traffic to another PE router
> and cause it to handle traffic it should not be handling?
>
> I've given up and just swapped the IOS XR box with a Junos one, and
> fixed the issue that way.
>
> But for posterity, has anyone ran into this and came up with a working
> solution, or is IOS XR just deficient in this regard? I don't understand
> the point of being able to point default to the global table in a VRF,
> and then not be able to actually use it. Thanks.
>

I spent a bit of time working on this problem years ago, and ultimately
there didn’t end up being any ideal solutions. Looking at rancid, it looks
like 7+ years ago. We ultimately ended up on JunOS, too.

We were learning a default from an eBGP peer on the same node, so we were
able to leak that in to the other VRF and get more or less what we wanted -
but it wasn’t ideal.
I can’t recall if it would do a route lookup in the VRF that had the eBGP
peer or not, I have a funny feeling it did what we wanted it do, though.
Obviously for packets coming from other PEs following that default, it
would work as desired (we were running per-VRF labels). Perhaps you could
experiment with that. If it does a route lookup, you could run a BGP
session over a hand-bag cable so that you have an eBGP default you can leak
- and in theory only traffic that doesn’t match your DFZ routes would go
down that link. Messy, but, might work?

From memory, if you create a static default and leak that, it follows
wherever that default goes, and doesn’t follow the logic you would expect
for label mode per-vrf - so if it’s a default to null, the packets get
dropped. Default to a vrf with a next-hop - packets go out to that next-hop.

--
Nathan Ward
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 3:43 AM

Post #5 of 12 (505 views)

Permalink

Would something like this work?

https://learningnetwork.cisco.com/s/question/0D53i00000KstGrCAJ/ios-xr-leaking-the-routes-between-vrf-and-global-rib

On Tue, Aug 29, 2023, 7:49 AM Mark Tinka via cisco-nsp <
cisco-nsp@puck.nether.net> wrote:

> Hi all.
>
> I've been racking my brain trying to implement an equivalent feature in
> IOS XR 6.7.1 similar to Junos' "next-table" feature.
>
> Essentially, I am trying to point all unknown destinations from within a
> VRF toward the local global table for resolution. In Junos, it's as easy
> as:
>
> static {
> route 0.0.0.0/0 next-table inet.0;
> }
>
> rib VRF.inet6.0 {
> static {
> route ::/0 next-table inet6.0;
> }
>
> In IOS XR, we have:
>
> vrf VRF
> address-family ipv4 unicast
> 0.0.0.0/0 vrf default
>
> vrf VRF
> address-family ipv6 unicast
> ::/0 vrf default
>
> The Junos one works straight out of the box.
>
> IOS XR is a bit more petulant.
>
> And if you look at the VRF FIB, the route exists:
>
> S* 0.0.0.0/0 [1/0] via 0.0.0.0 (nexthop in vrf default), 00:15:06
>
> But CEF says it is a "drop", likely because there is no associated
> output interface.
>
> The most I could do was to point the static route out via "vrf default",
> but to another PE device that carries the DFZ (with its Loopback address
> as the target). This works well, but surely cannot be expected to be a
> lasting solution, because the router on which this VRF is configured
> already carries the DFZ. So why send the traffic to another PE router
> and cause it to handle traffic it should not be handling?
>
> I've given up and just swapped the IOS XR box with a Junos one, and
> fixed the issue that way.
>
> But for posterity, has anyone ran into this and came up with a working
> solution, or is IOS XR just deficient in this regard? I don't understand
> the point of being able to point default to the global table in a VRF,
> and then not be able to actually use it. Thanks.
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 5:18 AM

Post #6 of 12 (505 views)

Permalink

On 8/29/23 12:43, Arie Vayner wrote:
> Would something like this work?
>
> https://learningnetwork.cisco.com/s/question/0D53i00000KstGrCAJ/ios-xr-leaking-the-routes-between-vrf-and-global-rib

That very thread was the last thing I tried this morning. It didn't work
either.

I suspected that it could be because we have 0/0 and ::/0 pointing to
Null0 in our DFZ on the box. So I changed that and pointed it to
something useful, and still, the default route would not import into the
VRF.

I then decided to walk away from IOS XR and move to Junos.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 5:28 AM

Post #7 of 12 (505 views)

Permalink

On 8/29/23 11:40, Nathan Ward wrote:

> We were learning a default from an eBGP peer on the same node, so we
> were able to leak that in to the other VRF and get more or less what
> we wanted - but it wasn’t ideal.

I tested the same by pointing 0/0 to another PE via the default VRF, and
that worked. But the traffic was being forwarded through the remote PE,
which is not sensible.

> I can’t recall if it would do a route lookup in the VRF that had the
> eBGP peer or not, I have a funny feeling it did what we wanted it do,
> though.

From my tests, unknown destination traffic was be pulled into the
global table, and sent to the remote PE configured as the default
route's next hop in the VRF, which worked. I am guessing that was label
switched traffic toward default route next hop.

> Obviously for packets coming from other PEs following that default, it
> would work as desired (we were running per-VRF labels). Perhaps you
> could experiment with that. If it does a route lookup, you could run a
> BGP session over a hand-bag cable so that you have an eBGP default you
> can leak - and in theory only traffic that doesn’t match your DFZ
> routes would go down that link. Messy, but, might work?

Yeah, the site is remote. Don't have the energy for sexiness :-).

>
> From memory, if you create a static default and leak that, it follows
> wherever that default goes, and doesn’t follow the logic you would
> expect for |label mode per-vrf| - so if it’s a default to null, the
> packets get dropped. Default to a vrf with a next-hop - packets go out
> to that next-hop.

Interesting, I always wondered what the equivalent for Junos'
"vrf-table-label" was. Thanks for this :-).

So yes, our default routes point to Null0. I changed that to something
useful and it still didn't work. It's almost as if the traffic exiting
the VRF toward the global table wanted to follow a label switched path,
and not an IP-based path. Not sure whether "label mode per-vrf" would
have helped to obfuscate the fact that the global table default routes
pointed to Null0, but it's too late to test now. The box has been
swapped out.

But this is a good tip. I'll ask the next person who runs into this to
update this post with their experience.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 6:17 AM

Post #8 of 12 (505 views)

Permalink

Hi,

On Tue, Aug 29, 2023 at 02:28:53PM +0200, Mark Tinka via cisco-nsp wrote:
> So yes, our default routes point to Null0. I changed that to something
> useful and it still didn't work. It's almost as if the traffic exiting the
> VRF toward the global table wanted to follow a label switched path, and not
> an IP-based path. Not sure whether "label mode per-vrf" would have helped to
> obfuscate the fact that the global table default routes pointed to Null0,
> but it's too late to test now. The box has been swapped out.

My guess after staring long and hard at IOS XR and VRF leaking is that
the CEF structures are getting in the way here - on ingress forward lookup,
as far as I understand, the system expects to find complete egress
information, as in "output line card, output interface, encapsulation,
destination MAC".

When you create a route to another VRF "with an egress interface", this
information can then be populated properly. Asking for "go to the other
VRF and do a routing table lookup over there" needs packet recirculation,
and (again, guessing from how I understand the architecture) this is just
not possible.

... unless you add a loop cable somewhere.

... maybe they could have made a virtual loop cable (LT-), but maybe not...

So, yes, I would be interested what exactly happens inside the box, and
why it does not work / how hard it would be with existing ASR9k NPUs to
make it work (technically) but I expect there will be no answer on this.

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: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 9:07 AM

Post #9 of 12 (505 views)

Permalink

On 8/29/23 15:17, Gert Doering wrote:
> So, yes, I would be interested what exactly happens inside the box, and
> why it does not work / how hard it would be with existing ASR9k NPUs to
> make it work (technically) but I expect there will be no answer on this.

I didn't even bother asking our SE.

One could probably find out, with enough energy, but I've given up on
IOS XR... also because BGP Add-Paths setup in IOS XR is unnecessarily
complicated if you compare it to IOS XE.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Aug 29, 2023, 9:42 AM

Post #10 of 12 (505 views)

Permalink

On 8/29/23 18:22, Daniël Verlouw wrote:

> slightly different approach, but I’ve had some success with ACL-based
> VRF select, but it really depends on your use-case:
>
> https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-abf-acl-based-forwarding/ta-p/3153403
>
> Something like:
>
> ipv4 access-list FOO
> remark Don’t perform FBF on intra-VRF traffic
> permit ipv4 <intra VRF>
> remark Forward everything else to VRF of your choice, default or
> non-default
> permit ipv4 any any nexthop1 <vrf>
> !
>
> int x/y/z
> vrf YOURVRF
> ipv4 access-list FOO ingress
> !
>
>
> Also works on NCS:
> https://xrdocs.io/ncs5500/tutorials/acl-based-forwarding-and-object-tracking-for-ncs5xx-and-ncs55xx/

I did come across a suggestion about using ABF for this, but it
immediately stood out as a 3-legged stool.

If it is working for you, that's good to bank for the archives.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Sep 2, 2023, 5:05 PM

Post #11 of 12 (483 views)

Permalink

As you found out, XR won't forward the traffic using inter-VRF route
leaking if it has to do another recursive lookup in the next VRF. It
requires specifying the next-hop/interface or leaking the more specific
routes into the VRF. So if you have 0/0 pointing to null0 that's not going
to work. If you have one pointing somewhere else, then it will. Some
Junos platforms won't do this either BTW, it's somewhat dependent on the
forwarding hardware.

ABF works but it's more similar to using filter based forwarding in Junos.

Thanks,
Phil

On Tue, Aug 29, 2023 at 12:43?PM Mark Tinka via cisco-nsp <
cisco-nsp@puck.nether.net> wrote:

>
>
> On 8/29/23 18:22, Daniël Verlouw wrote:
>
> > slightly different approach, but I’ve had some success with ACL-based
> > VRF select, but it really depends on your use-case:
> >
> >
> https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-abf-acl-based-forwarding/ta-p/3153403
> >
> > Something like:
> >
> > ipv4 access-list FOO
> > remark Don’t perform FBF on intra-VRF traffic
> > permit ipv4 <intra VRF>
> > remark Forward everything else to VRF of your choice, default or
> > non-default
> > permit ipv4 any any nexthop1 <vrf>
> > !
> >
> > int x/y/z
> > vrf YOURVRF
> > ipv4 access-list FOO ingress
> > !
> >
> >
> > Also works on NCS:
> >
> https://xrdocs.io/ncs5500/tutorials/acl-based-forwarding-and-object-tracking-for-ncs5xx-and-ncs55xx/
>
> I did come across a suggestion about using ABF for this, but it
> immediately stood out as a 3-legged stool.
>
> If it is working for you, that's good to bank for the archives.
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: "next-table" Equivalent for IOS XR - Default Route into Global Routing Table [ In reply to ]

cisco-nsp at puck

Sep 2, 2023, 10:15 PM

Post #12 of 12 (483 views)

Permalink

On 9/3/23 02:05, Phil Bedard wrote:

> Some Junos platforms won't do this either BTW, it's somewhat
> dependent on the forwarding hardware.

I was wondering whether anyone running Junos on a current Broadcom chip
has tested this. Trio spoils us.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Mailing List Archive

Mailing List Archive

Attached Files: