Switching

Expand all | Collapse all

Configuration archival using host n routing-instance

Jump to Best Answer
  • 1.  Configuration archival using host n routing-instance

    Posted 10-05-2020 11:07

    Hi.

    I have two ex4600 that are running 18.4R3-S3 and I have activated the management routing-instance mgmt_junos.

    I have got it to work with RADIUS and SNMP without any issues, but when I'm trying to add archival of configuration using "transfer-on-commit" I draw a blank.

     

    There is a command that seemd to be promising:

    set system archival configuration routing-instance mgmt_junos

    But this seems to have no affect.

     

    When ever I try to add the archival site the following command:

    set system archival configuration archive-sites scp://networkEQ@172.xxx.xxx.xxx/ password "xxxx" 

    I get the following error message: "ssh: connect to host 172.xxx.xxx.xxx port 22: No route to host".

     

    I'm able to ping the SCP server using "ping 172.xxx.xxx.xxx routing-instance mgmt_junos", so the routing is working as expected.

     

    Have someone managed to get this to work?

     

    Best regards,

    Johan Christensson



  • 2.  Re: Configuration archival using host n routing-instance
    Best Answer

     
    Posted 10-05-2020 11:18

    The archival feature has (sadly) not been ported to support routing-instances.

     

    Only way to make this work is to have the route leaked into inet.0 so a lookup for the destination can be done.

    Alternately you need an external system which can connect to the IP in mgmt_junos and extract the configuration at regular intervals.



  • 3.  Re: Configuration archival using host n routing-instance

    Posted 10-07-2020 01:57

    Thanks for the quick reply.
    So, the setting "system archive configuration routing-instance" basically doesn’t so anything then?

    So what would be my best strategy here? The reason I activated the "management-instance" was because I have these two switches setup in a MC-LAG using the vlan approach, and I wanted to separate the management from the ICL/ICCP traffic.
    Should I have gone the other way around instead? Put the ICL/ICCP in a separate routing-instance, or maybe better yet, put each of them in their own routing-instance?

     

    Best regards,
    Johan Christensson