SRX

Hi,

I realise this is a copy of my last question, but that's because I now have 2 working LNS and can concentrate on this ISIS issue...

So, on the last question, the last recommendation was to create a policy. Here is the configuration I have on the SRX currently and as far as I can see should work:

set routing-instances Customer-VR instance-type virtual-router
set routing-instances Customer-VR interface ae2.0
set routing-instances Customer-VR interface lo0.10
set routing-instances Customer-VR protocols isis level 1 authentication-key "$9$iHfz9Cu1Eyp0yKWxwsZUjHP5z36AuO"
set routing-instances Customer-VR protocols isis level 1 authentication-type md5
set routing-instances Customer-VR protocols isis level 2 authentication-key "$9$3DmzntOhclMLNreNbYoji5QFnApO1RSlK"
set routing-instances Customer-VR protocols isis level 2 authentication-type md5
set routing-instances Customer-VR protocols isis interface ae2.0
set routing-instances Customer-VR protocols isis interface lo0.10

set routing-instances NineGroup-VR instance-type virtual-router
set routing-instances NineGroup-VR interface ge-0/0/2.0
set routing-instances NineGroup-VR interface lo0.20
set routing-instances NineGroup-VR protocols isis export from_customer_to_ninegroup
set routing-instances NineGroup-VR protocols isis level 1 authentication-key "$9$kqT3AtORcl0BlMLNY2UjHq5Q369pO1"
set routing-instances NineGroup-VR protocols isis level 1 authentication-type md5
set routing-instances NineGroup-VR protocols isis level 2 authentication-key "$9$5T6AB1hrK8Ec87dsJZqmfTn/Ap0IhS"
set routing-instances NineGroup-VR protocols isis level 2 authentication-type md5
set routing-instances NineGroup-VR protocols isis interface ge-0/0/2.0
set routing-instances NineGroup-VR protocols isis interface lo0.20

set interfaces lo0 unit 0 family inet address 195.80.0.6/32
set interfaces lo0 unit 0 family iso address 49.0001.1950.0080.0006.00
set interfaces lo0 unit 0 family inet6 address 2a05:d840:001c:ffff:ffff:ffff:0000:0001/128
set interfaces lo0 unit 10 family iso address 49.0001.1950.0080.0026.00
set interfaces lo0 unit 20 family iso address 49.0001.1950.0080.0016.00

set interfaces ae2 unit 0 description To-HEX-CORE-02-ae2
set interfaces ae2 unit 0 family inet address 195.80.0.33/30
set interfaces ae2 unit 0 family iso
set interfaces ae2 unit 0 family inet6 address 2a05:d840:0048:ffff:ffff:ffff:0000:0002/127

set interfaces ge-0/0/2 unit 0 description To-HEX-RADIUS-SERVER
set interfaces ge-0/0/2 unit 0 family inet address 195.80.0.53/30
set interfaces ge-0/0/2 unit 0 family iso
set interfaces ge-0/0/2 unit 0 family inet6 address 2a05:d840:004d:ffff:ffff:ffff:0000:0001/127

set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest match source-address any
set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest match destination-address any
set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest match application any
set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest then permit
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 match source-address any
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 match destination-address any
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 match application any
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 then permit
set security zones security-zone NineGroup-DMZ host-inbound-traffic system-services all
set security zones security-zone NineGroup-DMZ host-inbound-traffic protocols all
set security zones security-zone NineGroup-DMZ interfaces ge-0/0/2.0
set security zones security-zone Customer-Network host-inbound-traffic system-services all
set security zones security-zone Customer-Network host-inbound-traffic protocols all
set security zones security-zone Customer-Network interfaces ae2.0

I also created a policy-statment as follows and placed within the NineGroup-VR:

set policy-options policy-statement from_customer_to_ninegroup term 1 from rib Customer-VR.inet.0

set policy-options policy-statement from_customer_to_ninegroup term 1 then accept

set routing-instance NineGroup-VR protocols isis export from_cusotmer_to_ninegroup

This makes no difference at all. I have also tried with the interface as the "from" and also the "protocol" as the from, all with no success....

I am really stuck on this and you guys are my last resort as I really cannot find anything, even on the Juniper Website, with how to complete this...

Thank you

Hi

Could anyone point in me in a direction that will make this work please?

I have tried all the recommendations with no success at all.

Thank you

Hi Folks,

I did some quick testing in lab and please find my suggestions,

In my case, I have 2 VR in r2, and I have created rib-groups vr1vr2 and vr2vr1 to leak advertise routes between the two VR.

              I1.24                   I2.43
 +-----+         +--+--+I1.23    +--+--+         +-----+
 + R1  |I1.12    | R2  +---------+ R3  |I1.35    | R5  +
 | PE1 +---------+ P1  |         | P2  +---------+ PE2 |
 +-----+    I2.12+--+--+    I2.23+--+--+    I2.35+-----+
                     I1.27            I2.73        LHR

labroot@re0_re0:r2> show configuration routing-instances | display set

set logical-systems r2 routing-instances vr1 instance-type virtual-router

set logical-systems r2 routing-instances vr1 interface ge-0/0/1.12

set logical-systems r2 routing-instances vr1 interface lo0.1000

set logical-systems r2 routing-instances vr1 routing-options interface-routes rib-group inet vr1vr2

set logical-systems r2 routing-instances vr1 protocols ospf rib-group vr1vr2

set logical-systems r2 routing-instances vr1 protocols ospf area 0.0.0.0 interface all

set logical-systems r2 routing-instances vr2 instance-type virtual-router

set logical-systems r2 routing-instances vr2 interface ge-0/0/0.23

set logical-systems r2 routing-instances vr2 interface lo0.2000

set logical-systems r2 routing-instances vr2 routing-options interface-routes rib-group inet vr2vr1

set logical-systems r2 routing-instances vr2 protocols ospf rib-group vr2vr1

set logical-systems r2 routing-instances vr2 protocols ospf export fromrib

set logical-systems r2 routing-instances vr2 protocols ospf import ospfimport

set logical-systems r2 routing-instances vr2 protocols ospf area 0.0.0.0 interface all

labroot@re0_re0:r2> show route table vr2 192.168.1.101/32 extensive

vr2.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

192.168.1.101/32 (1 entry, 1 announced)

TSI:

KRT in-kernel 192.168.1.101/32 -> {1.1.12.1}

OSPF area : 0.0.0.0, LSA ID : 192.168.1.101, LSA type : Extern

        *OSPF   Preference: 10

                Next hop type: Router, Next hop index: 996

                Address: 0x97f03d0

                Next-hop reference count: 4

                Next hop: 1.1.12.1 via ge-0/0/1.12, selected

                Session Id: 0x197

                State: <Secondary Active Int>

                Age: 36:04      Metric: 1

                Validation State: unverified

                Area: 0.0.0.0

                Task: vr1-OSPF

                Announcement bits (2): 0-KRT 1-vr2-OSPF ///// advertised to ospf with the help of fromrib

                 AS path: I

                Primary Routing Table vr1.inet.0

labroot@re0_re0:r2>

labroot@re0_re0:r2> show route table vr2 192.168.1.103/32 extensive   

vr2.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

192.168.1.103/32 (1 entry, 1 announced)

TSI:

KRT in-kernel 192.168.1.103/32 -> {1.1.23.2}

        *OSPF   Preference: 10

                Next hop type: Router, Next hop index: 995

                Address: 0x97f0560

                Next-hop reference count: 20

                Next hop: 1.1.23.2 via ge-0/0/0.23, selected

                Session Id: 0x198

                State: <Active Int>

                Age: 2:08:41    Metric: 1

                Validation State: unverified

                Area: 0.0.0.0

                Task: vr2-OSPF

                Announcement bits (1): 0-KRT //// by default this route is not advertised

                AS path: I

                Secondary Tables: vr1.inet.0

labroot@re0_re0:r2>

In order to advertise the routes leaked, I used the below export policy in ospf,

labroot@re0_re0:r2> ...nfiguration policy-options policy-statement fromrib | display set   

set logical-systems r2 policy-options policy-statement fromrib term 1 from rib vr2.inet.0

set logical-systems r2 policy-options policy-statement fromrib term 1 then accept

labroot@re0_re0:r2>

Next Action Plan

----------------

Change the configured policy as below and let me know the behavior,

set policy-options policy-statement from_customer_to_ninegroup term 1 from rib NineGroup-VR.inet.0

set policy-options policy-statement from_customer_to_ninegroup term 1 then accept

set routing-instance NineGroup-VR protocols isis export from_cusotmer_to_ninegroup

My device config just for your reference...

labroot@re0_re0:r2> show configuration | display set
set logical-systems r2 interfaces ge-0/0/0 unit 23 vlan-id 23
set logical-systems r2 interfaces ge-0/0/0 unit 23 family inet address 1.1.23.1/30
set logical-systems r2 interfaces ge-0/0/0 unit 23 family mpls
set logical-systems r2 interfaces ge-0/0/1 unit 12 vlan-id 12
set logical-systems r2 interfaces ge-0/0/1 unit 12 family inet address 1.1.12.2/30
set logical-systems r2 interfaces ge-0/0/1 unit 12 family mpls
set logical-systems r2 interfaces lo0 unit 102 family inet address 192.168.1.102/32
set logical-systems r2 interfaces lo0 unit 1000 family inet address 192.168.100.1/32
set logical-systems r2 interfaces lo0 unit 2000 family inet address 192.168.100.2/32
set logical-systems r2 policy-options policy-statement fromrib term 1 from rib vr2.inet.0
set logical-systems r2 policy-options policy-statement fromrib term 1 then accept
set logical-systems r2 policy-options policy-statement fromrib1 from rib vr1.inet.0
set logical-systems r2 policy-options policy-statement fromrib1 then accept
set logical-systems r2 routing-instances vr1 instance-type virtual-router
set logical-systems r2 routing-instances vr1 interface ge-0/0/1.12
set logical-systems r2 routing-instances vr1 interface lo0.1000
set logical-systems r2 routing-instances vr1 routing-options interface-routes rib-group inet vr1vr2
set logical-systems r2 routing-instances vr1 protocols ospf rib-group vr1vr2
set logical-systems r2 routing-instances vr1 protocols ospf export fromrib1
set logical-systems r2 routing-instances vr1 protocols ospf area 0.0.0.0 interface all
set logical-systems r2 routing-instances vr2 instance-type virtual-router
set logical-systems r2 routing-instances vr2 interface ge-0/0/0.23
set logical-systems r2 routing-instances vr2 interface lo0.2000
set logical-systems r2 routing-instances vr2 routing-options interface-routes rib-group inet vr2vr1
set logical-systems r2 routing-instances vr2 protocols ospf rib-group vr2vr1
set logical-systems r2 routing-instances vr2 protocols ospf export fromrib
set logical-systems r2 routing-instances vr2 protocols ospf area 0.0.0.0 interface all
set logical-systems r2 routing-options rib-groups vr1vr2 export-rib vr2.inet.0
set logical-systems r2 routing-options rib-groups vr1vr2 import-rib vr1.inet.0
set logical-systems r2 routing-options rib-groups vr1vr2 import-rib vr2.inet.0
set logical-systems r2 routing-options rib-groups vr2vr1 import-rib vr2.inet.0
set logical-systems r2 routing-options rib-groups vr2vr1 import-rib vr1.inet.0

labroot@re0_re0:r2>

Hi Python,

Thank you for your help. Very much appreciated. 

I have only had chance to give the first policy option a try but it fails for the interface command..... inet issue....

The following command "set routing-instances Customer-VR routing-options interface-routes rib-group inet vr1vr2" is where I am getting an issue.... 

Also, "set routing-instances Customer-VR protocols isis rib-group vr1vr2" is not being accepted

I expect this may revolve around the issue of OSPF being tested in your config whereas we are using ISIS ...... I have tried with the "protocols isis" as the replacement, but it does seem to throw up errors..... I will try on the other system later.

I am very grateful for your help with this and the time you are spending on the issue. Very much appreciated....

What is the topology here?

I only see an ae interface in customer vr and the physical interface in ninegroup vr.

The virtual routers are separate and do not share routes without some kind of connection between the routers.  This is likely why the policy is not working.

Think of the vr as if they were separate physical routers you are interconnecting.

If you need to share routes without having a physical connection between the vr then you would need to either setup rib groups for route leaking or create logical tunnel interfaces to connect the vr with virtual interfaces.

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/services-configuring-logical-tunnel-interfaces.html

https://www.juniper.net/documentation/en_US/junos/topics/example/routing-table-import.html

Hi Spuluka,

Okay, so I had a little bit of confusion there....

I realise the VRs are treated as seperate routers and therefore require configuration within their Instances rather than at global level. I also realised that these are Logical routers and not physical. In a physical environment we would have a cable between them and configure the connected interfaces. In the logical case we need something internal to represent the physical cable.....

Where I got confused and you have helped me out is the policy statement. I thought to get the connectivity between the logical router interfaces, we simply had to define zones and a policy to allow that routing information share between the two systems but now I know this is not correct (although still required I expect). 

I will have a look at the documentation as well as Python's brilliant input.

So, I now undertsand that part too.... my apologies for the confusion.

Thank you

Hi Steve / Python,

These docs and configs are great for exporting the routes from one instance to another and I have no issue with that. It all works great---- locally --- and that's the problem. All of these resolutions seem to work locally but not external to the SRX device.

If I use the Policy statements and the RIB groups what happens is that the routes from the Customer-VR then appear in the NineGroup-VR routing table and the same vice-versa. The problem is that the route configured on the ge-0/0/2 interface to the RADIUS is not seen external to the SRX..... Here is a basic topology:

RADIUS --> (ge-0/0/2 - NineGroup-VR)-SRX-(ae2 - Customer-VR) --> (ae2)-Core --> LNS --> LAC --> CPE

So, when looking at the routing table, Customer-VR see the NineGroup-VR routes as "Local" and not ISIS, so, of course, isis will not forward these because it does'nt know about them (I think).... This is the problem I have.... if I logon to the Core, there is no route to the NineGroup-VR addressing.

Thanks 

Apologies, as an add on to my last message, I fully appreciate this is a security device we are talking about and so, of course, the default will always be to separate the interfaces so that policies are required. I am sure on a normal MX router the configs are easier.

If I remove the VRs and use the default "trust/untrust", I can get this working by using the export command as follows:

set routing-options static route 195.80.0.54/32 next-hop 195.80.0.53

set routing-options set policy-options policy-statement export_statics term 1 from protocol static

set policy-options policy-statement export_statics term 1 then accept

set protocols isis export export_statics

If I then look on the data network this route appears everywhere advertised through isis (because that's where I placed the policy-statement)... but I just simply cannot even get this basic working from new VRs.... 😞

If I have a look at this forum item:

https://forums.juniper.net/t5/Routing/how-to-configure-ISIS-between-routing-instances-qfabric-QFX3500/td-p/267584

I have configured exactly the same way and yet it doesn't work, but this guys does.....

Very confused 😞  😞

Hi..... 

Update to the problem. I think I am half way there, or maybe a little further....

Here is a quick overview of what I need to work:

RADIUS --> ge-0/0/2 (SRX) <--> ae2 (SRX) --> Core --> LNS --> LAC --> CPE (Client)

The client has to get VSAs and PPP authentication from the RADIUS (we will also have an IPv6 DNS off another port). This means having the separate VRs and routing required between them.....

So, I know have the RADIUS Server address showing on the CORE routing table and advertised through ISIS. I used the lt interface eventually to create a tunnel. 

I still have a problem though. Although the RADIUS is in the routing table I cannot ping it and neither is the client coming up with an IPCP address (this will only occur once authorisation has completed). So, it's like it knows it's there but won't allow anything to communicate with it. Maybe I have something wrong with the config.... Here is what I have used:

SRX 

set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest match source-address any
set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest match destination-address any
set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest match application any
set security policies from-zone Customer-Network to-zone NineGroup-DMZ policy CliveTest then permit
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 match source-address any
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 match destination-address any
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 match application any
set security policies from-zone NineGroup-DMZ to-zone Customer-Network policy CliveTest1 then permit

set security zones security-zone NineGroup-DMZ host-inbound-traffic system-services all
set security zones security-zone NineGroup-DMZ host-inbound-traffic protocols all
set security zones security-zone NineGroup-DMZ interfaces ge-0/0/2.0
set security zones security-zone NineGroup-DMZ interfaces lt-0/0/0.1
set security zones security-zone Customer-Network host-inbound-traffic system-services all
set security zones security-zone Customer-Network host-inbound-traffic protocols all
set security zones security-zone Customer-Network interfaces ae2.0
set security zones security-zone Customer-Network interfaces lt-0/0/0.2

set interfaces lt-0/0/0 unit 1 encapsulation ethernet
set interfaces lt-0/0/0 unit 1 peer-unit 2
set interfaces lt-0/0/0 unit 1 family inet address 10.20.30.1/30
set interfaces lt-0/0/0 unit 1 family iso
set interfaces lt-0/0/0 unit 2 encapsulation ethernet
set interfaces lt-0/0/0 unit 2 peer-unit 1
set interfaces lt-0/0/0 unit 2 family inet address 10.20.30.2/30
set interfaces lt-0/0/0 unit 2 family iso

set interfaces ge-0/0/2 unit 0 description To-HEX-RADIUS-SERVER
set interfaces ge-0/0/2 unit 0 family inet address 195.80.0.53/30
set interfaces ge-0/0/2 unit 0 family iso
set interfaces ge-0/0/2 unit 0 family inet6 address 2a05:d840:004d:ffff:ffff:ffff:0000:0001/127

set interfaces ae2 unit 0 description To-HEX-CORE-02-ae2
set interfaces ae2 unit 0 family inet address 195.80.0.33/30
set interfaces ae2 unit 0 family iso
set interfaces ae2 unit 0 family inet6 address 2a05:d840:0048:ffff:ffff:ffff:0000:0002/127

set interfaces lo0 unit 0 family inet address 195.80.0.6/32
set interfaces lo0 unit 0 family iso address 49.0001.1950.0080.0006.00
set interfaces lo0 unit 0 family inet6 address 2a05:d840:001c:ffff:ffff:ffff:0000:0001/128
set interfaces lo0 unit 10 family iso address 49.0001.1950.0080.0026.00
set interfaces lo0 unit 20 family iso address 49.0001.1950.0080.0016.00

set routing-options static route 195.80.0.54/32 next-hop 195.80.0.53

set policy-options policy-statement from_customer_to_ninegroup from instance Customer-VR
set policy-options policy-statement from_customer_to_ninegroup from protocol direct
set policy-options policy-statement from_customer_to_ninegroup then accept
set policy-options policy-statement from_nine_to_customer from instance NineGroup-VR
set policy-options policy-statement from_nine_to_customer from protocol direct
set policy-options policy-statement from_nine_to_customer then accept
set policy-options policy-statement nine term term1 from protocol static
set policy-options policy-statement nine term term1 then accept
set policy-options policy-statement statics_to_isis term term1 from protocol direct
set policy-options policy-statement statics_to_isis term term1 then accept

set routing-instances Customer-VR instance-type virtual-router
set routing-instances Customer-VR interface lt-0/0/0.2
set routing-instances Customer-VR interface ae2.0
set routing-instances Customer-VR interface lo0.10
set routing-instances Customer-VR protocols isis export statics_to_isis
set routing-instances Customer-VR protocols isis export from_nine_to_customer
set routing-instances Customer-VR protocols isis level 1 authentication-key "$9$iHfz9Cu1Eyp0yKWxwsZUjHP5z36AuO"
set routing-instances Customer-VR protocols isis level 1 authentication-type md5
set routing-instances Customer-VR protocols isis level 2 authentication-key "$9$3DmzntOhclMLNreNbYoji5QFnApO1RSlK"
set routing-instances Customer-VR protocols isis level 2 authentication-type md5
set routing-instances Customer-VR protocols isis interface lt-0/0/0.2
set routing-instances Customer-VR protocols isis interface ae2.0
set routing-instances Customer-VR protocols isis interface lo0.10
set routing-instances NineGroup-VR instance-type virtual-router
set routing-instances NineGroup-VR interface lt-0/0/0.1
set routing-instances NineGroup-VR interface ge-0/0/2.0
set routing-instances NineGroup-VR interface lo0.20
set routing-instances NineGroup-VR protocols isis export statics_to_isis
set routing-instances NineGroup-VR protocols isis export from_customer_to_ninegroup
set routing-instances NineGroup-VR protocols isis export nine
set routing-instances NineGroup-VR protocols isis level 1 authentication-key "$9$C67IABEleWx-wM8wgaU.m369AO1EcyKWL"
set routing-instances NineGroup-VR protocols isis level 1 authentication-type md5
set routing-instances NineGroup-VR protocols isis level 2 authentication-key "$9$Yq2ZjmPQn9pTzpBRSMWdbs2JGjHqfQF"
set routing-instances NineGroup-VR protocols isis level 2 authentication-type md5
set routing-instances NineGroup-VR protocols isis interface lt-0/0/0.1
set routing-instances NineGroup-VR protocols isis interface ge-0/0/2.0
set routing-instances NineGroup-VR protocols isis interface lo0.20

Routing table on CORE Router for RADIUS

Clive@HEX-CORE-02# run show route 195.80.0.54

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

195.80.0.52/30 *[IS-IS/15] 00:23:03, metric 30
> to 195.80.0.33 via ae2.0

Ping test from CORE:

Clive@HEX-CORE-02# run ping 195.80.0.54
PING 195.80.0.54 (195.80.0.54): 56 data bytes
^C
--- 195.80.0.54 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

Routing table SRX:

NineGroup-VR.inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.20.30.0/30 *[Direct/0] 00:28:11
> via lt-0/0/0.1
10.20.30.1/32 *[Local/0] 00:29:33
Local via lt-0/0/0.1
192.168.85.0/24 *[IS-IS/160] 00:27:14, metric 30
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.1/32 *[IS-IS/15] 00:27:14, metric 40
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.2/32 *[IS-IS/15] 00:27:14, metric 30
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.3/32 *[IS-IS/15] 00:27:14, metric 40
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.4/32 *[IS-IS/15] 00:27:14, metric 30
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.5/32 *[IS-IS/15] 00:27:14, metric 20
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.12/30 *[IS-IS/15] 00:27:14, metric 40
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.16/30 *[IS-IS/15] 00:27:14, metric 40
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.20/30 *[IS-IS/15] 00:27:14, metric 30
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.32/30 *[IS-IS/15] 00:27:29, metric 20
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.36/30 *[IS-IS/15] 00:27:14, metric 50
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.44/30 *[IS-IS/15] 00:27:14, metric 30
> to 10.20.30.2 via lt-0/0/0.1
195.80.0.52/30 *[Direct/0] 18:27:30
> via ge-0/0/2.0
195.80.0.53/32 *[Local/0] 18:27:30
Local via ge-0/0/2.0
195.80.0.64/30 *[IS-IS/15] 00:27:14, metric 40
> to 10.20.30.2 via lt-0/0/0.1

Customer-VR.inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.20.30.0/30 *[Direct/0] 00:28:11
> via lt-0/0/0.2
10.20.30.2/32 *[Local/0] 00:28:11
Local via lt-0/0/0.2
192.168.85.0/24 *[IS-IS/160] 3d 17:55:30, metric 20
> to 195.80.0.34 via ae2.0
195.80.0.1/32 *[IS-IS/15] 3d 17:55:30, metric 30
> to 195.80.0.34 via ae2.0
195.80.0.2/32 *[IS-IS/15] 3d 17:55:30, metric 20
> to 195.80.0.34 via ae2.0
195.80.0.3/32 *[IS-IS/15] 3d 17:55:25, metric 30
> to 195.80.0.34 via ae2.0
195.80.0.4/32 *[IS-IS/15] 3d 17:55:30, metric 20
> to 195.80.0.34 via ae2.0
195.80.0.5/32 *[IS-IS/15] 3d 17:55:39, metric 10
> to 195.80.0.34 via ae2.0
195.80.0.12/30 *[IS-IS/15] 3d 17:55:30, metric 30
> to 195.80.0.34 via ae2.0
195.80.0.16/30 *[IS-IS/15] 3d 17:55:30, metric 30
> to 195.80.0.34 via ae2.0
195.80.0.20/30 *[IS-IS/15] 3d 17:55:39, metric 20
> to 195.80.0.34 via ae2.0
195.80.0.32/30 *[Direct/0] 3d 17:57:13
> via ae2.0
195.80.0.33/32 *[Local/0] 3d 17:57:13
Local via ae2.0
195.80.0.36/30 *[IS-IS/15] 3d 17:55:25, metric 40
> to 195.80.0.34 via ae2.0
195.80.0.44/30 *[IS-IS/15] 3d 17:55:39, metric 20
> to 195.80.0.34 via ae2.0
195.80.0.52/30 *[IS-IS/15] 00:27:29, metric 20
> to 10.20.30.1 via lt-0/0/0.2
195.80.0.64/30 *[IS-IS/15] 3d 17:55:30, metric 30
> to 195.80.0.34 via ae2.0

Sorry this is so long..... can anyone please point me as to where I have gone wrong please?

Thanks

So  the route to the RADIUS server is now in the customer VR.

Your policies allow all the traffic.

Next check the source address of the RADIUS request in the VR in the routing table of the nine group vr.  Will that traffic be sent across your lt interface connection?

Is that route upstream on the path to the RADIUS server as well so the return packets have a full path?

Hi Steve,

Thank you for your help along with Python with regards to this issue.

The mind sometimes misses simple steps that when looked at from a different angle are seen.

Not only does there have to be a policy in place for the tunnel, but there has to be a security policy in place within a VR that allows the logical to talk to the physical. This I should have noted but missed:

I added the following:

set security policies from-zone Customer-Network to-zone Customer-Network policy CliveTest match source-address any

set security policies from-zone Customer-Network to-zone Customer-Network policy CliveTest match destination-address any

set security policies from-zone Customer-Network to-zone Customer-Network policy CliveTest match application any

set security policies from-zone Customer-Network to-zone Customer-Network policy CliveTest then permit

set security policies from-zone NineGroup-DMZ to-zone NineGroup-DMZ policy CliveTest1 match source-address any

set security policies from-zone NineGroup-DMZ to-zone NineGroup-DMZ policy CliveTest1 match destination-address any

set security policies from-zone NineGroup-DMZ to-zone NineGroup-DMZ policy CliveTest1 match application any

set security policies from-zone NineGroup-DMZ to-zone NineGroup-DMZ policy CliveTest1 then permit

It now all works perfectly. Thank you all again for your great help..... superb....

Good to see your last update. 

Glad you have it working.