Noted for your explanation. Now it more clear to me.
Original Message:
Sent: 03-27-2024 13:35
From: Nikolay Semov
Subject: MNHA SRX Cluster question?
Those are not intended to be advertised to peers. They're only significant locally to the SRX where these routes exist. They only control actions in the policy-statement defined on the SRX.
In fact, it would probably be bad to advertise them to peers. If SRX1 advertises 10.99.1.1/32 and that is received by SRX2 then the route 10.99.1.1/32 will exist in SRX2 which will then affect its routing policies. Same for 10.99.1.2/32. You certainly wouldn't want one SRX to receive the signal routes from the other SRX, at least not in this example topology listed in the article.
If I recall correctly, the policies defined in the example config only export static and direct routes to BGP. I'm not sure what type the signal routes have.
------------------------------
Nikolay Semov
Original Message:
Sent: 03-27-2024 13:00
From: kronicklez
Subject: MNHA SRX Cluster question?
Hi Nikolav,
I referring route 10.39.1.1 and 10.39.1.2. The config i will share later. But my setup is follow exact like juniper vLAB that create by juniper itself under US-DEMOLAB.
Thanks
Original Message:
Sent: 03-27-2024 12:54
From: Nikolay Semov
Subject: MNHA SRX Cluster question?
What is the route you're referring to that's not being received by upstream or downstream? Please share config, too, if you can.
------------------------------
Nikolay Semov
Original Message:
Sent: 03-27-2024 12:36
From: kronicklez
Subject: MNHA SRX Cluster question?
Hi Nikolay,
First of all i'm very appreciate your explanation and opinion.
It make make sense what u explain. As far i'm understanding to advertise the route then that route need to be active first. But i try replicate in virtual lab and not see that route received by upstream or downstream. Even when do show route advertise protocol bgp i;m also not see that route advertise. So that's make me confuse because in the url use word "advertise". The failover i'm simulate look good. Even in the doc not state anything what will be happen if that route duplicate with another route that received from other router.
Thanks
Original Message:
Sent: 03-26-2024 23:38
From: Nikolay Semov
Subject: MNHA SRX Cluster question?
Correct. In fact, it must NOT be configured on any interface. If you have it configured on an interface, then the route will be active whenever the interface is up, and it won't work properly.
I wasn't able to find documentation specifically explaining active-signal-route and backup-signal-route, unfortunately.
In my opinion, the documentation is confusing because they tell you to configure these things and without first telling you what the premise is.
In their example the premise is that you want traffic to flow through the active firewall primarily and through the backup firewall in case of failure. But you don't know which firewall is primary and which one is backup at any given time. You need to tell your BGP peers somehow which of the two firewalls to prefer sending traffic to.
So, IF a firewall is active, it should list a lower MED (metric) -- 10 -- on routes it advertises to its BGP neighbors.
And, IF a firewall is backup, it should list a higher MED (metric) -- 20 -- on routes it advertises to its BGP neighbors.
(BGP prefers routes with lower MED.)
But how would BGP on the SRX know whether SRX is active or backup? The BGP process has no idea. It just looks at a policy-statement what to advertise and with what metric. But how would a policy-statement know whether SRX is active or backup? It, too, doesn't know. All it can do is evaluate a bunch of rules (terms) with conditions and actions. One of the conditions is defined as whether route to 10.39.1.1/32 exists. The policy-statement doesn't assign any particular meaning to 10.39.1.1 or 10.39.1.2. All it does is check if routes to those IPs exists.
Finally, this High Availability feature is very much aware whether the firewall is active or backup. The active-signal-route tells the feature to install a route to 10.39.1.1/32 going to nowhere into the routing table. The High Availability feature doesn't care who use the route and how. It doesn't care it's used for BGP in this case. If just installs the configured signal route and that's it. Other features can use that as they see fit. If you wanted to, you could do something crazy like propagate that signal route into OSPF or BGP in your internal network or read it from some monitoring system that participates in your network's routing.
------------------------------
Nikolay Semov
Original Message:
Sent: 03-26-2024 21:57
From: kronicklez
Subject: MNHA SRX Cluster question?
Hi Nikolav,
Many thanks your explanation. Please correct me if i wrong. You means the summary that ip address it just dummy ip address even that ip address not exists in existing routing table or that ip not configured at any interface in the MNHA firewall correct? I read that url also but not see related explanation detail ip address for "active-signal-route" or may be i'm miss somewhere.
Based on snapshot below from url, when it says "advertise", is it means that ip need to advertise to upstream / downstream or just between MNHA1 to MNHA2 only?
"In this step, the active SRX Series Firewall creates the route with IP address 10.39.1.1 and the backup SRX Series Firewall creates the route with IP address 10.39.1.2 depending on the configuration. In this example, the policy on the SRX-1 matches on 10.39.1.1 (since its active) and advertises static/direct routes with a metric 10 making it preferred. The policy on SRX-2 matches on 10.39.1.2 (since its backup) and advertises static/direct routes with a metric 20 making it less preferred.
The active signal route IP address you assign is used for route preference advertisement. You must specify the active signal route along with the route-exists policy in the policy-options statement."
Thanks and appreciate your confirmation.
Original Message:
Sent: 03-26-2024 13:19
From: Nikolay Semov
Subject: MNHA SRX Cluster question?
10.39.1.1 and 10.39.1.2 are just two examples but they can be any addresses that you're not using anywhere else on your network. They are just flags.
If the firewall is active in a high availability group, it will install 10.39.1.1 (the active-signal-route) into the routing table. If it's backup, it will install 10.39.1.2 in the routing table. The destination for those routes doesn't matter; those IP addresses don't have to be assigned to any particular device anywhere (in fact, they probably shouldn't be). What's important is whether they're present in the routing table or not.
The reason that's important is because you can define conditions (under policy-options) that return true of false depending on whether a route is present or not. You can then use those conditions in a policy-statement to control your routing.
There's also a failure flag you can use too:
https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/example/mnha-configuration-example.html
These new features basically use the routing table as a bridge to exchange information with old features. Instead of adding capabilities into policy-statements to check whether the firewall is active or back in a high availability group, the policy-statement feature remains unchanged, with the ability to check whether routes exist. And the new HA feature is given the ability to install routes that report its state.
------------------------------
Nikolay Semov
Original Message:
Sent: 03-26-2024 04:29
From: kronicklez
Subject: MNHA SRX Cluster question?
Hi All,
Based on this url https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic-map/mnha-asymmetric-route-support.html , is it someone can explain to me the prefix 10.39.1.1/32 & 10.39.1.2/32 refer to which ip?
Thanks and appreciate any feedback