[j-nsp] Issue with management and leaking routes

[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.....er....poor, unless
my brain is just stuck in a constant state of fart.

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

user at 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;
        }
    }
}


user at 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}
dball at 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}
user at 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}
user at 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}
dball at 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