Re: [j-nsp] ISIS authentication issue
On Wednesday, June 12, 2013 08:26:31 PM John Neiberger wrote:
The plan is eventually to add LSP authentication on the
Cisco side, but that would entail touching every Cisco
router in the area, which is kind of a pain at the
moment. We were hoping to find a way to get this
adjacency to the MX960 up before we tweak the rest of
the area. I think we'll try your first suggestion to see
if it at least gets us through for now and then we can
tweak it all again once we've added LSP authentication
to all the Cisco routers in the area.
My known working configuration for IOS XR, IOS, IOS XE
and Junos:
IOS XR:
router isis 1
lsp-password hmac-md5 encrypted somehing_encrypted level 2
!
interface GigabitEthernet0/0/0/0
hello-password hmac-md5 encrypted something_encrypted
IOS and IOS XE:
router isis 1
authentication mode md5
authentication key-chain some-name level-2
!
interface GigabitEthernet0/0
isis authentication mode md5 level-2
isis authentication key-chain some-name level-2
Junos:
isis-group {
protocols {
isis {
level 1 disable;
level 2 {
# authentication-key removed;
authentication-type md5;
Hope this helps.
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BOOTP helper on MX vrf
Hello, as I'm hearing conflicting information regarding bootp helper on MX routers in a vrf routing-instance, has anyone a working configuration? What I need: Forward DHCP broadcast requests from one vrf interface to a central DHCP server in the same VRF (classical bootp helper functionality). I don't want bootp helper on *every* interface, just a few. So any information regarding this is appreciated. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
On Thursday, June 13, 2013 01:03:04 PM Sebastian Wiesinger
wrote:
So any information regarding this is appreciated.
This was my working configuration on an MX480 running Junos
10.4:
routing-instances {
SOME-VRF-NAME {
...
skip
forwarding-options {
dhcp-relay {
overrides {
trust-option-82;
}
server-group {
DHCP-SERVICE {
192.168.1.1;
}
}
group DHCP-SERVICE {
active-server-group DHCP-SERVICE;
interface ge-0/0/0.190;
}
}
}
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
On 13/06/13 12:03, Sebastian Wiesinger wrote:
Hello,
as I'm hearing conflicting information regarding bootp helper on MX
routers in a vrf routing-instance, has anyone a working configuration?
What I need:
Forward DHCP broadcast requests from one vrf interface to a central
DHCP server in the same VRF (classical bootp helper functionality). I
don't want bootp helper on *every* interface, just a few.
It's a J-series, not MX, but should be the same:
forwarding-options {
helpers {
bootp {
interface {
ge-0/0/2.2021 {
server x.x.x.x routing-instance BLAH;
...and
routing-instances {
BLAH {
instance-type vrf;
interface ge-0/0/2.2021;
Basically, you have to put the routing-instance on the server option,
matching the routing instance of the interface.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
* Mark Tinka mark.ti...@seacom.mu [2013-06-13 13:24]:
On Thursday, June 13, 2013 01:03:04 PM Sebastian Wiesinger
wrote:
So any information regarding this is appreciated.
This was my working configuration on an MX480 running Junos
10.4:
routing-instances {
SOME-VRF-NAME {
...
skip
forwarding-options {
dhcp-relay {
Okay, but for dhcp-relay you need a license which is really not
something we want to do just for bootp helper. :)
Regards
Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
Hi, I have the following configuration working on an MX240 running 12.2R3.5. CUT set routing-instances 1023 forwarding-options dhcp-relay server-group SRV 10.1.1.33 set routing-instances 1023 forwarding-options dhcp-relay active-server-group SRV set routing-instances 1023 forwarding-options dhcp-relay group all active-server-group SRV set routing-instances 1023 forwarding-options dhcp-relay group all interface ge-2/0/2.85 set routing-instances 1023 forwarding-options dhcp-relay group all interface ge-2/1/9.806 CUT root@PE1-SVV show dhcp relay binding routing-instance 1023 IP addressSession Id Hardware address Expires State Interface 10.1.6.1069 00:1c:25:98:30:ca 685920 BOUND ge-2/1/9.806 10.1.6.11278 00:1c:25:9a:0b:f7 669024 BOUND ge-2/1/9.806 10.1.6.105107 00:1c:25:9a:3e:c0 673974 BOUND ge-2/1/9.806 10.1.6.10335 00:24:7e:00:a9:da 671427 BOUND ge-2/1/9.806 10.1.6.10190 00:24:7e:de:d4:e4 665187 BOUND ge-2/1/9.806 CUT Until now it has been running perfectly. Med venlig hilsen / Kind regards Peter Krüpl Network Specialist Tel: +45 88805242 Siminn Danmark A/S -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian Wiesinger Sent: 13. juni 2013 13:03 To: Juniper NSP Subject: [j-nsp] BOOTP helper on MX vrf Hello, as I'm hearing conflicting information regarding bootp helper on MX routers in a vrf routing-instance, has anyone a working configuration? What I need: Forward DHCP broadcast requests from one vrf interface to a central DHCP server in the same VRF (classical bootp helper functionality). I don't want bootp helper on *every* interface, just a few. So any information regarding this is appreciated. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] BOOTP helper on MX vrf
On Thursday, June 13, 2013 01:25:34 PM Sebastian Wiesinger wrote: Okay, but for dhcp-relay you need a license which is really not something we want to do just for bootp helper. :) If memory serves, I think the 1st 1,000 were free, but not sure if this has changed since 10.4. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
On Thursday, June 13, 2013 01:49:23 PM Sebastian Wiesinger wrote: Actually you're right. 1000 are free. That would be 1000 DHCP bindings on the whole box. Could work in this scenario... Is it true that the jdhcpd runs on the PFE? The bootp helper seems to punt *all* DHCP traffic (Port 69) going trough the box to the RE which is kind of scary... I just hope you can firewall it on the RE. IIRC, it's a control plane process. It would be nice if it can happen in the line card, but I don't have any definitive information on that. It is also good to ensure that if you have any Loopback interfaces in this VRF (as you would in a typical broadband type deployment), you check that you have allowed DHCP/BOOTP packets through the any group-applied firewalls, otherwise you could chase your tail trying to figure out what's going on. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] monitor start messages
Hello,
I hope this is a simple one.
I have trouble with monitor start messages:
dude@LON2-R96-01-re0 monitor start messages
{master}
dude@LON2-R96-01-re0
*** error - couldn't open 'messages' (Permission denied) - removed ***
{master}
dude@LON2-R96-01-re0
It is unclear to me whether this is a file permission issue, or a system
login configuration issue.
These are the rights I have:
dude@LON2-R96-01-re0 show configuration system login class noc-team-user
permissions
permissions [ access access-control admin configure firewall flow-tap
interface-control network routing security snmp-control system
trace-control view view-configuration ];
{master}
dude@LON2-R96-01-re0
Logging on with higher priviledges, I can start a shell and see that:
% ls -al /var/log/messages
-rw-rw 1 root wheel 316194 Jun 13 14:57 /var/log/messages
%
Strangely, a similar configuration works ok on an EX4200 (it is on a MX960
that it does not work).
Any idea?
Thanks,
Vincent
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] I've got some bone head problem on an srx...but I don't see it.
12.06.2013 08:59, Morgan McLean wrote: I rolled back and ran a ping to a host out on the net. Heres the trace...is the fact that its coming from junos-self screwing things up? The trace shows no src nat happened: Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.29.11, x_dst_ip 192.81.130.21, in ifp .local..0, out ifp N/A sp 8, dp 207, ip_proto 1, tos 0 [...] Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: dip id = 0/0, 192.168.29.11/8- 192.168.29.11/8 This means you were sending packets to the Internet from the source IP 192.168.29.11. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] I've got some bone head problem on an srx...but I don't see it.
Yes. the issue appears that I was not putting junos-self or junos-host at the source security zone for the nat rule. I have yet to try it, will test today. Thanks! Morgan On Thu, Jun 13, 2013 at 9:25 AM, Pavel Lunin plu...@senetsy.ru wrote: 12.06.2013 08:59, Morgan McLean wrote: I rolled back and ran a ping to a host out on the net. Heres the trace...is the fact that its coming from junos-self screwing things up? The trace shows no src nat happened: Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.29.11, x_dst_ip 192.81.130.21, in ifp .local..0, out ifp N/A sp 8, dp 207, ip_proto 1, tos 0 [...] Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False. Jun 11 21:51:22 21:51:21.1472397:CID-1:RT: dip id = 0/0, 192.168.29.11/8- 192.168.29.11/8 This means you were sending packets to the Internet from the source IP 192.168.29.11. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
It's the same on the MX series
I ended up with an open JTAC case because I'd configured bootp under
vrf's, but it wasn't working.
It needed to be configured under the base instance, as you've shown
here.
Perhaps something that Juniper should look at clarifying or expanding
on in the docs.
Cheers,
Gordon
On Thu, 13 Jun 2013 12:22:17 +0100, Phil Mayers wrote:
It's a J-series, not MX, but should be the same:
forwarding-options {
helpers {
bootp {
interface {
ge-0/0/2.2021 {
server x.x.x.x routing-instance BLAH;
...and
routing-instances {
BLAH {
instance-type vrf;
interface ge-0/0/2.2021;
Basically, you have to put the routing-instance on the server option,
matching the routing instance of the interface.
___
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] BOOTP helper on MX vrf
It's also now available on the SRX as of 12.1X44D10. One to watch though - Mac OSX and most other non-windows clients will fail to get an address from the JDHCP daemon because they set the BOOTP Unicast flag on all requests, whereas Windows will fall-back to broadcast after 30 seconds. The following command will fix it even though the text of the knob says the complete opposite of what it seems to do: set system services dhcp-local-server group BLAH interface BLAH overrides no-unicast-replies (or under your routing-instance) Ben On 13/06/2013, at 9:03 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: Hello, as I'm hearing conflicting information regarding bootp helper on MX routers in a vrf routing-instance, has anyone a working configuration? What I need: Forward DHCP broadcast requests from one vrf interface to a central DHCP server in the same VRF (classical bootp helper functionality). I don't want bootp helper on *every* interface, just a few. So any information regarding this is appreciated. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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
