1

I have an issue when I try to configure several ip addresses on the loopback interface on a vSRX cluster.

Here is my setup (in gns3) :

enter image description here

vSRX-1 and 2 are in cluster mode. VyOS-1 and 2 are BGP routers miming our actual ISP. Each vSRX have active BGP session with the corresponding VyOS router; this setup is for redundancy only (no load balancing). vSRX-1 and VyOS-1 share a /30 network and vSRX-2/VyOS-2 share another /30.

Our ISP gave us a private as number and we announce a /28 network via BGP.

Concerning our cluster setup :

As reth interface can be active on only one node at a time, WAN interfaces are non-reth. LAN interfaces are in redundancy groups.

Some public IP need to be hosted on vSRX (for destination nat and VPN), as WAN interfaces are non-consistent in case of failure, I need to set public IP addresses on the loopback interface.

Here comes the issue.

If I try the following setup

# show interfaces lo0        
unit 0 {
    family inet {
        address X.X.6.97/28;
        address X.X.6.98/32;
    }
}

Commit fails with the following error:

# commit 
error: Overlapping subnet is configred under lo0
[edit interfaces lo0 unit 0 family inet]
  'address X.X.6.98/32'
     Overlapping subnet is configured 
error: configuration check-out failed

And if I try the following configuration

# show interfaces lo0 
unit 0 {
    family inet {
        address X.X.6.97/28;
        address X.X.6.98/28;
    }
}

The route is correctly mounted but lo0 has only one IP:

# run show route
[..]
X.X.6.96/28    *[Direct/0] 16:56:19
                    > via lo0.0
X.X.6.97/32    *[Local/0] 16:56:19
                      Local via lo0.0
[..]
# run show interfaces lo0.0 terse           
Interface               Admin Link Proto    Local                 Remote
lo0.0                   up    up   inet     X.X.6.97/28 

And if I try:

# show interfaces lo0 
unit 0 {
    family inet {
        address X.X.6.97/32;
        address X.X.6.98/32;
    }
}

lo0.0 has both IP but the route to X.X.6.96/28 is missing (and thus, not propagated by BGP) :

# run show interfaces lo0.0 terse   
Interface               Admin Link Proto    Local                 Remote
lo0.0                   up    up   inet     X.X.6.97        --> 0/0
                                            X.X.6.98        --> 0/0
# run show route  
[..]
X.X.6.97/32    *[Direct/0] 00:01:43
                    > via lo0.0
X.X.6.98/32    *[Direct/0] 00:01:43
                    > via lo0.0
[..]

Any idea of what am I doing wrong ?

Does the cluster design look good to you ?

Update. BGP config:

set routing-options autonomous-system 65000
set protocols bgp log-updown
set protocols bgp group PEER-PRIMARY type external
set protocols bgp group PEER-PRIMARY description "Peer primary"
set protocols bgp group PEER-PRIMARY log-updown
set protocols bgp group PEER-PRIMARY export PEER-PRIMARY-OUT
set protocols bgp group PEER-PRIMARY peer-as XX1
set protocols bgp group PEER-PRIMARY neighbor X.X.X.8 import PEER-PRIMARY-IN
set protocols bgp group PEER-SECONDARY type external
set protocols bgp group PEER-SECONDARY description "Peer secondary"
set protocols bgp group PEER-SECONDARY log-updown
set protocols bgp group PEER-SECONDARY export PEER-SECONDARY-OUT
set protocols bgp group PEER-SECONDARY peer-as XX1
set protocols bgp group PEER-SECONDARY neighbor X.X.X.4 import PEER-SECONDARY-IN
set policy-options prefix-list BGP-LAN X.X.6.96/28
set policy-options policy-statement PEER-PRIMARY-IN term DEFAULT then local-preference 100
set policy-options policy-statement PEER-PRIMARY-IN term DEFAULT then accept
set policy-options policy-statement PEER-PRIMARY-IN then reject
set policy-options policy-statement PEER-PRIMARY-OUT term LAN from prefix-list BGP-LAN
set policy-options policy-statement PEER-PRIMARY-OUT term LAN then accept
set policy-options policy-statement PEER-PRIMARY-OUT then reject
set policy-options policy-statement PEER-SECONDARY-IN term DEFAULT then local-preference 50
set policy-options policy-statement PEER-SECONDARY-IN term DEFAULT then accept
set policy-options policy-statement PEER-SECONDARY-IN then reject
set policy-options policy-statement PEER-SECONDARY-OUT term LAN from prefix-list BGP-LAN
set policy-options policy-statement PEER-SECONDARY-OUT term LAN then as-path-prepend 65000
set policy-options policy-statement PEER-SECONDARY-OUT term LAN then accept
set policy-options policy-statement PEER-SECONDARY-OUT then reject

Update 2. address ordering

As suggested by @Cown and described in https://forums.juniper.net/t5/SRX-Services-Gateway/Multiple-IP-s-on-the-loopback-interface-not-working/m-p/249710#M30768 IP ordering in interface lo0.0 doesn't work for me in vSRX 15.1X49-D80.4

# show interfaces lo0 unit 0 
family inet {
    address X.X.6.98/28;
    address X.X.6.97/32;
}
# commit
error: Overlapping subnet is configred under lo0
[edit interfaces lo0 unit 0 family inet]
  'address X.X.6.97/32'
     Overlapping subnet is configured 
error: configuration check-out failed
7
  • address X.X.6.97/28; and address X.X.6.98/32; are in the same subnet and overlapping each other, that's why you cannot commit. x.x.6.98 is a network address under the x.x.6.97/28 subnet, the network spans from x.x.6.97-110. – user36472 Jul 21 '17 at 9:34
  • You need to use: # show interfaces lo0 unit 0 { family inet { address X.X.6.97/28; address X.X.6.98/28; } } x.x.6.97 and x.x.6.98 is announced via X.X.6.96/28 because they are part of that subnet. – user36472 Jul 21 '17 at 9:41
  • @Cown thanks for your comments. I already tryed to put .97/28 and .98/28 but in that case, lo0.0 get only .97/28 and .98/28 is ignored. (see my post, 2nd case) – PierreEmile Jul 21 '17 at 9:58
  • Could you post the full BGP configuration? – user36472 Jul 21 '17 at 10:29
  • What is the task you're trying to solve? If you just want to announce /28, then simply make /28 static route with discard keyword and use two /32 for loopback. – ar_ Jul 21 '17 at 13:16
1

Thanks to @ar_ the solution is :

  • configure ip addresses on lo0.0 with /32 mask
  • set a discarded static route to /28 (network will then be propagated by BGP)

To go further :

  • add lo0.0 in untrust zone
  • set an intra-zone policy to allow 'external' traffic (ex. ping) since lo0.0 won't be the incoming traffic interface.
# show interfaces lo0 
unit 0 {
    family inet {
        address X.X.6.97/32;
        address X.X.6.98/32;
    }
}
# show routing-options 
static {
    route X.X.6.96/28 discard;
}
[ยทยท]
# show security zones security-zone untrust 
[..]
interfaces {
    ge-0/0/0.0 {
        host-inbound-traffic {
            system-services {
                ping;
            }
        }
    }
    ge-7/0/0.0 {
        host-inbound-traffic {
            system-services {
                ping;
            }
        }
    }
    lo0.0 {
        host-inbound-traffic {
            system-services {
                ping;                   
            }
        }
    }
}
# show security policies from-zone untrust to-zone untrust 
policy permit-ping {
    match {
        source-address any;
        destination-address any;
        application junos-ping;
    }
    then {
        permit;
    }
}
1
  • Great, i'm happy you got it working. That solution seems a lot better. :-) – user36472 Jul 21 '17 at 16:57

Your Answer

By clicking โ€œPost Your Answerโ€, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.