Monday, February 8, 2010

Should IPC's be redistributed by OSPF?

I have a tac case open for over 5 months, regarding the default redistribution of 127/8 when "service internal" is configured on a C10000 router. Keep in mind that i'm redistributing all connected routes to OSPF.


C10k-33SB7>sh ip route
Routing entry for, 2 known subnets
Attached (2 connections)
Variably subnetted with 2 masks
Redistributing via ospf x
C is directly connected, Ethernet0/0/0
L is directly connected, Ethernet0/0/0

C10k-33SB7>sh ip ospf database self-originate | i x.x.x.x 1590 0x80001C02 0x00FA81 0

If i understand correctly, 127/8 is used by the IPC (Inter-Process Communication) channel on the C10k. According to Cisco:

"Ethernet 0/0/0 is assigned to the backplane. It is not a user configurable interface. The reason for this is to provide a loopback interface for testing purposes. You cannot configure it or make it go away. There will be no impact on routing since all addresses in the 127/8 are illegal for routing purposes."

Of course, the reason i have to carry all those non-routable prefixes in my OSPF database is of no concern to Cisco.

another-router>sh ip ospf database | i x.x.x.x 601 0x80000932 0x00BEC7 0 x.x.x.x 347 0x80001C02 0x00FA81 0 x.x.x.x 288 0x80000918 0x00FB7B 0 x.x.x.x 526 0x800026EE 0x00E9EE 0 x.x.x.x 1972 0x80000917 0x00A8DE 0 x.x.x.x 110 0x80002563 0x00D622 0

Cisco proposes to simply filter them using access-lists/prefix-lists, but i cannot understand why i have to filter something that shouldn't be there in any case. After all, i'm already filtering customer routes where i would expect such routes.

Some months ago, Cisco had issued a security advisory about the IPC being externally reachable. Both bugs (CSCsg15342, CSCsh29217) referenced in that advisory include exactly the same info, but i don't know what was actually fixed.

IPC processing needs to be more robust
Cisco 10000, uBR10012 and uBR7200 series devices use a User Datagram Protocol (UDP) based Inter-Process Communication (IPC) channel that is externally reachable. An attacker could exploit this vulnerability to cause a denial of service (DoS) condition on affected devices. No other platforms are affected.

Probably they fixed the reachable part and messed up the announce part, because in previous IOS there wasn't such an issue :

C10k-31SB14>sh ip route
Routing entry for
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via ospf x
Routing Descriptor Blocks:
* directly connected, via Ethernet0/0/0
Route metric is 0, traffic share count is 1

C10k-31SB14>sh ip ospf database self-originate | i

I have heard tens of excuses about "service internal", but i haven't heard anything that mandates this silly 127/8 redistribution. If anyone knows the actual reason behind this, i would be very glad to hear it.


  1. Interesting bug. There is no valid reason why 127/8 should ever be announced by a routing protocol by any vendor for any reason. Sure there could be academic modeling that uses these addresses, but it's just not worth the potential pain.

  2. just curious from someone whos trying to learn with no knowledge-jack


Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.