Running Juniper SRX device.
Within a routing-instance, I removed two /25 static routes and replaced it with a single /24 static route. This /24 static route starts on the same IP, just a bigger subnet. Note that 172.18.10.10 is a blackhole; 10.10.201.128/25 is NOT being used yet.
Config for routing-instance A:
[omitted]
routing-options {
static {
inactive: route 10.212.17.0/24 next-hop 10.212.210.17;
route 10.10.200.0/25 next-hop 172.18.10.2;
route 10.10.201.0/25 next-hop 172.18.10.6;
route 10.10.201.128/25 next-hop 172.18.10.10;
}
[omitted]
New config for routing-instance A:
[omitted]
routing-options {
static {
inactive: route 10.212.17.0/24 next-hop 10.212.210.17;
route 10.10.200.0/25 next-hop 172.18.10.2;
route 10.10.201.0/24 next-hop 172.18.10.6;
}
[omitted]
After making this change, I can no longer route from some places (but not all) to 10.10.201.0/25 hosts. At first I thought this might be caused by a summarization issue, but then I realized that two other random networks within the same routing instance (let us call it routing instance B) and on the same router (not going through ebgp connections from other sites) do not have similar behavior. Specifically, 10.212.200.0/24 cannot reach 10.10.201.0/25, but 10.212.203.0/24 can. Again, both 10.212.200/24 and 10.212.203/24 are coming from the same routing instance on the same physical router.
So...I checked the security flow to look at the traffic, and I found that traffic was able to route from 10.10.201.0/25 to the appropriate hosts, however some hosts were unable to respond with an echo response:
Session ID: 6726, **Policy name: HQ-VPN-DMZ_To_Trust**/30, Timeout: 2, Valid
In: 10.10.201.3/152 --> 10.212.200.1/63851;icmp, If: ge-0/0/7.0, Pkts: 1, Bytes: **84**
Out: 10.212.200.1/63851 --> 10.10.201.3/152;icmp, If: ge-0/0/4.0, Pkts: 0, Bytes: **0**
So...I checked the policy hit-count, and saw that the hit-count was increasing. The policy is listed below:
policy HQ-VPN-DMZ_To_Trust {
match {
source-address [ *omitted* 10.212.210.18/32 10.10.201.0/25 ];
destination-address any;
application any;
}
then {
permit;
}
Since the source IP is 10.10.201.3, the policy hit-counter should NOT have been increasing.
My question is: How is it possible that the policy was blocking that return echo response from 10.212.200.1 -> 10.10.201.3, when it is clearly permitted?
Also:
I should note that when I added the specific static route...
[omitted]
routing-options {
static {
inactive: route 10.212.17.0/24 next-hop 10.212.210.17;
route 10.10.200.0/25 next-hop 172.18.10.2;
route 10.10.201.0/24 next-hop 172.18.10.6;
route 10.10.201.0/25 next-hop 172.18.10.6;
}
[omitted]
...back into the routing-instance config, everything started working again.
Since we are on this topic, how is it possible that 10.10.201.0/25 static route would work, but 10.10.201.0/24 static route would not work? 10.10.201.0/25 is summarized within 10.10.201.0/24!!!
The show route output differences are shown below (one with the /25 in, and one with the /24 in):
With /24:
x@x> show route 10.10.201.0
inet.0: 919 destinations, 1825 routes (919 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/80] 18w6d 22:42:17, localpref 100
AS path: YYYY AAAA I
> to 104.x.x.x via ge-0/0/0.0
[BGP/80] 7w4d 10:38:07, localpref 50, from 10.99.1.23
AS path: YYYY BBBB I
> to 10.99.1.2 via ge-0/0/15.0
[OSPF/150] 14w5d 02:01:25, metric 1, tag 0
> to 10.99.1.2 via ge-0/0/15.0
DMZ.inet.0: 101 destinations, 101 routes (101 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.201.0/24 *[Static/5] 00:49:33
> to 172.18.10.6 via ge-0/0/7.0
tunnel.inet.0: 90 destinations, 113 routes (73 active, 0 holddown, 25 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/80] 18w6d 22:42:17, localpref 100
AS path: YYYY AAAA I
> to 104.x.x.x via ge-0/0/0.0
lan-vr.inet.0: 58 destinations, 83 routes (58 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/80] 18w6d 22:42:17, localpref 100
AS path: YYYY AAAA I
> to 104.x.x.x via ge-0/0/0.0
[OSPF/150] 7w4d 10:38:06, metric 0, tag 0
> to 10.212.6.20 via ge-0/0/1.0
With /25:
x@x# run show route 10.10.201.0
inet.0: 921 destinations, 1829 routes (921 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.201.0/25 *[Static/5] 01:04:04
> to 172.18.10.6 via ge-0/0/7.0
[OSPF/150] 01:04:02, metric 1, tag 0
> to 10.99.1.2 via ge-0/0/15.0
DMZ.inet.0: 102 destinations, 102 routes (102 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.201.0/25 *[Static/5] 01:04:06
> to 172.18.10.6 via ge-0/0/7.0
tunnel.inet.0: 91 destinations, 114 routes (74 active, 0 holddown, 25 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.201.0/25 *[Static/5] 01:04:04
> to 172.18.10.6 via ge-0/0/7.0
lan-vr.inet.0: 59 destinations, 84 routes (59 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.201.0/25 *[Static/5] 01:04:04
> to 172.18.10.6 via ge-0/0/7.0