Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: juniper

out of band management - real OOB

 

 

nsp juniper RSS feed   Index | Next | Previous | View Threaded


chrisccnpspam2 at gmail

Sep 17, 2011, 5:14 AM

Post #1 of 17 (4464 views)
Permalink
out of band management - real OOB

Juniper devices have out of band ethernet ports, but have the HUGE HUGE
downfall of being in the main routing table conflicting with every other
route. This limits it usage, however a work around is to put the FXP
interface into a logical system (on support devices). This has downfalls
too, but its better than nothing. Unfortunately Juniper hasn't gotten this
clue yes, every other vendor I've used recently has full vrf/logical system
support for their OOB interfaces keeping them out of the main routing table.

One main downfall I'm running into is that I cannot copy or install software
using the FXP port as my source for traffic. Does anyone know of a command
that will allow me to select the logical system? The current commands don't
seem to allow routing instances or logical systems to be specified.

Something like: file copy logical-system:MGMT:ftp://blah/blah..

Anyone have any other workarounds. Thanks!
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


herro91 at gmail

Sep 17, 2011, 5:36 PM

Post #2 of 17 (4415 views)
Permalink
Re: out of band management - real OOB [In reply to]

Hi,

Don't know if this will work, but have you tried executing the "file copy"
command from within the logical system by "set cli logical-system blah" ?

if this works, i don't know if you can install software from that location
or not unfortunately.

On Sat, Sep 17, 2011 at 8:14 AM, Chris Evans <chrisccnpspam2 [at] gmail>wrote:

> Juniper devices have out of band ethernet ports, but have the HUGE HUGE
> downfall of being in the main routing table conflicting with every other
> route. This limits it usage, however a work around is to put the FXP
> interface into a logical system (on support devices). This has downfalls
> too, but its better than nothing. Unfortunately Juniper hasn't gotten this
> clue yes, every other vendor I've used recently has full vrf/logical system
> support for their OOB interfaces keeping them out of the main routing
> table.
>
> One main downfall I'm running into is that I cannot copy or install
> software
> using the FXP port as my source for traffic. Does anyone know of a command
> that will allow me to select the logical system? The current commands don't
> seem to allow routing instances or logical systems to be specified.
>
> Something like: file copy logical-system:MGMT:ftp://blah/blah..
>
> Anyone have any other workarounds. Thanks!
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


darren at bolding

Sep 17, 2011, 5:41 PM

Post #3 of 17 (4411 views)
Permalink
Re: out of band management - real OOB [In reply to]

Not an answer, but a related work-around I have used is to put everything
_else_ in a virtual router instance.

This, however, has other major limitations, such as network/tunnel VPN's
terminate in, and other features depend on inet0.

The management interface not having a separate routing instance, or at least
default route, is very annoying.

On Sat, Sep 17, 2011 at 5:36 PM, Herro91 <herro91 [at] gmail> wrote:

> Hi,
>
> Don't know if this will work, but have you tried executing the "file copy"
> command from within the logical system by "set cli logical-system blah" ?
>
> if this works, i don't know if you can install software from that location
> or not unfortunately.
>
> On Sat, Sep 17, 2011 at 8:14 AM, Chris Evans <chrisccnpspam2 [at] gmail
> >wrote:
>
> > Juniper devices have out of band ethernet ports, but have the HUGE HUGE
> > downfall of being in the main routing table conflicting with every other
> > route. This limits it usage, however a work around is to put the FXP
> > interface into a logical system (on support devices). This has downfalls
> > too, but its better than nothing. Unfortunately Juniper hasn't gotten
> this
> > clue yes, every other vendor I've used recently has full vrf/logical
> system
> > support for their OOB interfaces keeping them out of the main routing
> > table.
> >
> > One main downfall I'm running into is that I cannot copy or install
> > software
> > using the FXP port as my source for traffic. Does anyone know of a
> command
> > that will allow me to select the logical system? The current commands
> don't
> > seem to allow routing instances or logical systems to be specified.
> >
> > Something like: file copy logical-system:MGMT:ftp://blah/blah..
> >
> > Anyone have any other workarounds. Thanks!
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp [at] puck
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



--
-- Darren Bolding --
-- darren [at] bolding --
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jof at thejof

Sep 17, 2011, 7:04 PM

Post #4 of 17 (4417 views)
Permalink
Re: out of band management - real OOB [In reply to]

I agree with all of these points, and it's a pretty classic problem with
managing devices that route.

The path I've gone down in most setups I've done is to simplify.

I place all devices within a site within an "out of band" LAN/broadcast
domain, and setup one (or two, depending on HA requirements) management
host(s) on that LAN with a connection to a DSL or analog modem.
Then, I only use the management port with other directly-connected hosts and
avoid the routing problem all-together.

In the cases where constant connections need to be made (SNMP polling,
configuration auditing, etc.), I've setup NAT or port forwarding rules in
iptables or pf on the management host.

--j
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


andrew at parnell

Sep 19, 2011, 9:16 AM

Post #5 of 17 (4413 views)
Permalink
Re: out of band management - real OOB [In reply to]

On Sat, Sep 17, 2011 at 8:14 AM, Chris Evans <chrisccnpspam2 [at] gmail> wrote:
> One main downfall I'm running into is that I cannot copy or install software
> using the FXP port as my source for traffic. Does anyone know of a command
> that will allow me to select the logical system? The current commands don't
> seem to allow routing instances or logical systems to be specified.

A good workaround for this particular problem would be to scp the file
to the router, rather than trying to source the copy from the router
itself. I tested this in my lab and it works perfectly as far as I
can tell - for this particular task anyway. Of course the issue is
likely to pop up in other cases where traffic must be sourced from the
router itself (eg snmp traps, etc).

Andrew
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


plunin at senetsy

Sep 19, 2011, 1:42 PM

Post #6 of 17 (4406 views)
Permalink
Re: out of band management - real OOB [In reply to]

2011/9/17 Chris Evans <chrisccnpspam2 [at] gmail>

> Juniper devices have out of band ethernet ports, but have the HUGE HUGE
> downfall of being in the main routing table conflicting with every other
> route.
>


BTW, can anyone give a good real-world example of a _routed_ OOB management
network usage?

As far as I understand the whole concept of OOB MGT IP interface was
invented to make the management network totally isolated from any transit
traffic. For security concerns, at the days when firewalls were not trusty
enough, when lack of Internet connection was not that big issue. If you
really need to implement this, you won't run into any routing conflict,
since it's a really separated network, will you?

But. Nowadays not really many folks run separate PCs for OOB MGT totally
apart of their LAN, corporate environment, email, Internet, etc. Even though
some conservators may still desire this sort of design, most NMS need an
Internet connection to update something. In this case yes, you bump into a
routing conflict using fxp0, but why to use fxp0 in such a scenario?

An only exception I know of (looks like a real design flaw by Juniper) is
the SRX cluster case, where you MUST use fxp0 interfaces, if you want to
have access to particular members of a cluster. Otherwise you can only
access a virtual devise as a whole, with no clue which particular node you
connect to. Not so big problem in real world, to be honest, but if you are
required to connect it to, say, NSM, which goes to the Internet through this
same SRX cluster, you got a real pain in the rear (workarounds exist, of
course).

Sure, there are some good applications of fxp0 in field, but this does not
much relate to real routing issues.
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


plunin at senetsy

Sep 19, 2011, 1:57 PM

Post #7 of 17 (4406 views)
Permalink
Re: out of band management - real OOB [In reply to]

> As far as I understand the whole concept of OOB MGT IP interface


Sorry, really meant dedicated physical interfaces, of course.
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jof at thejof

Sep 19, 2011, 1:59 PM

Post #8 of 17 (4408 views)
Permalink
Re: out of band management - real OOB [In reply to]

On Mon, Sep 19, 2011 at 1:42 PM, Pavel Lunin <plunin [at] senetsy> wrote:

> 2011/9/17 Chris Evans <chrisccnpspam2 [at] gmail>
>
> > Juniper devices have out of band ethernet ports, but have the HUGE HUGE
> > downfall of being in the main routing table conflicting with every other
> > route.
> >
>
>
> BTW, can anyone give a good real-world example of a _routed_ OOB management
> network usage?
>
> As far as I understand the whole concept of OOB MGT IP interface was
> invented to make the management network totally isolated from any transit
> traffic. For security concerns, at the days when firewalls were not trusty
> enough, when lack of Internet connection was not that big issue. If you
> really need to implement this, you won't run into any routing conflict,
> since it's a really separated network, will you?
>
> But. Nowadays not really many folks run separate PCs for OOB MGT totally
> apart of their LAN, corporate environment, email, Internet, etc. Even
> though
> some conservators may still desire this sort of design, most NMS need an
> Internet connection to update something. In this case yes, you bump into
> a
> routing conflict using fxp0, but why to use fxp0 in such a scenario?
>
> An only exception I know of (looks like a real design flaw by Juniper) is
> the SRX cluster case, where you MUST use fxp0 interfaces, if you want to
> have access to particular members of a cluster. Otherwise you can only
> access a virtual devise as a whole, with no clue which particular node you
> connect to. Not so big problem in real world, to be honest, but if you are
> required to connect it to, say, NSM, which goes to the Internet through
> this
> same SRX cluster, you got a real pain in the rear (workarounds exist, of
> course).
>
> Sure, there are some good applications of fxp0 in field, but this does not
> much relate to real routing issues.
>

I see two ways one can go about this. Either programmatically tunnel into an
OOB L2 segment via a "bastion" host in an on-demand fashion, or point some
routes (dynamically, or otherwise) into your internal network for management
use.

The risk of pointing routes into your internal network, IMO, is that
very-specific ACLs for management access can begin to have a blurred
distinction. RFC-1918 space can overlap, and public IPs within an internal
network can sometimes overlap with an active transit path.

It's more work to script things to work nicely, but I believe the dynamic
tunneling method is the safer thing to do.
In the spirit of Junipers clean separation of the data and forwarding
planes, it seems too bad that they end up using the kernel routing table to
hold what goes in the forwarding hardware as well.

If you have the blessing of being able to have an all-J network, or one with
devices that all support multiple routing tables and routing protocol
separation (a la logical systems, or routing instance) -- setting up
separate routing tables for management vs. traffic-carrying is probably a
good thing.

--j

> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


morrowc at ops-netman

Sep 19, 2011, 2:04 PM

Post #9 of 17 (4404 views)
Permalink
Re: out of band management - real OOB [In reply to]

On 09/19/11 16:59, Jonathan Lassoff wrote:
>> BTW, can anyone give a good real-world example of a_routed_ OOB management
>> network usage?
>>
>> As far as I understand the whole concept of OOB MGT IP interface was
>> invented to make the management network totally isolated from any transit
>> traffic. For security concerns, at the days when firewalls were not trusty
>> enough, when lack of Internet connection was not that big issue. If you
>> really need to implement this, you won't run into any routing conflict,
>> since it's a really separated network, will you?
>>

how about like management networks on ss7 deployments?

It's really not that hard to conceive of a 'management card' on a
network device that can twiddle all of the network device's parts and
maintains a separate routing world from the production side of the hardware.

Hell, you could even envision something like this in the world of
servers: ilom (sun), drac (dell), hp-whatever-the-hell...

-chris

in 2011, we CAN have more than routing table on a single device, yes?
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


plunin at senetsy

Sep 19, 2011, 2:16 PM

Post #10 of 17 (4406 views)
Permalink
Re: out of band management - real OOB [In reply to]

> I see two ways one can go about this. Either programmatically tunnel into
> an OOB L2 segment via a "bastion" host in an on-demand fashion, or point
> some routes (dynamically, or otherwise) into your internal network for
> management use.
>
> The risk of pointing routes into your internal network, IMO, is that
> very-specific ACLs for management access can begin to have a blurred
> distinction. RFC-1918 space can overlap, and public IPs within an internal
> network can sometimes overlap with an active transit path.
>
>
Why not just use a normal port/vlan, plug it where you would've plug fxp0
to, and than put it to a vrf/whatever?
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jof at thejof

Sep 19, 2011, 3:38 PM

Post #11 of 17 (4407 views)
Permalink
Re: out of band management - real OOB [In reply to]

On Mon, Sep 19, 2011 at 2:16 PM, Pavel Lunin <plunin [at] senetsy> wrote:

>
>
>> I see two ways one can go about this. Either programmatically tunnel into
>> an OOB L2 segment via a "bastion" host in an on-demand fashion, or point
>> some routes (dynamically, or otherwise) into your internal network for
>> management use.
>>
>> The risk of pointing routes into your internal network, IMO, is that
>> very-specific ACLs for management access can begin to have a blurred
>> distinction. RFC-1918 space can overlap, and public IPs within an internal
>> network can sometimes overlap with an active transit path.
>>
>>
> Why not just use a normal port/vlan, plug it where you would've plug fxp0
> to, and than put it to a vrf/whatever?
>

On the internal side? This is one way about going about it. The question is,
what would the routing table on the device-to-be-managed look like? Just one
directly-connected route for the network segment it touches?

--j
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jof at thejof

Sep 19, 2011, 3:39 PM

Post #12 of 17 (4408 views)
Permalink
Re: out of band management - real OOB [In reply to]

On Mon, Sep 19, 2011 at 2:04 PM, Chris Morrow <morrowc [at] ops-netman>wrote:

>
>
> On 09/19/11 16:59, Jonathan Lassoff wrote:
>
>> BTW, can anyone give a good real-world example of a_routed_ OOB
>>> management
>>> network usage?
>>>
>>> As far as I understand the whole concept of OOB MGT IP interface was
>>> invented to make the management network totally isolated from any
>>> transit
>>> traffic. For security concerns, at the days when firewalls were not
>>> trusty
>>> enough, when lack of Internet connection was not that big issue. If you
>>> really need to implement this, you won't run into any routing conflict,
>>> since it's a really separated network, will you?
>>>
>>>
> how about like management networks on ss7 deployments?
>
> It's really not that hard to conceive of a 'management card' on a network
> device that can twiddle all of the network device's parts and maintains a
> separate routing world from the production side of the hardware.
>
> Hell, you could even envision something like this in the world of servers:
> ilom (sun), drac (dell), hp-whatever-the-hell...
>

This is the exact right way to go about this.

in 2011, we CAN have more than routing table on a single device, yes?


Certainly. Though plenty of older hardware did not do this for many years.

--j
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


plunin at senetsy

Sep 19, 2011, 5:02 PM

Post #13 of 17 (4419 views)
Permalink
Re: out of band management - real OOB [In reply to]

> how about like management networks on ss7 deployments?
>

Not sure I correctly understand how the analogy from IP world should look
like. I can imagine a network of, say, access devices whether L2 or L3, for
which OOB mgt is really needed. But I don't know much people who use
dedicated mgt ports for this, first because it's usually copper, second
because it requires a dedicated line. Most implementations I saw used the
mgt-vlan-based approach. We've even seen here a discussion on OSPF design
for this a couple of weeks ago. Yes, sure, I agree, it's a good idea to
place the correspondent RVI into a VR/VRF/whatever. Second, I am not sure
this device (even if it's L3 and fxp0 is used) needs to send any transit
packets towards the management machines, if so no problem with "routing
conflict".

> Hell, you could even envision something like this in the world of servers:
> > ilom (sun), drac (dell), hp-whatever-the-hell...
>

Yes, we have such a thing for routers. Called console port :)

BTW It's called iLO2 for HP. These toys usually require a license for
graphic support, JVM, weigh a couple hundreds of extra megabytes and is
totally different for different vendors. Not sure I want this in JUNOS :)
Moreover the copper 1G ports for this toys are becoming a problem for DCs
moving towards all-ten-gig.

in 2011, we CAN have more than routing table on a single device, yes?
>

I am not arguing, that support of software-based VRs for fxp0 in JUNOS would
be useful. I just can't understand why people want so much to plug the MGT
network right into the control plane. What for? Just because they paid for
this port on RE? Why not use a normal interface, which does not require any
additional wiring and you can put into VRF or anywhere you wish?
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


joelja at bogus

Sep 19, 2011, 5:42 PM

Post #14 of 17 (4414 views)
Permalink
Re: out of band management - real OOB [In reply to]

On 9/19/11 14:04 , Chris Morrow wrote:
>
>
> On 09/19/11 16:59, Jonathan Lassoff wrote:
>>> BTW, can anyone give a good real-world example of a_routed_ OOB
>>> management
>>> network usage?

yeah, I I find that oob networks larger than a /21 are sort of hard to
manage therefore we split them up into l3 segments.

>>> As far as I understand the whole concept of OOB MGT IP interface was
>>> invented to make the management network totally isolated from any
>>> transit
>>> traffic.

It is.

>>> For security concerns, at the days when firewalls were not
>>> trusty
>>> enough,

They still aren't.

when lack of Internet connection was not that big issue.

It isn't.

If you
>>> really need to implement this, you won't run into any routing conflict,
>>> since it's a really separated network, will you?
>>>

Ships in the night may still pass in some cases.

> how about like management networks on ss7 deployments?
>
> It's really not that hard to conceive of a 'management card' on a
> network device that can twiddle all of the network device's parts and
> maintains a separate routing world from the production side of the
> hardware.
>
> Hell, you could even envision something like this in the world of
> servers: ilom (sun), drac (dell), hp-whatever-the-hell...
>
> -chris
>
> in 2011, we CAN have more than routing table on a single device, yes?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


chrisccnpspam2 at gmail

Sep 21, 2011, 4:33 AM

Post #15 of 17 (4384 views)
Permalink
Re: out of band management - real OOB [In reply to]

From a data center perspective we use it for building more than anything.
We're using Nexus kit in our DC's mostly and they have full OOB support. Its
nice to be able to load code, configure, burn-in, etc.. before you bring the
container onto the core. All of the benefits after the fact are just a
plus.

On Mon, Sep 19, 2011 at 8:42 PM, Joel jaeggli <joelja [at] bogus> wrote:

> On 9/19/11 14:04 , Chris Morrow wrote:
> >
> >
> > On 09/19/11 16:59, Jonathan Lassoff wrote:
> >>> BTW, can anyone give a good real-world example of a_routed_ OOB
> >>> management
> >>> network usage?
>
> yeah, I I find that oob networks larger than a /21 are sort of hard to
> manage therefore we split them up into l3 segments.
>
> >>> As far as I understand the whole concept of OOB MGT IP interface was
> >>> invented to make the management network totally isolated from any
> >>> transit
> >>> traffic.
>
> It is.
>
> >>> For security concerns, at the days when firewalls were not
> >>> trusty
> >>> enough,
>
> They still aren't.
>
> when lack of Internet connection was not that big issue.
>
> It isn't.
>
> If you
> >>> really need to implement this, you won't run into any routing
> conflict,
> >>> since it's a really separated network, will you?
> >>>
>
> Ships in the night may still pass in some cases.
>
> > how about like management networks on ss7 deployments?
> >
> > It's really not that hard to conceive of a 'management card' on a
> > network device that can twiddle all of the network device's parts and
> > maintains a separate routing world from the production side of the
> > hardware.
> >
> > Hell, you could even envision something like this in the world of
> > servers: ilom (sun), drac (dell), hp-whatever-the-hell...
> >
> > -chris
> >
> > in 2011, we CAN have more than routing table on a single device, yes?
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp [at] puck
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


joelja at bogus

Oct 30, 2011, 8:29 PM

Post #16 of 17 (4372 views)
Permalink
Re: out of band management - real OOB [In reply to]

Sorry, this is late, as far as this thread goes but I think I'd add one
more thing since I've got oob networks big enough to have to add l3
boundries in them...

juniper's not the only vendor with this issue by far...

On 9/19/11 13:59 , Jonathan Lassoff wrote:
> On Mon, Sep 19, 2011 at 1:42 PM, Pavel Lunin <plunin [at] senetsy> wrote:
>
>> 2011/9/17 Chris Evans <chrisccnpspam2 [at] gmail>
>>
>>> Juniper devices have out of band ethernet ports, but have the HUGE HUGE
>>> downfall of being in the main routing table conflicting with every other
>>> route.
>>>
>>
>>
>> BTW, can anyone give a good real-world example of a _routed_ OOB management
>> network usage?
>>
>> As far as I understand the whole concept of OOB MGT IP interface was
>> invented to make the management network totally isolated from any transit
>> traffic. For security concerns, at the days when firewalls were not trusty
>> enough, when lack of Internet connection was not that big issue. If you
>> really need to implement this, you won't run into any routing conflict,
>> since it's a really separated network, will you?
>>
>> But. Nowadays not really many folks run separate PCs for OOB MGT totally
>> apart of their LAN, corporate environment, email, Internet, etc. Even
>> though
>> some conservators may still desire this sort of design, most NMS need an
>> Internet connection to update something. In this case yes, you bump into
>> a
>> routing conflict using fxp0, but why to use fxp0 in such a scenario?

So, I have a routed oob, and proxy-arp is your friend. the netmask on
the management interface needs to be big enough to cover your whole oob
network... organizing your addresses space such that this is feasible is
left as an exercise for the reader.

>> An only exception I know of (looks like a real design flaw by Juniper) is
>> the SRX cluster case, where you MUST use fxp0 interfaces, if you want to
>> have access to particular members of a cluster. Otherwise you can only
>> access a virtual devise as a whole, with no clue which particular node you
>> connect to. Not so big problem in real world, to be honest, but if you are
>> required to connect it to, say, NSM, which goes to the Internet through
>> this
>> same SRX cluster, you got a real pain in the rear (workarounds exist, of
>> course).
>>
>> Sure, there are some good applications of fxp0 in field, but this does not
>> much relate to real routing issues.
>>
>
> I see two ways one can go about this. Either programmatically tunnel into an
> OOB L2 segment via a "bastion" host in an on-demand fashion, or point some
> routes (dynamically, or otherwise) into your internal network for management
> use.
>
> The risk of pointing routes into your internal network, IMO, is that
> very-specific ACLs for management access can begin to have a blurred
> distinction. RFC-1918 space can overlap, and public IPs within an internal
> network can sometimes overlap with an active transit path.
>
> It's more work to script things to work nicely, but I believe the dynamic
> tunneling method is the safer thing to do.
> In the spirit of Junipers clean separation of the data and forwarding
> planes, it seems too bad that they end up using the kernel routing table to
> hold what goes in the forwarding hardware as well.
>
> If you have the blessing of being able to have an all-J network, or one with
> devices that all support multiple routing tables and routing protocol
> separation (a la logical systems, or routing instance) -- setting up
> separate routing tables for management vs. traffic-carrying is probably a
> good thing.
>
> --j
>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


deathpacket at gmail

Oct 30, 2011, 10:57 PM

Post #17 of 17 (4287 views)
Permalink
Re: out of band management - real OOB [In reply to]

All,

Juniper does allow you to use a specific route table for management, it's
inet.0. You then create a VR, and place all your transit ports in the VR.
Ideal would be to do the reverse of that, create a VR and put the mgmt
ports in the VR, but it is not supported today. Still it is doable without
Logical systems.

-DP




On Sat, Sep 17, 2011 at 7:14 AM, Chris Evans <chrisccnpspam2 [at] gmail>wrote:

> Juniper devices have out of band ethernet ports, but have the HUGE HUGE
> downfall of being in the main routing table conflicting with every other
> route. This limits it usage, however a work around is to put the FXP
> interface into a logical system (on support devices). This has downfalls
> too, but its better than nothing. Unfortunately Juniper hasn't gotten this
> clue yes, every other vendor I've used recently has full vrf/logical system
> support for their OOB interfaces keeping them out of the main routing
> table.
>
> One main downfall I'm running into is that I cannot copy or install
> software
> using the FXP port as my source for traffic. Does anyone know of a command
> that will allow me to select the logical system? The current commands don't
> seem to allow routing instances or logical systems to be specified.
>
> Something like: file copy logical-system:MGMT:ftp://blah/blah..
>
> Anyone have any other workarounds. Thanks!
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

nsp juniper RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.