Quantcast
Channel: All SRX Services Gateway posts
Viewing all articles
Browse latest Browse all 17645

Re: OpenVpn issue with rerouting interfaces

$
0
0

Dimi,


Based on the configuration, reth2.110 and reth2.150 are not configured under any custom routing-instances so they will be configured by default under the Master/Default routing-instance (inet.0).


If a packet destined to 1.1.1.1 comes in to reth2.110, the inet.0 routing-table will be checked and based on the provided information the route from inet.0 is the following:

 

show route 1.1.1.1 detail

inet.0: 144 destinations, 150 routes (143 active, 0 holddown, 1 hidden)
0.0.0.0/0 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 262142
                Address: 0x150e4d8
                Next-hop reference count: 3
                Next hop: a.a.a.a via reth2.2222
                Session Id: 0x4dNext hop: via pp0.0
                Session Id: 0x0Next hop: via pp0.1
                Session Id: 0x0Next hop: via pp0.2, selected
                Session Id: 0x0Next hop: via pp0.4
                Session Id: 0x0Next hop: via pp0.3
                Session Id: 0x0Next hop: b.b.b.b via reth2.2211
                Session Id: 0x79Next hop: via pp0.5
                Session Id: 0x0 Next hop: 2.2.2.193 via reth2.150
                Session Id: 0x7f
                State: <Active Int Ext>
                Age: 76w6d 15:55:06
                Validation State: unverified
                Task: RT
                Announcement bits (2): 0-KRT 2-Resolve tree 1
                AS path: I

 

I can see diferent next-hops showing up and I would like to confirm if this is expected. Can you share the configuration of that default route under [edit routing-options static].


When we configure multiple next-hops for a route, without specifying any preference/prioritization between them, they will all have the same chances to be elected as the next-hop for that route. Actually Junos does the next-hop selection randomly, so at any given time reth2.150 can be the next-hop and out of the sudden we could see pp0.4 interface showing as the next-hop, because it is equally preferable as reth2.150. I believe this is the root cause of your issue.


I could think of three possible scenarios here:


1. You have the incorrect configuration and you only need reth2.150 as the next-hop for your default-route.


2. You might want to use "qualified next-hop" feature in order to have multiple next-hops, different than reth2.150, but have them as backup in case reth2.150 fails:

 

     https://www.juniper.net/documentation/en_US/junos/topics/concept/routing-protocol-static-security-route-preference-and-qualified-next-hop-understanding.html

 

3. You are trying to configure load-balance among all those next-hops. In that case you will need to load balance per flow (even though the command says per-packet it works per flow):

 

     https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ecmp-flow-based.html

 

I hope this helps


Viewing all articles
Browse latest Browse all 17645


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>