Training and Certification

 View Only
last person joined: 11 days ago 

How to get the most from Juniper's education services and get advice on your certification journey.

  • 1.  Aggregate / Summary Routes [JNCIS-SP]

    Posted 07-19-2021 11:37
    Hey guys - studying for my JNCIS-SP again, and hoping someone can clarify some of 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.



    ------------------------------
    THOMAS SCOTT
    ------------------------------


  • 2.  RE: Aggregate / Summary Routes [JNCIS-SP]

    Posted 07-19-2021 12:42
    Edited by Fred Glauser 07-19-2021 12:42

    Hi Tomas, good question.

    The box that is producing the aggregate route(vMX6 in your case) is the only device that will have the reject listed with the route, neighboring routers will have vMX6 as the next hop instead.  The reason for the reject on the originating router is because the originating router should never use the aggregate route, it should always use a more specific contributing route and route to reject if it didn't have one.  If you think about ip routing rules, we always look for the longest match which would mean a contributing route would be used, if you don't have a contributing route working on the originating router, where would an aggregate route take you? 

    The reduction in routing table size is for all other routers, not the originating one.

    I am not sure what your topology looks like to explain why the ping isn't working.

    Hope that helps


    ------------------------------
    Fred Glauser
    ------------------------------

    Original Message