What is mean by null route ?

[palani2010]

What is mean by null route ?

[Leo Laohoo]

Null route, aka "blackhole".  

Whatever data goes into this gets dropped/discarded by the CPU.  

[David Ruess]

Hello,

It's basically like a 'bit bucket' that discard traffic if the router doesn't have a more specific route. Usually a null route is created because a summary address is used. (There are other ways but lets use that example). 

Lets say you have addresses like the following:

172.16.0.0 255.255.255.0

172.16.1.0 255.255.255.0

172.16.2.0 255.255.255.0

These are all /24 masks. So say you want to advertise a summarization of these routes to other routers so you don't have to advertise the individual routes.

You make a summary route of 172.16.0.0 0.0.255.255 Which includes everything 172.16.0.0-172.16.255.255. Your router will advertise the 172.16.0.0/16 network to its neighbors. The problem is you don't have all those other addresses. You just have the 3 mentioned above. So when the router receives traffic for a route that's destined to one of the addresses above it forwards it through. If it received traffic for any of the other 172.16.3.0 - 172.16.255.255 routes it send it to the Null 0 route it has created form the summary command and discards it. This is to prevent traffic from looping/traversing the network needlessly.

YOU can also statically configure a null route depending on your network requirements.

Hope that helps

-David

[MHM Cisco World]

If network advertising by bgp not found exactly same in routing table bgp not advertise it, so we use static route to null to force bgp advertise it.

[Richard Burts]

A "null route" is a route with the next hop of null 0. null 0 is a virtual interface. As others have mentioned there are several possible uses for the null route.

- If you configure a summary address in some dynamic routing protocols the protocol will create an entry in the routing table for the summary address with null 0 as the next hop. This is to take care of the possibility that your summary route may include some destinations for which you do not have a viable route.

- In configuring BGP you sometimes will use a route with null 0 as the next hop to create an entry for a group of networks that you want to advertise.

- It can be an easy way to deal with traffic that you do not want to forward. For example on an edge router there might be some traffic that you do not want to forward into your network. You might configure an access list to deny the traffic. But you could also forward that traffic to null 0. This would be less processing requirement that an access list would have.

[Joseph W. Doherty]

". . . You might configure an access list to deny the traffic. But you could also forward that traffic to null 0. This would be less processing requirement that an access list would have."

BTW, the lessor processing is likely still true on routers that do most, if not all, processing on their CPU.  Might not be true on "larger" routers with dedicated hardware assistance.  Probably not true on L3 switches.

[Richard Burts]

@Joseph W. Doherty I do not agree with your comment about not true on L3 switches, and do not really understand your point about devices with dedicated hardware.

Cisco works very hard to make forwarding decisions as efficient and low processing as possible. If making a routing decision (forward to null 0) results in the traffic being dropped then there is not anything (switch, router, whatever) that can filter and drop traffic with lower processing requirements.

[Joseph W. Doherty]

"Cisco works very hard to make forwarding decisions as efficient and low processing as possible."

@Richard Burts, indeed Cisco does, as that's the "core" function of routing.  However, Cisco usually, at least it appears to me, tries to make other data plane functions as efficient as possible too.  Over the years I've seen Cisco incorporate (on CPU based routers) some data plane function, done in the non-interrupt processing, migrated to interrupt processing.

I've also seen Cisco do things such as creating, on CPU based routers, Turbo ACL processing (i.e. compiled ACLs) to make them more efficient too, such that their usage doesn't otherwise impede forwarding, at least as much as the non-Turbo implementation.

As to "dedicated hardware" (e.g. an ASIC), on L2/L3 switches, this is the norm for L2 and/or L3 forwarding.  Such hardware is what allows "small" switches to have such great forwarding capacity relative to "small" CPU (only) based routers.  Further, sometimes such "dedicated hardware" isn't limited to just supporting L2 or L3 forwarding, but also covers other data plane functions, such as ACLs, QoS, etc.  Because it's difficult and/or expensive, to do all that a software router does on its CPU on "dedicated hardware", switch hardware acceleration is often limited, as, for example, much more limited QoS feature support.

(As a side note, in my last job, when we started to roll out IPv6, I had a IPv4 tunnel hosted on a sup-720, which the 720 supported at wire speed.  I converted the tunnel to IPv6, and forwarding performance dropped through the floor.  Contacting Cisco, they confirmed IPv6 tunneling was not supported by "hardware", on the sup-720. For that, I needed to upgrade to a sup-2T.)

Even for "ordinary" L3 forwarding, if an IP packet has unusual (like using extended options), routing performance might be degraded.

Newer and/or larger "routers" also have "dedicated hardware" to accelerate some, usually highly used, functions.  An earlier example of such a router might be the 7200 VxR using a NSE-1 or the 7304 using a NSE-100 or -150 with a PxF.  (The PxF, is what I have in mind, as an example of "dedicated hardware", on a router, which often, but not always, provided higher forwarding rates.  [Ideally the NSE-150 had over 3x the forwarding performance of a NPE-G2.  If the PxF didn't support whatever, performance was like an NSE-150])  Or, another "router" example would be the ASR 1K with their QuantumProcessor.

Back to switches, most likely support ACLs processing with "dedicated hardware" (again, i.e. an ASIC).  If so, the point I was making, on such devices, dropping packets, via a null route, or via an ACL, probably doesn't make a difference.

I.e. I'm not saying a device with such "dedicated hardware" will ACL drop faster, and with less resource consumption, then null routing, just that null routing is likely also not "faster", as it typically was on a software based routers.

[Joseph W. Doherty]

PS:

Unfortunately, I don't have access to hardware to "lab" this on.  But, @Richard Burts, if you do, i.e. have a traffic generator and something like a 3560/3750, I believe if you push even a gig link at 100% capacity, and drop all its traffic using a null route or ACL I expect you'll not see any difference in CPU impact (provided you don't exceed the TCAM resources for either null routing or dropping via an ACL).

Further, if using an ACL, I suspect you wouldn't see any CPU difference whether dropping on ingress or egress interfaces, or if the "dropping" ACE was the last of 1,000 ACEs (again, assuming, TCAM resources haven't been exceeded).

[Richard Burts]

When using the null route to discard packets the process is quite simple: packet in, packet forwarded. No extra steps.

When using an acl/or other type of filter the process is packet in; invoke the filter; evaluate the acl against the packet; decision to drop; update counters (perhaps some other overhead activity).

No matter how efficient the hardware is, how can it be less processing than the routing solution?

[Joseph W. Doherty]

"No matter how efficient the hardware is, how can it be less processing than the routing solution?"

Rick, again, I'm NOT saying an ACL would have less processing than a routing, I'm saying, with, what I believe, is the usual hardware, on most switches, (null) routing wouldn't be better/faster than using an ACL to discard.

I'm sure you're aware of the old adage "switch when you can, route when you must".  Why was there such an adage, and why were things like tag switching (which grew into MPLS) implemented?  Both because routing a packet is more complex (it's usually the variable length of matching network prefixes) than switching a frame.  Years ago, it was difficult to support routing in hardware.  Or, consider earlier routing using flow based caching (including on supervisors like the cat1).  I.e. first packet routed was "slow", remaining packets were, effectively, L2 switched.

Hardware support improved where L3, often, can be done as fast as L2, at least on a L3 switch.

Ditto, I believe, for many other functions like ACL processing.

On routers, traditionally, we worried about how many ACEs were in the ACL, and/or tried to place the most commonly used ACEs (if logically possible), at the top of the ACL.  My understanding, this isn't an issue on the typical L3 switch.

You did mention things, like an ACL, updating counters.  Again, something that can be done in hardware.  Cisco devices also manage to count packets crossing interfaces too, don't they?  However, there's still consideration with some functions, I believe, like ACLs if you enable logging on a certain ACEs.

[Richard Burts]

 From a Cisco document "A null interface provides an alternative method of filtering without the overhead involved with using access lists. For example, instead of creating an outbound access list that prevents traffic to a destination network from being transmitted out an interface, you can configure a static route for the destination network that points to the null interface." 

The doc is for XE software. See here for details

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/configuration/xe-17/ir-xe-17-book/ir-cfg-vir-if-xe.html?dtid=osscdc000283

[Joseph W. Doherty]

@Richard Burts, yes that Cisco IOS documentation does state what you note, but is this IOS for routers or switches?

[Richard Burts]

That documentation is for anything that runs IOS XE and that includes both routers and switches.

[Joseph W. Doherty]

"That documentation is for anything that runs IOS XE and that includes both routers and switches."

@Richard Burts, agreed, but in your referenced documentation, in the beginning of Read Me First, also includes: "Use Cisco Feature Navigator to find information about feature support, platform support, and Cisco software image support."

Because of such issues, Cisco provides specific documentation for specific platform/software combinations.  I.e. "generic" documentation, as you reference, is not always 100% accurate vis-a-vis a specific platform/software combination.

A likely example example of how a 9200's specific implementation of an IOS-XE version might be different as described in "generic" documentation could be in QoS feature support.

Priority to my last reply, I (quickly) examined Catalyst 9200 documentation for its latest IOS-XE variant - didn't find similar NULL interface mention ("like" 9200 section), but may have missed it. I also did (briefly) scan (and search) 9200 and 9400 documentation (their latest code releases), couldn't find a similar statement in their configuration guides. Again, though, I might have missed any similar statement within the specific Catalyst documentation I was text searching.

Even if such a statement, was found, in might very well be incorrect, as with IOS bugs, Cisco does, on occasion, have errors in their documentation too.

Personally, the statement you noted/referenced, I believe is almost always true for routers, as least those without additional hardware assist feature support, but also believe likely almost always not true for many L3 switches.  (Once again, I'm not saying an ACL, for dropping, would be "better" on a L3 switch vs, dropping via a null route, I'm saying, likely they are about the same.)

Also again, I no longer have the hardware to verify one or the other, but in times past, I found trying something on actual hardware was the only way to tell for sure, although, sometimes, "for sure" demonstrated a bug (in software or documentation [laugh, many, many years/decades ago, I went to the trouble of documenting, to the hardware vendor {not Cisco}, a feature that didn't appear to work correctly - 3 months later vendor provided the fix, which was, I kid you not, a couple of pages of replacement documentation which included one page of "this page intentionally blank - {i.e. they removed the feature}]).

For a moment, let's assume I'm correct, i.e. null routing and ACL dropping, are, on a L3 switch, on par for impact usage on the switch.  If such is true, why not just use null routing all the time?  You could, but as often ACLs may encompass more complex ACEs than a destination prefix, and/or have both such simple and complex ACEs, is it really worthwhile to create NULL routes to avoid having them as ACEs in an ACL you otherwise still need?

If NULL routing is truly so much better on all platforms, it might be worthwhile to split off some ACEs, especially if highly "hit".  But if there's no real performance benefit, it might be foolish to do so.

Again, wish I had the hardware to test on, but alas, I don't.  Without such, though, on most, if not all, L3 switches, would be surprised if ACLs matching isn't done at wire-speed, in hardware.