Control-Plane Configuration

[Evan Roggenkamp]

I do not understand why the router will not allow me to add this configuration:

configure terminal
do terminal monitor
control-plane
 management-plane
  inband
    interface all
    allow SNMP peer
     address ipv4 1.2.3.4
    allow SSH peer
     address ipv4 1.2.3.4
  out-of-band
   vrf OOB-MGMT
   interface all
    allow SSH peer
     address ipv4 1.2.3.4
    !
   !
  !
 !
!
root

"!!% 'MPP Server Process' detected the 'fatal' condition 'Interface configured/used in other band'"

To me this does not make logical sense - why was this built this way?

Is there any way around it without specifying EVERY interface individually in both the inband and out-of-band configuration?

[Aleksandar Vidakovic]

hi Evan,

effectively the only out-of-band interfaces are the MgmtEth on the R(S)P. I don't think that anyone is using any other interface as out-of-band. So in the out-of-band config section you only need to configure the MgmtEth, while you can use "interface all" in the inband section.

Regards,

Aleksandar

[Evan Roggenkamp]

This is what I thought too but consider the following ASR config:

control-plane
 management-plane
  inband
   interface all
    allow SNMP peer
     address ipv4 1.1.1.1
    !
   !
  !
  out-of-band
   vrf OOB-MGMT
   interface MgmtEth0/RSP0/CPU0/0
    allow SSH peer
     address ipv4 1.1.1.1
     address ipv4 2.2.2.2
     address ipv4 3.3.3.3
     address ipv4 4.4.4.4
    !
   !
  !
 !
!

I try to update this using adding

configure terminal 
control-plane
 management-plane
  inband
   interface all 
    allow SSH peer
     address ipv4 1.1.1.1
     address ipv4 2.2.2.2
     address ipv4 3.3.3.3
     address ipv4 4.4.4.4
     address ipv4 5.5.5.5
    !
   !  
 !

The router will not accept this. I just want to add these IP's so I can access the ASR via loopback as well as OOB as OOB will be going away. 

control-plane
 management-plane
  inband
   interface all
    allow SSH peer
     address ipv4 1.1.1.1
!!% 'MPP Server Process' detected the 'fatal' condition 'Interface configured/used in other band'
    !
   !
  !
 !
!
end

[Aleksandar Vidakovic · Accepted solution]

Can you try this as workaround:

group Inband
 control-plane
  management-plane
   inband
    interface 'TenGigE*'
     allow TFTP
    !
    interface 'GigabitEthernet*'
     allow TFTP
    !
   !
  !
 !
end-group
!
control-plane
 management-plane
  inband
   apply-group Inband
  !
  out-of-band
   interface MgmtEth0/RSP0/CPU0/0
    allow SSH
    allow TFTP
   !
  !
 !
!

[Evan Roggenkamp]

Aleksandar Vidakovic this is a good workaround to keep the configuration clean and after testing it worked for me and so I thank you and I have marked this answer correct. Cheers.

[Aleksandar Vidakovic]

I'm happy to hear you found the workaround feasible. Thanks for sharing the feedback!!
 

[Evan Roggenkamp]

Aleksandar I am afraid I am still fighting with this

I have a baseconfig that is working well on 90% of my routers. However with a few, there is trouble: (This is an ASR 9001)

control-plane
 management-plane
  inband
   interface Loopback0
    allow SSH peer
     address ipv4 <address_1>
     address ipv4 <address_2>
    !
    allow SNMP peer
     address ipv4 <address_1>
    !
   !
   interface TenGigE0/0/2/0
    allow SSH peer
     address ipv4 <address_1>
     address ipv4 <address_2>
    !
    allow SNMP peer
     address ipv4 <address_1>
    !
   !
   interface TenGigE0/0/2/1
    allow SSH peer
     address ipv4 <address_1>
     address ipv4 <address_2>
    !
    allow SNMP peer
     address ipv4 <address_1>
    !
   !
   interface TenGigE0/0/2/2
    allow TFTP
   !
  !
  out-of-band
   vrf OOB-MGMT
   interface MgmtEth0/RSP0/CPU0/0
    allow all
   !
  !
 !
!

When I try to add the new configuration using the group, I am unable to poll the loopback IP address or SSH to it:

configure terminal
do terminal monitor
group inband
 control-plane
  management-plane
   inband
    interface 'TenGigE*'
     allow SSH peer
      address ipv4 <address_1>
      address ipv4 <address_2>
     !
     allow SNMP peer
      address ipv4 <address_3>
     !
    !
   !
  !
 !
!
end-group
!
control-plane
 management-plane
  inband
   no interface all
   !
   no interface Loopback0
   !
   no interface TenGigE0/0/2/0
   !
   no interface TenGigE0/0/2/1
   !
   no interface TenGigE0/0/2/2
   !
   no interface TenGigE0/0/2/3
   !
   apply-group inband
   !
 out-of-band
  vrf OOB-MGMT
   interface MgmtEth0/RSP0/CPU0/0
    no allow all
    allow SSH peer address ipv4 <address_1>
    allow SSH peer address ipv4 <address_2>
  !
 !
!
root
!

Note that when I leave the "allow all" under the OOB control-plane configuration, I can still SSH to the loopback. 

This almost feels like a bug. SSH/SNMP to Loopback should not depend on configuration of the OOB control-plane.

[Aleksandar Vidakovic]

Hi Evan,

the model of the asr9k doesn't matter, from SW forwarding architecture point they are all identical. What matters is the base XR release and SMUs/SPs that are installed. Are they the same on the working and non-working routers?

To understand what was programmed in LPTS based on the control-plane config, please check the

sh lpts pifib brief
sh lpts pifib hardware police location <location>

That should help confirm whether the programming matches what you expected based on the config.

/Aleksandar

[Evan Roggenkamp]

Aleksandar

Yes, this is the strange thing - packages and SMU's are exactly the same. 

Thanks

[Aleksandar Vidakovic]

hi Evan,

please compare the two output sets before and after the config change:

sh lpts pifib brief
sh lpts pifib hardware police location <location>

That should help understand the behaviour.

Regards,

Aleksandar

[elesani]

You can configure a interface as either inband OR outband , under inband you are doing "interface all "which includes mgmtEth 0/RSP0/CPU0/0. So while configuring under outband its failing.

Thanks,

Ehsan

[Evan Roggenkamp]

Yes, this confirms my suspicions - I was under the impression that "interface all" would not include mgmtEth as they are essentially out of band interfaces. It is unfortunate this was designed this way as it makes the configuration more difficult to maintain and keep "clean," but it is as it is and I appreciate you pointing this out. 

[Evan Roggenkamp]

.