Re: [j-nsp] controlling the source IP for the Dns Proxy feature
I'm running 12.1X44-D40.2 right now (had to run newer 12.1X code to even
use the dns-proxy feature :) ). I'll give X46-D10 a look; the
traffic-selctors looks pretty interesting.
As far as your comment regarding widening the crypto-map- that's what i
was implying with my example acl- basically widening it on the cisco side
to include every IP subnet ('any'). Not sure if that's allowed.
Either way it looks like i've got some good options to try.
Thank you!
-andy
On 10/15/14 3:50 PM, "Ben Dale" wrote:
>I've certainly had no issue with stability using route-based VPN.
>
>As far as multiple subnet (proxy-id / traffic selectors) support, as of
>12.1X46-D10 this is now native in Junos -
>
>http://kb.juniper.net/InfoCenter/index?page=content&id=KB28820
>
>and is dead simple to configure.
>
>If you're a little gun shy on 12.1X code and are still running
>old-faithful builds like 11.4RLate, then there are a couple of options:
>
>- If your subnets are contiguous, just widen the mask to include them in
>a single crypto-map on the Cisco side (even if that means widening the
>mask a LOT)
>
>- If your subnets are arbitrarily selected from different RFC1918 blocks
>(DOH!), then create separate P2 bindings for each subnet:
>
>http://kb.juniper.net/InfoCenter/index?page=content&id=KB20543
>
>just be aware that this will only work if the multiple subnets are on the
>Cisco side (which seems to be true in your case)
>
>There are a few other hacks out there using FBF as well. J-NET has some
>good material:
>
>http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on
>-route-based-VPN-with-multiple-local/td-p/172002/page/2
>
>Cheers,
>
>Ben
>
>On 16 Oct 2014, at 8:35 am, Andy Litzinger
> wrote:
>
>> I'd happily use route-based vpns if they are supported in my use case.
>> Based on Kbs and internet lore, it seemed policy based was the best bet
>> for stability.
>>
>> My two tunnel endpoint devices are the SRX and a Cisco ASA.
>> On the SRX side I've got a single subnet but on the ASA side I've got
>>two
>> subnets. I would happily use a simple policy on the ASA side like
>>'permit
>> ip any ' if i was confident I wasn't
>> going to have squirrely issues with connectivity.
>>
>> What do you think?
>>
>> -andy
>>
>> On 10/15/14 3:22 PM, "Ben Dale" wrote:
>>
>>> Hi Andy,
>>>
>>> I have come across this exact issue using the feature.
>>>
>>> There was a good reason why we didn't use default address selection
>>>that
>>> escapes me just now, but I had a slight advantage in that I was using
>>> route-based VPNs, so I was able to number the st0 interface with a /32
>>> from the corporate range and source my queries from there.
>>>
>>> Unfortunately policy-based VPNs are extremely limiting when it comes to
>>> things like this. I can't think of too many scenarios where I'd even
>>>use
>>> them any more. If you don't have too many sites, I'd seriously
>>>consider
>>> migrating them across.
>>>
>>> Cheers,
>>>
>>> Ben
>>>
>>> On 16 Oct 2014, at 1:28 am, Andy Litzinger
>>> wrote:
>>>
Hello,
is anyone out there using the dns-proxy feature for the branch SRX?
Are
there any clever tricks for specifying the source address the SRX uses
to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can
solve
my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust
zone.
users sit on the trust zone and receive dhcp from the SRX and use the
SRX
as their default gateway and dns server. There is a policy based vpn
that
connects from the untrust zone to our corp HQ. I have the dns-proxy
config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
;
;
}
}
}
the problem is without the 'default address selection' set the SRX
tries to
use the untrust interface IP as the source IP to query our corp HQ
name
servers, but the traffic doesn't enter the tunnel because it doesn't
match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is jun
Re: [j-nsp] controlling the source IP for the Dns Proxy feature
I'd happily use route-based vpns if they are supported in my use case.
Based on Kbs and internet lore, it seemed policy based was the best bet
for stability.
My two tunnel endpoint devices are the SRX and a Cisco ASA.
On the SRX side I've got a single subnet but on the ASA side I've got two
subnets. I would happily use a simple policy on the ASA side like 'permit
ip any ' if i was confident I wasn't
going to have squirrely issues with connectivity.
What do you think?
-andy
On 10/15/14 3:22 PM, "Ben Dale" wrote:
>Hi Andy,
>
>I have come across this exact issue using the feature.
>
>There was a good reason why we didn't use default address selection that
>escapes me just now, but I had a slight advantage in that I was using
>route-based VPNs, so I was able to number the st0 interface with a /32
>from the corporate range and source my queries from there.
>
>Unfortunately policy-based VPNs are extremely limiting when it comes to
>things like this. I can't think of too many scenarios where I'd even use
>them any more. If you don't have too many sites, I'd seriously consider
>migrating them across.
>
>Cheers,
>
>Ben
>
>On 16 Oct 2014, at 1:28 am, Andy Litzinger
> wrote:
>
>> Hello,
>> is anyone out there using the dns-proxy feature for the branch SRX? Are
>> there any clever tricks for specifying the source address the SRX uses
>>to
>> query name servers? It does not appear to be a config option.
>>
>> with the default config it appears to use the IP of the outbound
>> interface. If I add the config statement 'set system default address
>> selection' i can influence it to use the lo0.0 address, which can solve
>>my
>> issue, but not in a way i prefer.
>>
>> my exact problem is the following:
>> I have an SRX 220H in a remote office. It has an trust and untrust zone.
>> users sit on the trust zone and receive dhcp from the SRX and use the
>>SRX
>> as their default gateway and dns server. There is a policy based vpn
>>that
>> connects from the untrust zone to our corp HQ. I have the dns-proxy
>>config
>> set up so that if a dns request is going to an intranet zone, e.g.
>> corp.example.com, then it should use DNS servers that live across the
>> tunnel in our corp HQ. If they are looking up anything else, they use
>> google dns servers.
>>
>> here's the relevant config:
>> dns-proxy {
>>interface {
>>;
>>}
>>default-domain * {
>>forwarders {
>>8.8.8.8;
>>8.8.4.4;
>>}
>>}
>>default-domain corp.example.com {
>>forwarders {
>>;
>>;
>>}
>>}
>> }
>>
>> the problem is without the 'default address selection' set the SRX
>>tries to
>> use the untrust interface IP as the source IP to query our corp HQ name
>> servers, but the traffic doesn't enter the tunnel because it doesn't
>>match
>> the vpn policy. And I can't change the policy to allow it because the
>> untrust interface IP is the endpoint of the tunnel. It looks like the
>> source zone of the dns query is junos-host- is it possible maybe to set
>>up
>> a junos-host zone to untrust zone NAT when going to corp-hq IP space?
>>
>> or is there another clever solution?
>>
>> thanks!
>> -andy
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] controlling the source IP for the Dns Proxy feature
I've certainly had no issue with stability using route-based VPN.
As far as multiple subnet (proxy-id / traffic selectors) support, as of
12.1X46-D10 this is now native in Junos -
http://kb.juniper.net/InfoCenter/index?page=content&id=KB28820
and is dead simple to configure.
If you're a little gun shy on 12.1X code and are still running old-faithful
builds like 11.4RLate, then there are a couple of options:
- If your subnets are contiguous, just widen the mask to include them in a
single crypto-map on the Cisco side (even if that means widening the mask a LOT)
- If your subnets are arbitrarily selected from different RFC1918 blocks
(DOH!), then create separate P2 bindings for each subnet:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB20543
just be aware that this will only work if the multiple subnets are on the Cisco
side (which seems to be true in your case)
There are a few other hacks out there using FBF as well. J-NET has some good
material:
http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on-route-based-VPN-with-multiple-local/td-p/172002/page/2
Cheers,
Ben
On 16 Oct 2014, at 8:35 am, Andy Litzinger
wrote:
> I'd happily use route-based vpns if they are supported in my use case.
> Based on Kbs and internet lore, it seemed policy based was the best bet
> for stability.
>
> My two tunnel endpoint devices are the SRX and a Cisco ASA.
> On the SRX side I've got a single subnet but on the ASA side I've got two
> subnets. I would happily use a simple policy on the ASA side like 'permit
> ip any ' if i was confident I wasn't
> going to have squirrely issues with connectivity.
>
> What do you think?
>
> -andy
>
> On 10/15/14 3:22 PM, "Ben Dale" wrote:
>
>> Hi Andy,
>>
>> I have come across this exact issue using the feature.
>>
>> There was a good reason why we didn't use default address selection that
>> escapes me just now, but I had a slight advantage in that I was using
>> route-based VPNs, so I was able to number the st0 interface with a /32
>> from the corporate range and source my queries from there.
>>
>> Unfortunately policy-based VPNs are extremely limiting when it comes to
>> things like this. I can't think of too many scenarios where I'd even use
>> them any more. If you don't have too many sites, I'd seriously consider
>> migrating them across.
>>
>> Cheers,
>>
>> Ben
>>
>> On 16 Oct 2014, at 1:28 am, Andy Litzinger
>> wrote:
>>
>>> Hello,
>>> is anyone out there using the dns-proxy feature for the branch SRX? Are
>>> there any clever tricks for specifying the source address the SRX uses
>>> to
>>> query name servers? It does not appear to be a config option.
>>>
>>> with the default config it appears to use the IP of the outbound
>>> interface. If I add the config statement 'set system default address
>>> selection' i can influence it to use the lo0.0 address, which can solve
>>> my
>>> issue, but not in a way i prefer.
>>>
>>> my exact problem is the following:
>>> I have an SRX 220H in a remote office. It has an trust and untrust zone.
>>> users sit on the trust zone and receive dhcp from the SRX and use the
>>> SRX
>>> as their default gateway and dns server. There is a policy based vpn
>>> that
>>> connects from the untrust zone to our corp HQ. I have the dns-proxy
>>> config
>>> set up so that if a dns request is going to an intranet zone, e.g.
>>> corp.example.com, then it should use DNS servers that live across the
>>> tunnel in our corp HQ. If they are looking up anything else, they use
>>> google dns servers.
>>>
>>> here's the relevant config:
>>> dns-proxy {
>>> interface {
>>> ;
>>> }
>>> default-domain * {
>>> forwarders {
>>> 8.8.8.8;
>>> 8.8.4.4;
>>> }
>>> }
>>> default-domain corp.example.com {
>>> forwarders {
>>> ;
>>> ;
>>> }
>>> }
>>> }
>>>
>>> the problem is without the 'default address selection' set the SRX
>>> tries to
>>> use the untrust interface IP as the source IP to query our corp HQ name
>>> servers, but the traffic doesn't enter the tunnel because it doesn't
>>> match
>>> the vpn policy. And I can't change the policy to allow it because the
>>> untrust interface IP is the endpoint of the tunnel. It looks like the
>>> source zone of the dns query is junos-host- is it possible maybe to set
>>> up
>>> a junos-host zone to untrust zone NAT when going to corp-hq IP space?
>>>
>>> or is there another clever solution?
>>>
>>> thanks!
>>> -andy
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/ma
Re: [j-nsp] controlling the source IP for the Dns Proxy feature
Hi Andy,
I have come across this exact issue using the feature.
There was a good reason why we didn't use default address selection that
escapes me just now, but I had a slight advantage in that I was using
route-based VPNs, so I was able to number the st0 interface with a /32 from the
corporate range and source my queries from there.
Unfortunately policy-based VPNs are extremely limiting when it comes to things
like this. I can't think of too many scenarios where I'd even use them any
more. If you don't have too many sites, I'd seriously consider migrating them
across.
Cheers,
Ben
On 16 Oct 2014, at 1:28 am, Andy Litzinger
wrote:
> Hello,
> is anyone out there using the dns-proxy feature for the branch SRX? Are
> there any clever tricks for specifying the source address the SRX uses to
> query name servers? It does not appear to be a config option.
>
> with the default config it appears to use the IP of the outbound
> interface. If I add the config statement 'set system default address
> selection' i can influence it to use the lo0.0 address, which can solve my
> issue, but not in a way i prefer.
>
> my exact problem is the following:
> I have an SRX 220H in a remote office. It has an trust and untrust zone.
> users sit on the trust zone and receive dhcp from the SRX and use the SRX
> as their default gateway and dns server. There is a policy based vpn that
> connects from the untrust zone to our corp HQ. I have the dns-proxy config
> set up so that if a dns request is going to an intranet zone, e.g.
> corp.example.com, then it should use DNS servers that live across the
> tunnel in our corp HQ. If they are looking up anything else, they use
> google dns servers.
>
> here's the relevant config:
> dns-proxy {
>interface {
>;
>}
>default-domain * {
>forwarders {
>8.8.8.8;
>8.8.4.4;
>}
>}
>default-domain corp.example.com {
>forwarders {
>;
>;
>}
>}
> }
>
> the problem is without the 'default address selection' set the SRX tries to
> use the untrust interface IP as the source IP to query our corp HQ name
> servers, but the traffic doesn't enter the tunnel because it doesn't match
> the vpn policy. And I can't change the policy to allow it because the
> untrust interface IP is the endpoint of the tunnel. It looks like the
> source zone of the dns query is junos-host- is it possible maybe to set up
> a junos-host zone to untrust zone NAT when going to corp-hq IP space?
>
> or is there another clever solution?
>
> thanks!
> -andy
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M20 fpc issue
I started with a 10.0 train with the same symptoms. show log chassisd only shows an snmp trap for fru removal when the fpc is trying to come up. show log messages has this, though- Oct 15 13:56:48 lab-m20 alarmd[1532]: Alarm set: FPC color=RED, class=CHASSIS, reason=Too many unrecoverable errors Oct 15 13:56:48 lab-m20 craftd[1533]: Major alarm set, Too many unrecoverable errors Oct 15 13:56:48 lab-m20 craftd[1533]: forwarding display request to chassisd: type = 4, subtype = 43 Oct 15 13:56:48 lab-m20 CM(0): Slot 3: No response from FPC interface manager Oct 15 13:56:48 lab-m20 chassisd[1531]: CHASSISD_FRU_EVENT: scb_recv_slot_detach: detached FPC 3 Oct 15 13:56:48 lab-m20 chassisd[1531]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(3) Oct 15 13:56:48 lab-m20 CM(0): Slot 3: No response from FPC chassis manager Oct 15 13:56:48 lab-m20 chassisd[1531]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU insertion (jnxFruContentsIndex 7, jnxFruL1Index 4, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: FPC @ 3/*/*, jnxFruType 3, jnxFruSlot 3) Oct 15 13:56:48 lab-m20 CM(0): Slot 3: Unrecoverable error; probe failed Oct 15 13:56:48 lab-m20 CM(0): Slot 3: Too many unrecoverable errors, going off-line Oct 15 13:56:48 lab-m20 CM(0): ALARM SET: (Major) Slot 3: Too many unrecoverable errors So no real clue as to why it won't come up. Again, I get this on every FPC I try in the box, and I've tried a different chassis (using the same re's) with the same results. I initially thought it might be an expired hardware certificate on the FPC, but setting the date back to 2001 didn't help. On Wed, Oct 15, 2014 at 3:04 PM, Damien DeVille wrote: > Hi Joe- > > Have you tried an 11.x or 10.x train of code? The M20 went end of > engineering on 30-Sep-2011 so 12.x versions Junos might not support the FPC. > > Also, you should see something in var/log/messages if the system can't > bring the fpc on line. > > request chassis fpc online slot should also give you an error > message if it can't bring it online. > > > - Damien > > On Wed, Oct 15, 2014 at 2:58 PM, Joe Freeman wrote: > >> Greetings- >> >> I have an M20 in the lab that I need to get up for a couple of tests. I >> realize it's an old boat anchor and isn't supported, but it's what I've >> got >> at the moment. All I really need to do is some MPLS/LDP testing, which it >> should be able to do. >> >> I have Junos 12.3R1.7 running on this hardware build- >> root@lab-m20> show chassis hardware >> Hardware inventory: >> Item Version Part number Serial number Description >> Chassis22178 M20 >> BackplaneREV 07 710-001517 AL3655M20 Backplane >> Power Supply A Rev 03 740-007311 506645AC Power Supply >> Display REV 04 710-001519 AF4603M20 FPM Board >> Routing Engine 0 REV 01 740-016485 P13004103006 RE-4.0 >> Routing Engine 1 REV 06 740-008883 P11123901048 RE-4.0 >> SSB 0REV 01 710-001951 AF2998Internet >> Processor >> IIv1 >> SSB 1N/A N/A N/A Backup >> Fan Tray 0 Front Upper Fan >> Tray >> Fan Tray 1 Front Middle Fan >> Tray >> Fan Tray 2 Front Bottom Fan >> Tray >> Fan Tray 3 Rear Fan Tray >> >> >> Notice the FPC's aren't showing up They are all offline, and I can't >> get them to come online- >> root@lab-m20> show chassis fpc >> Temp CPU Utilization (%) MemoryUtilization (%) >> Slot State(C) Total Interrupt DRAM (MB) Heap Buffer >> 0 Offline 27 >> 1 Offline 29 >> 2 Offline 27 >> 3 Offline 27 >> >> root@lab-m20> request chassis fpc slot 3 online >> Online initiated, use "show chassis fpc" to verify >> >> root@lab-m20> show chassis fpc >> Temp CPU Utilization (%) MemoryUtilization (%) >> Slot State(C) Total Interrupt DRAM (MB) Heap Buffer >> 0 Offline 27 >> 1 Offline 29 >> 2 Offline 27 >> 3 Offline Absent >> >> root@lab-m20> show chassis fpc >> Temp CPU Utilization (%) MemoryUtilization (%) >> Slot State(C) Total Interrupt DRAM (MB) Heap Buffer >> 0 Offline 27 >> 1 Offline 29 >> 2 Offline 27 >> 3 Present 27 >> >> They will sit at present for several minutes, then change to empty for a >> few minutes, then return back to offline. >> >> While they are in the 'present' state, they will show up in the show >> chassis hardware output- >> FPC 3REV 10 710-000175 AA7681FPC >> >> I've changed to different fpc's, different ssb's, different RE's and >> c
Re: [j-nsp] M20 fpc issue
Hi Joe- Have you tried an 11.x or 10.x train of code? The M20 went end of engineering on 30-Sep-2011 so 12.x versions Junos might not support the FPC. Also, you should see something in var/log/messages if the system can't bring the fpc on line. request chassis fpc online slot should also give you an error message if it can't bring it online. - Damien On Wed, Oct 15, 2014 at 2:58 PM, Joe Freeman wrote: > Greetings- > > I have an M20 in the lab that I need to get up for a couple of tests. I > realize it's an old boat anchor and isn't supported, but it's what I've got > at the moment. All I really need to do is some MPLS/LDP testing, which it > should be able to do. > > I have Junos 12.3R1.7 running on this hardware build- > root@lab-m20> show chassis hardware > Hardware inventory: > Item Version Part number Serial number Description > Chassis22178 M20 > BackplaneREV 07 710-001517 AL3655M20 Backplane > Power Supply A Rev 03 740-007311 506645AC Power Supply > Display REV 04 710-001519 AF4603M20 FPM Board > Routing Engine 0 REV 01 740-016485 P13004103006 RE-4.0 > Routing Engine 1 REV 06 740-008883 P11123901048 RE-4.0 > SSB 0REV 01 710-001951 AF2998Internet Processor > IIv1 > SSB 1N/A N/A N/A Backup > Fan Tray 0 Front Upper Fan > Tray > Fan Tray 1 Front Middle Fan > Tray > Fan Tray 2 Front Bottom Fan > Tray > Fan Tray 3 Rear Fan Tray > > > Notice the FPC's aren't showing up They are all offline, and I can't > get them to come online- > root@lab-m20> show chassis fpc > Temp CPU Utilization (%) MemoryUtilization (%) > Slot State(C) Total Interrupt DRAM (MB) Heap Buffer > 0 Offline 27 > 1 Offline 29 > 2 Offline 27 > 3 Offline 27 > > root@lab-m20> request chassis fpc slot 3 online > Online initiated, use "show chassis fpc" to verify > > root@lab-m20> show chassis fpc > Temp CPU Utilization (%) MemoryUtilization (%) > Slot State(C) Total Interrupt DRAM (MB) Heap Buffer > 0 Offline 27 > 1 Offline 29 > 2 Offline 27 > 3 Offline Absent > > root@lab-m20> show chassis fpc > Temp CPU Utilization (%) MemoryUtilization (%) > Slot State(C) Total Interrupt DRAM (MB) Heap Buffer > 0 Offline 27 > 1 Offline 29 > 2 Offline 27 > 3 Present 27 > > They will sit at present for several minutes, then change to empty for a > few minutes, then return back to offline. > > While they are in the 'present' state, they will show up in the show > chassis hardware output- > FPC 3REV 10 710-000175 AA7681FPC > > I've changed to different fpc's, different ssb's, different RE's and > changed the junos version. I even set the system clock back to 2001. No > change in symptoms. > > Any and all ideas are appreciated. > > Thanks- > Joe > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] M20 fpc issue
Greetings- I have an M20 in the lab that I need to get up for a couple of tests. I realize it's an old boat anchor and isn't supported, but it's what I've got at the moment. All I really need to do is some MPLS/LDP testing, which it should be able to do. I have Junos 12.3R1.7 running on this hardware build- root@lab-m20> show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis22178 M20 BackplaneREV 07 710-001517 AL3655M20 Backplane Power Supply A Rev 03 740-007311 506645AC Power Supply Display REV 04 710-001519 AF4603M20 FPM Board Routing Engine 0 REV 01 740-016485 P13004103006 RE-4.0 Routing Engine 1 REV 06 740-008883 P11123901048 RE-4.0 SSB 0REV 01 710-001951 AF2998Internet Processor IIv1 SSB 1N/A N/A N/A Backup Fan Tray 0 Front Upper Fan Tray Fan Tray 1 Front Middle Fan Tray Fan Tray 2 Front Bottom Fan Tray Fan Tray 3 Rear Fan Tray Notice the FPC's aren't showing up They are all offline, and I can't get them to come online- root@lab-m20> show chassis fpc Temp CPU Utilization (%) MemoryUtilization (%) Slot State(C) Total Interrupt DRAM (MB) Heap Buffer 0 Offline 27 1 Offline 29 2 Offline 27 3 Offline 27 root@lab-m20> request chassis fpc slot 3 online Online initiated, use "show chassis fpc" to verify root@lab-m20> show chassis fpc Temp CPU Utilization (%) MemoryUtilization (%) Slot State(C) Total Interrupt DRAM (MB) Heap Buffer 0 Offline 27 1 Offline 29 2 Offline 27 3 Offline Absent root@lab-m20> show chassis fpc Temp CPU Utilization (%) MemoryUtilization (%) Slot State(C) Total Interrupt DRAM (MB) Heap Buffer 0 Offline 27 1 Offline 29 2 Offline 27 3 Present 27 They will sit at present for several minutes, then change to empty for a few minutes, then return back to offline. While they are in the 'present' state, they will show up in the show chassis hardware output- FPC 3REV 10 710-000175 AA7681FPC I've changed to different fpc's, different ssb's, different RE's and changed the junos version. I even set the system clock back to 2001. No change in symptoms. Any and all ideas are appreciated. Thanks- Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 6VPE on QFX3500?
List friends, Does the QFX3500 support 6VPE, aka RFC4659? I cannot get an answer from JTAC or my SE. I can only find documentation from Juniper that 6PE is supported, with no mention of 6VPE as supported or unsupported. I think I have it working (using 12.3X50-D30), but do wonder if it is actually supported. Thank you, …karl ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] controlling the source IP for the Dns Proxy feature
Hello,
is anyone out there using the dns-proxy feature for the branch SRX? Are
there any clever tricks for specifying the source address the SRX uses to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can solve my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust zone.
users sit on the trust zone and receive dhcp from the SRX and use the SRX
as their default gateway and dns server. There is a policy based vpn that
connects from the untrust zone to our corp HQ. I have the dns-proxy config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
;
;
}
}
}
the problem is without the 'default address selection' set the SRX tries to
use the untrust interface IP as the source IP to query our corp HQ name
servers, but the traffic doesn't enter the tunnel because it doesn't match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is junos-host- is it possible maybe to set up
a junos-host zone to untrust zone NAT when going to corp-hq IP space?
or is there another clever solution?
thanks!
-andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
