Re: [j-nsp] Stuck access-internal route

2010-09-10 Thread Bjørn Skovlund
Hi Nitzan,

I hope it's OK I copy the list on your reply, as it was very useful to
solve a single customer without impact on the rest.

In short, it works this way!

I'm still waiting on a servicewindow to solve the overall situation.

Cheers, Bjørn

2010/9/9 Nitzan Tzelniker nitzan.tzelni...@gmail.com:
 you can try to put the address on loopback and then remove it

 Nitzan

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] Issue with management and leaking routes

2010-09-10 Thread David Ball
Ts and MXs running 10.0R3.10.  inet.0 used only for loopback and interface
routes...all else go into MPLS VPNs.

  I have a remote MX that I have to manage in-band.  I've created lo0.1
which I add to a VRF, which terminates on an int facing our management
network.  I can SSH to the lo0.1 (VRF) int fine, but the NTP and SNMP
daemons seem to run on lo0.0 (whose IP is used for other things such as BGP
peering, LSP establishment, etc) and hence can't reach the management
network.  So, I leaked the lo0.0 IP into the VRF (see below) and leaked the
management network block into inet.0 in hopes of allowing my management
network to reach the NTP/SNMP daemons.  It doesn't appear to work as
expected.

  When I ping my lo0.0 (inet.0) IP address from my management network, the
lo0.1 (VRF) address provides the replies.  I have to think that this isn't
working the way it should.  Anyone seen this kind of thing before?

$ ping 1.7.*1.*35
PING 1.7.1.35 (1.7.*1.35*) 56(84) bytes of data.
64 bytes from 1.7.*3.35:* icmp_seq=1 ttl=62 time=9.93 ms
64 bytes from 1.7.3.35: icmp_seq=2 ttl=62 time=2.91 ms
64 bytes from 1.7.3.35: icmp_seq=3 ttl=62 time=2.77 ms

  Admittedly, my method of leaking routes isn't exactly standard (based on
mailing list and doc scrubbing), and I'm open to suggestions, but initially
I just wanted to see if the aforementioned behaviour should be expected
(ping an IP, get a reply from another IP).  That said, if someone has a
succinct explanation regarding how rib-groups work, I'd love to see it.  I
find this section of JUNOS docs uncharacteristically.erpoor, unless
my brain is just stuck in a constant state of fart.

  Relevant (I use that term loosely) config snippets follow.

u...@router#show int lo0
lo0 {
unit 0 {
description protocols IP;
family inet {
filter {
input secure-router;
}
address 1.7.1.35/32;
}
}
unit 1 {
description in-band mgmnt IP;
family inet {
filter {
input noc-access;
output noc-access;
}
address 1.7.3.35/32;
}
}
}


u...@router# show routing-options
nonstop-routing;
*interface-routes {
rib-group inet leak-lo0-to-mgmnt-vrf;
}*
static {
defaults {
retain;
install;
readvertise;
active;
as-path {
origin igp;
}
}
route 0.0.0.0/0 {
reject;
no-readvertise;
}
*route 192.168.8.0/23 {
next-table netmgmt_73IB.inet.0;
no-readvertise;
}*
}
rib-groups {
leak-lo0-to-mgmnt-vrf {
import-rib [ inet.0 netmgmt_73IB.inet.0 ];
import-policy leak-lo0-to-mgmnt-vrf;
}
}
autonomous-system 64555;
forwarding-table {
export load-balance-policy;
}

{master}
db...@clgrabflw01-re0 show route 1.7.1.35

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

1.7.1.35/32*[Direct/0] 14w1d 23:37:16
 via lo0.0

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

1.7.1.35/32*[Direct/0] 23:12:22
 via lo0.0

{master}
u...@router show route 192.168.8.0

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

192.168.8.0/23 *[Static/5] 01:42:57
  to table netmgmt_73IB.inet.0

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

192.168.8.0/23 *[BGP/170] 1w1d 08:58:49, localpref 100, from 1.7.1.29
  AS path: I
 to 1.7.2.38 via xe-1/3/0.0, Push 22, Push 300112(top)
[BGP/170] 1w1d 08:58:49, localpref 100, from 1.7.1.43
  AS path: I
 to 1.7.2.38 via xe-1/3/0.0, Push 22, Push 300112(top)

{master}
u...@router

And this, I don't understand at all.  the netmgmt_73IB routing-instance is
where the 192.168.8.0/23 is originating, yet traceroute fails with Op not
permitted ?  I do see entries in the forwarding table(s):

{master}
db...@clgrabflw01-re0 traceroute routing-instance netmgmt_73IB
192.168.9.1
traceroute to 192.168.9.1 (192.168.9.1), 30 hops max, 40 byte packets
traceroute: sendto: Operation not permitted
 1 traceroute: wrote 192.168.9.1 40 chars, ret=-1
 *traceroute: sendto: Operation not permitted
traceroute: wrote 192.168.9.1 40 chars, ret=-1
 *traceroute: sendto: Operation not permitted


David
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Centralized scripts and copying to redundant routing-engines..

2010-09-10 Thread Derick Winkworth
http://www.juniper.net/techpubs/software/junos/junos103/junos-xml-ref-oper/html/summary-oper-request107.html#2093716


You can write a script that will do it for you automatically  You can copy 
files between the REs from the CLI...






From: Chris Evans chrisccnpsp...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Thu, September 9, 2010 8:31:55 PM
Subject: [j-nsp] Centralized scripts and copying to redundant routing-engines..

I have a question, hopefully someone has an answer..


I have setup centralized stored commit scripts, however I'm running into
issues with devices (EX and MX) that have redundant routing-engines. The
files have to be on both RE's to successfully commit as I use commit sync.
How do I get the files on both RE's when using a central server??


The documentation says this: If a platform has dual Routing Engines, you
need to refresh the commit scripts on both Routing Engines. The commit
synchronize command does not refresh the commit scripts between Routing
Engines.


That is a very vague statement and gives no options on how to do it.. Also
the backup RE has no connectivity to the network, only the primary does.. So
how am I supposed to copy the files over?


Thanks


Chris
___
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