0

studying for my JNCIS-SP and finally digging into the minutiae. I'm trying to grasp the default behavior of aggregate/summary routes. Why are these a reject? Maybe I'm just using them wrong, but here's my config:

vMX6

[edit]
jcluser@vMX6# show routing-options
static {
    route 0.0.0.0/0 next-hop 100.123.0.1;
}
aggregate {
    route 172.29.0.0/22;
}

[edit]
jcluser@vMX6# show policy-options
policy-statement aggregete->ospf {
    from protocol aggregate;
    then accept;
}

[edit]
jcluser@vMX6# show protocols ospf
area 0.0.0.2 {
    interface ge-0/0/3.0;
    interface ge-0/0/4.0;
    interface lo0.0;
    interface ge-0/0/1.0;
}
export aggregete->ospf;

[edit]
jcluser@vMX6# run show route 172.29.0.0/22

inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.29.0.0/22      *[Aggregate/130] 00:03:05
                       Reject
172.29.0.0/24      *[Direct/0] 00:28:14
                    >  via fxp0.0
172.29.0.1/32      *[Local/0] 00:28:14
                       Local via fxp0.0
172.29.1.0/24      *[Direct/0] 00:28:14
                    >  via fxp0.0
172.29.1.1/32      *[Local/0] 00:28:14
                       Local via fxp0.0
172.29.2.0/24      *[Direct/0] 00:28:14
                    >  via fxp0.0
172.29.2.1/32      *[Local/0] 00:28:14
                       Local via fxp0.0

[edit]
jcluser@vMX6#

vMX1

jcluser@vMX1> show route 172.29.0.0

inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.29.0.0/22      *[OSPF/150] 00:00:41, metric 0, tag 0
                    >  to 10.100.12.2 via ge-0/0/0.0
                       to 10.100.14.2 via ge-0/0/1.0

jcluser@vMX1> ping 172.29.0.1
PING 172.29.0.1 (172.29.0.1): 56 data bytes
^C
--- 172.29.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

jcluser@vMX1> ping 172.29.0.1
PING 172.29.0.1 (172.29.0.1): 56 data bytes
36 bytes from 10.100.26.2: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f16b   0 0000  3f  01 c7ba 10.100.12.1  172.29.0.1

36 bytes from 10.100.26.2: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f194   0 0000  3f  01 c791 10.100.12.1  172.29.0.1

36 bytes from 10.100.26.2: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f1bf   0 0000  3f  01 c766 10.100.12.1  172.29.0.1

^C
--- 172.29.0.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

jcluser@vMX1>

My intention was to drop the entire /22 into the table and have the smaller subnets (the three /32s really) reachable and have everything else rejected, however in doing that I would have to build my /24s on an OSPF interface so that the smaller subnet routes are exported as well. I'm curious as to why this is? I'm attempting to introduce an LSA that advertises an external route, but without the smaller routes. I thought about writing an export policy that rejected the range smaller than /23, but I didn't get a chance to get too far down that rabbit hole, and the end goal as I see it would still be the same, a route to a subnet that for all intents and purposes is unreachable.

Besides advertising a blackhole into a routing table, what's the purpose of all of this? Why would I want to provide a summary if it's never going to be reachable without the smaller routes? How does this decrease the size of the other routers? Obviously I'm missing something here, but I'm not seeing it.

edit I'm confused as to why the question and the first answer (which answers most of my question) were down-voted. Normally on other SE sites I see mods making changes to clarify the question instead of simply down-voting it. Is there a better question I could be asking?

1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Dec 16 '20 at 23:24
1

The aggregate route is useful for reach-ability outside the area or AS where detailed routing information is available for the covered routes.

Inside such an area, the reason aggregates default to reject is so unused addresses -- those which are un-routed -- can generate an ICMP unreachable reply. When someone tries to connect (for example, with TCP) they get an immediate error instead of a lengthy time-out.

1
  • 1
    So inside an area/AS an aggregate is just a larger block that will drop traffic that doesn't have a more specific route So apparently I have more to learn on exporting routes and how those will work with this framework. Jul 28 '20 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.