Junos Aggregate Routes
Topology#
graph LR
net1(LAN1_172.17.99.0/24)
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4
Configuration and Analysis#
The default next hop of an aggregate route is reject:
root@R4> show configuration routing-options rib inet.0 aggregate
defaults {
preference 189;
}
route 10.22.1.0/26;
root@R4>
root@R4> show route protocol aggregate
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/26 *[Aggregate/189] 00:00:58
Reject
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R4>
root@R4> show route 10.22.1.0/26 exact detail
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
10.22.1.0/26 (1 entry, 1 announced)
*Aggregate Preference: 189
Next hop type: Reject, Next hop index: 0
Address: 0x77c5434
Next-hop reference count: 2
Kernel Table Id: 0
State: <Active Int Ext>
Local AS: 22
Age: 7:22
Validation State: unverified
Task: Aggregate
Announcement bits (2): 0-KRT 5-Resolve tree 3
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 2
Contributing Routes (2):
10.22.1.0/27 proto Direct
10.22.1.32/27 proto Static
Thread: junos-main
root@R4>
#LessonLearned The contributing routes may be of different routing protocols or pseudoprotocols.
Advertising the Aggregate Route instead of the contributing Routes#
I am going to export the aggregate route 10.22.1.0/26 from the RIB into BGP toward R1, instead of the contributing route 10.22.1.0/27.
Existing config:
root@R4> show configuration policy-options
policy-statement LAN-segments {
term LAN10.22 {
from {
route-filter 10.22.1.0/27 exact;
}
then {
community add AS22-PREFER;
accept;
}
}
}
policy-statement R4-loopback {
term r4-lo-addr {
from {
route-filter 4.4.4.4/32 exact;
}
then accept;
}
}
community AS22-PREFER members 22:200;
root@R4> show configuration protocols bgp
group ebgp-peerz {
type external;
export [ R4-loopback LAN-segments ];
peer-as 17;
neighbor 10.10.10.9;
}
group internPeers {
type internal;
traceoptions {
file BGPdebugWassim;
}
local-address 4.4.4.4;
peer-as 22;
neighbor 2.2.2.2;
}
root@R4>
I modified the policy-statement config to include the aggregate route prefix instead of the contributing route prefix:
root@R4> show configuration policy-options policy-statement LAN-segments
term LAN10.22 {
from {
route-filter 10.22.1.0/26 exact;
}
then {
community add AS22-PREFER;
accept;
}
}
I made sure that the aggregate route is active:
root@R4> show route 10.22.1.0/26
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/26 *[Aggregate/189] 14:36:45
Reject
10.22.1.0/27 *[Direct/0] 3w2d 23:41:02
> via ge-0/0/3.0
10.22.1.4/32 *[Local/0] 3w2d 23:41:02
Local via ge-0/0/3.0
10.22.1.32/27 *[Static/181] 3d 00:43:04
> to 10.22.1.2 via ge-0/0/3.0
I check in the BGP config whether the policy-statement is called out in the export direction:
root@R4> show configuration protocols bgp group ebgp-peerz
type external;
export [ R4-loopback LAN-segments ];
peer-as 17;
neighbor 10.10.10.9;
root@R4>
I check which BGP routes R4 is advertising toward R1:
root@R4> show route advertising-protocol bgp 10.10.10.9
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 4.4.4.4/32 Self I
* 10.22.1.0/26 Self I
root@R4>
On R1, I check what it is receiving from R4 in BGP:
root@R1> show route receive-protocol bgp 10.10.10.10
inet.0: 16 destinations, 16 routes (13 active, 0 holddown, 3 hidden)
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R1>
Nothing. So I check the policies referenced in the BGP config.
root@R1> show configuration protocols bgp group extGrp-22
type external;
import ModifyBGPattr;
export [ PREPEND-EXPORT LAN172.17.99 ];
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.10;
root@R1>
root@R1> show configuration policy-options policy-statement ModifyBGPattr
term modLocalPref {
from {
protocol bgp;
community From-R4;
route-filter 10.22.1.0/27 exact;
}
then {
local-preference 200;
accept;
}
}
term OtherRoutes {
then reject;
}
root@R1>
The poliy-statement matches on exactly 10.22.1.0/27, which is the contributing route to 10.22.1.0/26. But R4 is advertising only the aggregate route version of 10.22.1.0. I adapt the config and verify the received BGP routes on R1:
[edit]
root@R1# ...icy-statement ModifyBGPattr term modLocalPref
[edit policy-options policy-statement ModifyBGPattr term modLocalPref]
root@R1# show
from {
protocol bgp;
community From-R4;
route-filter 10.22.1.0/27 exact;
}
then {
local-preference 200;
accept;
}
[edit policy-options policy-statement ModifyBGPattr term modLocalPref]
root@R1# edit from
[edit policy-options policy-statement ModifyBGPattr term modLocalPref from]
root@R1# rename route-filter 10.22.1.0/27 exact to route-filter 10.22.1.0/26 exact
[edit policy-options policy-statement ModifyBGPattr term modLocalPref from]
root@R1#
[edit policy-options policy-statement ModifyBGPattr term modLocalPref from]
root@R1# up
[edit policy-options policy-statement ModifyBGPattr term modLocalPref]
root@R1# show
from {
protocol bgp;
community From-R4;
route-filter 10.22.1.0/26 exact;
}
then {
local-preference 200;
accept;
}
[edit policy-options policy-statement ModifyBGPattr term modLocalPref]
root@R1# commit check
configuration check succeeds
[edit policy-options policy-statement ModifyBGPattr term modLocalPref]
root@R1# commit and-quit
commit complete
Exiting configuration mode
root@R1> show route receive-protocol bgp 10.10.10.10
inet.0: 16 destinations, 16 routes (14 active, 0 holddown, 2 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.22.1.0/26 10.10.10.10 22 I
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R1>
And that is the only route that R1 receives to reach the prefix 10.22.1.0:
root@R1> show route 10.22.1.0
inet.0: 16 destinations, 16 routes (14 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/26 *[BGP/170] 00:02:28, localpref 200
AS path: 22 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/4.0
root@R1>
root@R1> ping 10.22.1.34 source 1.1.1.1
PING 10.22.1.34 (10.22.1.34): 56 data bytes
64 bytes from 10.22.1.34: icmp_seq=0 ttl=64 time=2.579 ms
64 bytes from 10.22.1.34: icmp_seq=1 ttl=64 time=2.929 ms
^C
--- 10.22.1.34 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.579/2.754/2.929/0.175 ms
root@R1>
Acquired skills in this blog#
- configuring an aggregate route in the Junos routing table
inet.0, given existing contributing routes - setting defaults for an aggregate route
- exporting an aggregate route from RIB to BGP toward a BGP group
- verifying the existence of the aggregate route
- verifying that the default next hop of an aggregate route is
reject
Open Topics#
reject vs discard in the next hop value of the aggregate route#
Assumption#
R4 exported an aggregate route from RIB to BGP. R1 successfully imported it from BGP into RIB. The aggregate route is correctly configured on R4 with the default next hop value of reject.
Expected Observables#
When R1’s loopback pings a non-existing destination in the IP range of the received aggregate route, R1 receives ICMP messages of unreachability.
Observed Reality#
#TBC A ping on R1 to a non-existing destination in the IP range of the received aggregate route does not show ICMP messages of unreachability.