Prevent OSPF Default Information Originate

[alex.dersch]

Hi, 

i am setting up an SD WAN over a MPLS backbone. When configuring the OSPF process in vManage it always enables the default information originate even I set it to off. Which results that each Router injects a default route into the MPLS backbone. Any idea how to prevent the distribution of the default route?

thanks

Alex

[ekhabaro]

Can you please show us screenshot of configuration from vManage? 

Can you try to disable "always" first, update template and only then disable "originate" option?

Which version are you using?

[ekhabaro]

I opened DDTS to track this: CSCvp65817
Would be great if you can open TAC case for us to track this further as well.

[alex.dersch]

Hi, I have opened a case 686708665

thanks

Alex

[alex.dersch]

Hi,

we are using vManage 19.1.0, the routers are 4431 running code 16.11.1a.

I didn't find where I could disable always can you explain me how to do this?

[ekhabaro]

Hey Alex,

Unfortunately, it's a bug and the only way to disable this is to detach device from vManage and then remove "default-information originate" manually.

[alex.dersch]

Thanks, 

it's getting kinda frustrating, too many bugs in this system. I ran in another issue with a C1111 and the Default AAA template. It seems that C1111 doesn't support AAA commands used for a ISR44xx.

Best regards

Alex 

[ekhabaro]

Not sure what you mean, I need more details about this issue. There are no known issues with AAA template in 19.1.0

[alex.dersch]

Hey, sorry for my late response. 

When deploying the factory default aaa template to the C1111-8P I am getting this error

[13-May-2019 19:02:08 UTC] Configuring device with feature template: c1111-8p-default-template
[13-May-2019 19:02:08 UTC] Generating configuration from template
[13-May-2019 19:02:10 UTC] Checking and creating device in vManage
[13-May-2019 19:02:12 UTC] Device is online
[13-May-2019 19:02:12 UTC] Updating device configuration in vManage
[13-May-2019 19:02:16 UTC] Pushing configuration to device
[13-May-2019 19:04:16 UTC] Failed to process device request. Error response : rpc-reply error: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="13">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-message unknown:lang="en">inconsistent value: Device refused one or more commands</error-message>
<error-info>
<severity xmlns="http://cisco.com/yang/cisco-ia">error_cli</severity>
<detail xmlns="http://cisco.com/yang/cisco-ia">
<bad-cli>
<bad-command>aaa authentication login default local</bad-command>
<error-location>4</error-location>
<parser-response/> </bad-cli>
<bad-cli>
<bad-command>aaa authorization exec default local</bad-command>
<error-location>4</error-location>
<parser-response/> </bad-cli>
<bad-cli>
<bad-command> login authentication default</bad-command>
<error-location>7</error-location>
<parser-response/> </bad-cli>
</detail>
</error-info>
</rpc-error>
</rpc-reply>

I also tried to add those aaa commands in cli mode, with the same result. 

[ekhabaro]

Just reset config and start over. Most likely you configured something before you upgraded to SDWAN image, right? 

[alex.dersch]

Hey, I don't think so. It's a greenfield deployment. The router had never any config loaded. I just changed the code to 16.11.1a and connected it via ZTP to vManage. 

[alex.dersch]

it's good now. I had some issues in my brain I guess. The two routers didn't establish the tunnel over the MPLS link, simply because i had enabled control connections on the MPLS side interface. As i disabled it, the tunnels established like a charm.

I have one last issue with the rest of my routers. There are not yet connected to the MPLS and they are plugged in to the a switch in the same subnet. 

So the tunnel between those routers on the "internet" facing side are not getting up. I think it's because they try to establish a tunnel over the public ip they got from my firewall instead of connecting on the private ip address they have at the moment configured.

Any idea how to force them to establish a tunnel over their private ip address rather the public ip?

for example router 1 ip private 172.16.0.1 router 2 private address 172.16.0.2 and both have the public ip of 4.4.4.4

Rome wasn't built in a day

thanks

Alex

[Stefan Tiefel]

Hi,
how did you resolve this AAA problem?

I'm running into the same.

Kind regards

Stefan

[Simon Ko]

Just out of curiosity,
if you leave the setting at default setting, does it apply "default-information originate" statement?
On 16.9.5 and vManage 18.3.5, if I leave the setting default, it does not put the statement in.
I am finding issues on ISR on production units.

[alex.dersch]

it inserts default-information-originate in any way, regardless of leaving it at default, or set it to global