128.0.0.0/16 configured as martians in some routers
Mark Tinka
mtinka at globaltransit.net
Tue Dec 6 09:23:53 UTC 2011
On Tuesday, December 06, 2011 04:50:46 PM Florian Weimer wrote:
> Would someone please clarify the impact? Will it result in a blackhole,
> or will the entire announcement be suppressed? I suspect the latter,
> given what we see and what Chris Adams has reported.
This is what we see on Cisco IOS and IOS XR boxes:
lab#sh ip bgp 128.0.0.0
BGP routing table entry for 128.0.0.0/21, version 260804693
Paths: (2 available, best #1, table default)
Advertised to update-groups:
2
3491 3257 1103 12654
61.11.xxx.yy (metric 34400) from 61.11.xxx.zz (61.11.xxx.zz)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 24218:1
Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2
3491 3257 1103 12654
61.11.xxx.yy (metric 34400) from 61.11.xxx.ww (61.11.xxx.ww)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 24218:1
Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2
lab#
RP/0/RSP0/CPU0:lab#sh route 128.0.0.0
Tue Dec 6 17:09:13.439 MYT
Routing entry for 128.0.0.0/21
Known via "bgp 24218", distance 200, metric 0
Tag 3491, type internal
Installed Dec 4 20:00:33.089 for 1d21h
Routing Descriptor Blocks
61.11.xxx.yy, from 61.11.yyy.zz
Route metric is 0
No advertising protos.
RP/0/RSP0/CPU0:lab#
This is what we see on an unfixed Juniper:
tinka at lab# run show route 128.0.0.0
inet.0: 384214 destinations, 768288 routes (384212 active, 0 holddown, 4 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 20w2d 13:21:14
Discard
[edit]
tinka at lab#
tinka at lab# run show route 128.0.0.0/21
inet.0: 384218 destinations, 768296 routes (384216 active, 0 holddown, 4 hidden)
Restart Complete
[edit]
tinka at lab#
tinka at edge-gw-1-sin-pip.sg# run show route 128.0.0.0/21 hidden
inet.0: 384224 destinations, 768308 routes (384222 active, 0 holddown, 4 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
128.0.0.0/21 [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.ww
AS path: 3491 3257 1103 12654 I
> to 124.158.xxx.uu via ge-0/0/0.0, Push 16052
to 124.158.xxx.vv via ge-0/0/0.0, Push 16017
to 124.158.xxx.ww via ge-0/1/0.0, Push 16052
to 124.158.xxx.xx via ge-0/1/0.0, Push 16017
[BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.zz
AS path: 3491 3257 1103 12654 I
> to 124.158.xxx.uu via ge-0/0/0.0, Push 16052
to 124.158.xxx.vv via ge-0/0/0.0, Push 16017
to 124.158.xxx.ww via ge-0/1/0.0, Push 16052
to 124.158.xxx.xx via ge-0/1/0.0, Push 16017
[edit]
tinka at edge-gw-1-sin-pip.sg#
tinka at lab# run show route 128.0.0.0/21 hidden extensive | match State
State: <Hidden Martian Int Ext>
State: <Hidden Martian Int Ext>
[edit]
tinka at lab#
tinka at lab# run show interfaces terse
<snip>
...
fxp1 up up
fxp1.0 up up inet 10.0.0.1/8
10.0.0.4/8
128.0.0.1/2
128.0.0.4/2
inet6 fe80::200:ff:fe00:4/64
fec0::a:0:0:4/64
tnp 0x4
<snip>
...
[edit]
tinka at lab#
This is what we see on a Cisco router which lives behind
an unfixed Juniper router that is peering externally:
lab#sh ip bgp 128.0.0.0
% Network not in table
lab#
So our deduction - if a Juniper router is in the data path,
it will blackhole traffic destined to this address.
If a Juniper is in the control plane path, it will
filter this prefix and not send it to the rest of the
network.
Either way, you're screwed :-).
Cheers,
Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111206/482077fb/attachment.sig>
More information about the NANOG
mailing list