cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1056
Views
5
Helpful
5
Replies

Unicast Reverse Path Forwarding and CEF

Mitrixsen
Level 1
Level 1

Hello, everyone!

I am currently studying for my ENARSI exam and my current topic is uRPF. CEF is covered very lightly by my ENARSI resources in comparison with ENCOR but I understand that it's a packet switching mechanism whose purpose is to optimize and make the packet forwarding process more efficient. I understand that CEF uses two main data structures/components - the FIB and the adjacency table.

From what I've read about uRPF, uRPF performs a reverse path lookup into the FIB table to determine whether the received packet should be forwarded or not based on whether the source IP is valid. If CEF is disabled, uRPF won't work.

Why is it that uRPF won't work without CEF? I suppose that having CEF disabled would cause the absence of the FIB but there is still a routing table that uRPF can use to perform its lookups, can it not?

Thank you in advance for your help.

Kind regards,

David

 

2 Accepted Solutions

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @Mitrixsen ,

it is an implementation choice  made by Cisco , almost all modern and current features have CEF enabled as a requirement.

For some platforms like multilayer switches and ASR1000 with hardware assistance CEF is implemented in hardware and provides high performance in the forwarding plane.

CEF exceptions are punted to main CPU and can be processed by some policers (rate limited in CoPP )  to protect the main CPU resources.

uRPF uses the FIB table to detect if a packet has been received on the interface that would be used to send traffic to the source ( uRPF strict mode) so uRPF requires CEF to be enabled.

In theory yes the routing table might be used to find out the route to the source but the packet forwarding would be not efficient with CEF disabled causing a much higher impact on main CPU or even causing not using ASIC based hardware that use CEF data structures FIB and adjacency table.

Hope to help

Giuseppe

 

View solution in original post

"it is an implementation choice  made by Cisco , almost all modern and current features have CEF enabled as a requirement."

Indeed!

@Mitrixsen have you ever looked at some old router performance tables showing "process switching" 10x (or more) slower than "fast/CEF switching"?  This on small router platforms without any special switching hardware.

So, how would you feel, if you came along, have uRPF enabled, disabled CEF, and find that one feature, alone, now reduces your forwarding capacity by 10x or more?

What's often not fully appreciated by many network engineers, is how some "routine" network operations versus other "routine" operations are much, much more time consuming to do without specialized hardware, and such specialized hardware isn't easy to design (and often can add much to the price of the system).  I.e. to many network engineers, no big difference between forwarding L2 frames vs. L3 packets - but not always so!

So, Cisco chose not to support uRPF w/o CEF, because they chose to.  Laugh.  What both Giuseppe and I have described, might be good reasons they made this decision, based on technical impact, but, and/or other reasons might be in play too, such as they don't want to expend their dev resources creating and supporting this non-CEF variant, and/or they see this part of their marketing of the value of the combination, and/or . . .

When you try to draw back the curtain on "why" a vendor does something, it might make sense, it might not, but often, until you draw back that curtain, sometimes you just need to accept "it just is".  ; )

Notwithstanding the forgoing, I too often wonder about, a vendor did that?  Why?

One of my many stories . . .

So, decades ago, when I purchased by first microcomputer, its CPU ran at 1.77 MHz, but it was a 2.0 MHz chip.  Huh?  Why?

Being curious, I did a lot of research, BTW it was much harder, back then, before we had the Internet, and search engines we have had for decades now, not to mention forums where you might post such a question, but . . . 

Well, supposedly, the microcomputer vendor was concerned will the CPU reliably run at 2 MHz?  If it doesn't, it reflects poorly on us.  So, they "slowed" the system down to improve their odds for there not being any glitches.  (I recall, years later, IBM did the same with its PC  That CPU was rated for 5 MHz, but they ran it at 4.77 MHz.  Back then, I recall, it too was slowed to better guarantee reliability, but [right now] just checking its "why", and found, it's also noted it allowed a better clock rate to support video and/or it saved 50 cents for other hardware components.)  What's the actual truth?  I cannot say, but generally, a vendor has a reason, but, yea, they too flip coins.

View solution in original post

5 Replies 5

M02@rt37
VIP
VIP

Hello @Mitrixsen,

uRPF can not work without CEF. uRPF checks the source IP address of incoming packets against the routing table to ensure that the packet arrives on the expected interface. The routing table contains information about the routes to different destinations, and uRPF uses this information to validate the source IP address.

Good continuation for your cert prep.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Thank you for your reply!

That seems wrong. uRPF checks the source IP address and performs a reverse path lookup using the FIB. You cannot even enable uRPF without having CEF enabled first. Where did you get this information from?

Mitrixsen_1-1692886355282.png

For more information about Unicast RPF-related features and technologies, review the following:

 

"Unicast RPF requires Cisco express forwarding (CEF) to function properly on the switch. For more information about CEF, refer to the Cisco IOS Switching Services Configuration Guide."

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/53SG/configuration/config/schrpf.html

 

Thanks @Mitrixsen.

uRPF performs a reverse path lookup using the FIB, which is a key component of CEF. Without CEF, the FIB is not available, and uRPF cannot perform the necessary lookups to validate the source IP address of incoming packets.

Router will actually rely on the CEF table to perform lookups.

Thank you for clarifying and the link shared.

https://ccie-or-null.net/2012/09/10/cisco-urpf/

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @Mitrixsen ,

it is an implementation choice  made by Cisco , almost all modern and current features have CEF enabled as a requirement.

For some platforms like multilayer switches and ASR1000 with hardware assistance CEF is implemented in hardware and provides high performance in the forwarding plane.

CEF exceptions are punted to main CPU and can be processed by some policers (rate limited in CoPP )  to protect the main CPU resources.

uRPF uses the FIB table to detect if a packet has been received on the interface that would be used to send traffic to the source ( uRPF strict mode) so uRPF requires CEF to be enabled.

In theory yes the routing table might be used to find out the route to the source but the packet forwarding would be not efficient with CEF disabled causing a much higher impact on main CPU or even causing not using ASIC based hardware that use CEF data structures FIB and adjacency table.

Hope to help

Giuseppe

 

"it is an implementation choice  made by Cisco , almost all modern and current features have CEF enabled as a requirement."

Indeed!

@Mitrixsen have you ever looked at some old router performance tables showing "process switching" 10x (or more) slower than "fast/CEF switching"?  This on small router platforms without any special switching hardware.

So, how would you feel, if you came along, have uRPF enabled, disabled CEF, and find that one feature, alone, now reduces your forwarding capacity by 10x or more?

What's often not fully appreciated by many network engineers, is how some "routine" network operations versus other "routine" operations are much, much more time consuming to do without specialized hardware, and such specialized hardware isn't easy to design (and often can add much to the price of the system).  I.e. to many network engineers, no big difference between forwarding L2 frames vs. L3 packets - but not always so!

So, Cisco chose not to support uRPF w/o CEF, because they chose to.  Laugh.  What both Giuseppe and I have described, might be good reasons they made this decision, based on technical impact, but, and/or other reasons might be in play too, such as they don't want to expend their dev resources creating and supporting this non-CEF variant, and/or they see this part of their marketing of the value of the combination, and/or . . .

When you try to draw back the curtain on "why" a vendor does something, it might make sense, it might not, but often, until you draw back that curtain, sometimes you just need to accept "it just is".  ; )

Notwithstanding the forgoing, I too often wonder about, a vendor did that?  Why?

One of my many stories . . .

So, decades ago, when I purchased by first microcomputer, its CPU ran at 1.77 MHz, but it was a 2.0 MHz chip.  Huh?  Why?

Being curious, I did a lot of research, BTW it was much harder, back then, before we had the Internet, and search engines we have had for decades now, not to mention forums where you might post such a question, but . . . 

Well, supposedly, the microcomputer vendor was concerned will the CPU reliably run at 2 MHz?  If it doesn't, it reflects poorly on us.  So, they "slowed" the system down to improve their odds for there not being any glitches.  (I recall, years later, IBM did the same with its PC  That CPU was rated for 5 MHz, but they ran it at 4.77 MHz.  Back then, I recall, it too was slowed to better guarantee reliability, but [right now] just checking its "why", and found, it's also noted it allowed a better clock rate to support video and/or it saved 50 cents for other hardware components.)  What's the actual truth?  I cannot say, but generally, a vendor has a reason, but, yea, they too flip coins.