[j-nsp] routing updates between PFEs and Kernal

Good One good1 at live.com
Wed Nov 3 14:34:59 EDT 2010


Thanks for an useful information, Richard.
Well, a DPC has a 1G ram inside and if each PFE has a complete copy of the routing table (even the best route) and you are receiving a full feed of internet and a thousands of your own routes, then all the 4 PFEs should occupy the 1G RAM (I assume all 4 PFEs are using/sharing the DPC 1G ram to store routing table) ... 
not sure how to connect to a PFE individually, all I can do is 'start shell pfe network fpc0' which connects you to a DPC and not the PFEs sitting somewhere on the DPC :)
Regards,Andrew
  
> Date: Wed, 3 Nov 2010 12:20:06 -0500
> From: ras at e-gerbil.net
> To: good1 at live.com
> CC: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] routing updates between PFEs and Kernal
> 
> On Wed, Nov 03, 2010 at 02:00:11PM +0500, Good One wrote:
> > 
> > We started using MX-480 and I came to know that each DPC has four 
> > PFEs. Now a question comes to mind that how the chemistry of routing 
> > updates in between PFEs and RE(kernel) is being done. If kernel routes 
> > are being exported to PFEs, does it means that each PFE contains a 
> > full routing table? So if you have five DPCs than you have 20 PFEs and 
> > you are exporting kernel routes to all 20 PFEs and each PFEs is having 
> > a best route in the forwarding table.
> 
> Yes each PFE has a complete copy of the routing table and makes the 
> routing decision for ingress packets, this is how distributed forwarding 
> works. I suspect what actually happens is the kernel sends it's routing 
> table (krt) to the CPU on the DPC, which then programs the individual 
> PFEs on the card (4 per DPC), but I don't work for Juniper or anything 
> so I have no special knowledge about their implementation.
> 
> There is also a fair amount of work that goes into locking and 
> verification of the routes, to ensure that every PFE has a consistent 
> view. Otherwise, you risk creating micro forwarding loops with every 
> route update, or worse macro forwarding loops aka Cisco Customer 
> Enragement Feature. :)
> 
> -- 
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
 		 	   		  


More information about the juniper-nsp mailing list