[rbak-nsp] forwarding policy

Richard Clayton sledge121 at gmail.com
Tue Mar 1 15:42:25 EST 2011


Ian

Thanks for the lesson, I probably should read up on the architecture rather
than assuming it's a Cisco in a different coloured box, maybe some formal
training rather than the pdf's I found and our SE lab.

Thanks
Rick

On 1 March 2011 20:11, Ian Calderbank <ian at calderbankconsulting.co.uk>wrote:

> Redback does forwarding using the PPA, end of story. (apart from some very
> special exceptions).
>
> Process-switching concept doesn't exist outside of cisco. Seems your
> friendly local redback SE isn't giving you the basic architecture lesson?
>
> <history>
> Ye olde Cisco way of  forwarding packets = process switching,
> fast-switching
> yada yada
> Cisco invented Cef then better DCEF = Distributed forwarding using line
> card
> processors (VIP's on 7500's in the mid 90s) to perform all forwarding
> actions (except those that CEF didn't support.. which was the issue).
>
> Juniper did it properly with a box with a "strict separation of control and
> forwarding planes" architecture (enter stage left to thunderous applause
> the
> M series). impossible for a transit packet to touch the control processor.
> The forwarding processor (either a shared forwarding blade, or a chip on a
> line card) does all the forwarding work. Control cpu cruises at 1% if the
> network is converged/stable, regardless of the forwarding load.
>
> Redback followed suit with the SE. Did a bit more work on modularising the
> control plane than J, different backplane design, different asics of
> course,
> but still the fundamental separation of forwarding and control processors
> and data paths, transit packet unable to touch the RP.
> </history>
>
> As david mentions there are corner case applications where you might
> deliberately redirect the packet to the RP such as http url redirect .
> Session Border controller does the same for SIP I would expect.
>
> For a regular forwarding policy, it just adds another link in the PPA's
> chain of actions (called a PED graph) that are to be applied to that
> circuit. Each PED costs you a bit of resource (mem , cpu) on the PPA. But
> so
> long as your PPA's are not overcooked - don't worry about it.
>
> cheers
> Ian
>
> -----Original Message-----
> From: redback-nsp-bounces at puck.nether.net
> [mailto:redback-nsp-bounces at puck.nether.net] On Behalf Of
> redback-nsp-request at puck.nether.net
> Sent: 28 February 2011 17:00
> To: redback-nsp at puck.nether.net
> Subject: redback-nsp Digest, Vol 38, Issue 13
>
> Send redback-nsp mailing list submissions to
>        redback-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://puck.nether.net/mailman/listinfo/redback-nsp
> or, via email, send a message with subject or body 'help' to
>        redback-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
>        redback-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of redback-nsp digest..."
>
>
> Today's Topics:
>
>   1. forwarding policy (Richard Clayton)
>   2. Re: forwarding policy (david.freedman at uk.clara.net)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 27 Feb 2011 22:05:43 +0000
> From: Richard Clayton <sledge121 at gmail.com>
> To: redback-nsp at puck.nether.net
> Subject: [rbak-nsp] forwarding policy
> Message-ID:
>        <AANLkTinwxkUwkiStm6PuGt=xdPaf1TjPNeeyid7f=K-c at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Am I correct in thinking that a Redback forwarding policy is process
> switched, the same as Cisco policy-based routing.
>
> Thanks
> Rick
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <
> https://puck.nether.net/pipermail/redback-nsp/attachments/20110227/a50d24e4
> /attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 27 Feb 2011 22:10:28 +0000 (GMT)
> From: david.freedman at uk.clara.net
> To: sledge121 at gmail.com
> Cc: redback-nsp at puck.nether.net
> Subject: Re: [rbak-nsp] forwarding policy
> Message-ID:
>        <Pine.BSF.4.58.1102272206340.31883 at singularity.convergence.cx>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> >Am I correct in thinking that a Redback forwarding policy is process
> >switched
>
> Not quite sure what you mean here, my understanding is that unless you are
> using XCRP services (such as the http server), then the forwarding actions
> occur in hardware, on the PPA,
>
>
> [thingy]redback# show forward policy foo
>
> Policy-Name                Type     Grid    Qs Slots  Ports  Bound  DnLd
> Status
> foo                        forward  14      0  1      4      in
>
> Slot#:       1   2   3   4   5   6   7   8   9  10  11  12  13  14
> iPPA dnld:
> ePPA dnld:
> iPPA ports:  4
> ePPA ports:
>
> Class-Name          Action  Mode  IP-Addr/Option   Bound  Int,msec
> Output-Name
> redirect-class      redir   local
> drop-class          drop
>
> Total policy map: 1
>
> I believe this is possible because these are FPGA , though I'm sure there
> are some internal limits to how nested operations can be.
>
> Dave.
>
>
>
> ------------------------------
>
> _______________________________________________
> redback-nsp mailing list
> redback-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/redback-nsp
>
>
> End of redback-nsp Digest, Vol 38, Issue 13
> *******************************************
>
> _______________________________________________
> redback-nsp mailing list
> redback-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/redback-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/redback-nsp/attachments/20110301/48197c39/attachment.html>


More information about the redback-nsp mailing list