IOS-XR: EIGRP passive-interface default?

Garry Peirce · ‎04-11-2013

It appears there's no ability to make all interfaces passive by default in XR as there is in IOS.

Is there a reason for this or is it just that it has not been included yet?

Workaround is to configure all unnecessary interfaces as passive but I prefer to have all passive and then only enabled where needed.

TIA,

xthuijs · ‎04-13-2013

Garry, correct there is no such thing that I see, nor do I see it filed as an enhancement request either.

If it is important to you, I can file a request to have this added to the IOS-XR Eigrp implementation.

regards

xander

Garry Peirce · ‎04-16-2013

Sure , appreciate if you could inquire about doing so.

I find it an easier way to go, unless there is some reason I'm unaware of.

Perhaps due to this which I found in the EIGRP XR doc?

Passive—Advertises connected prefixes but does not form adjacencies. The passive command is used to configure interfaces as passive. Passive interfaces should be used sparingly for important prefixes, such as loopback addresses, that need to be injected into the EIGRP domain. If many connected prefixes need to be advertised, then the redistribution of connected routes with the appropriate policy should be used instead.

I'd be interested in further detail on that recommendation - as well as what magnitude constitutes 'many' (10,100,1000?)

thanks,

xthuijs · ‎04-16-2013

Hi Gary,

I filed request CSCug38048 for this. It may take a day or so for it to show up in teh bug toolkit, but then you have something for tracking. I dont have a definitive release for this either, but I am trying to see if we can do this short(er) term.

As for the other question on the use of passive sparingly. I don't necessarily agree with that statement. Passive is very useful to include prefixes in the advertisement, but to prevent forming adj. Loopbacks are to be made passive, because it is a waste of cpy cycles trying to generate a hello on that stub interface and then drop it in software. Passive is the proper solution. Same thing with access facing interfaces that dont need adj to the CE's, but have to be included in the routing.

The alternative of using redistribute connected is indeed an option, but the disadvantage for that is that it creates EXTERNAL routes, in both OSPF and EIGRP, with different metric calculations.

The magnitude of "many" in this regard is dependent on the number of times you don't mind configuring "passive-interface" under the eigrp enabled interface configuration. For me personally that would be about 20

What I mean to say is, it is not dependent on a scaling limitation or anything other then operator/user.

cheers!

xander

Garry Peirce · ‎04-17-2013

Great thanks xander.

xthuijs · ‎04-17-2013

Gary, I received some feedback from our EIGRP development group on the ddts that I filed and they had a suggestion that might be workable for you. It is part of the flex CLI capability that is in XR43.

Is this an acceptable solution to you?

regards

xander

group G-EIGRP-Passive

router eigrp '.*'

address-family ipv4

interface 'Gig.*'

passive-interface

!

end-group

Garry Peirce · ‎04-17-2013

Perhaps, but I'm not sure I understand this config.

I've no problem if method/syntax is different from IOS as XR has that anyhow.

I'm running 4.30, but the config parser seems unaware of the top-level 'group' command.

Is the asterisk actually a wildcard (regex?) or are you saying that all passive interfaces would just be listed under this group definition?

If the former, would the use of a full interface name (more specific) override the wildcard config?

megathumpzilla · ‎09-24-2013

In IOS, eigrp applies globaly to addreeses primarily.

In IOSxr, an interface is added into an EIGRP route process.

Would your solution be to not add interfaces to EIGRP that you don't want to participate?

xthuijs · ‎09-24-2013

You not add that interface under the router eigrp address-family group.

we dont use a network statement in XR to pull in interfaces, you only need to insert those interfaces you want to run EIGRP on, regardless of their address (much easier).

By not adding the interface, you are not sending or processsing received eigrp packets.

xander

Garry Peirce · ‎01-02-2014

Just a followup as I've now an ASR9k that can run the aforementioned top-level 'group' command now.

re: megathumpzilla's note, by excluding the interface within the EIGRP process, that interface's prefix(es) will not be included in EIGRP topology, hence the desire to enable the interface in the topology but make it passive.

group G-EIGRP-Passive

router eigrp '.*'

address-family ipv4

interface 'Te.*'

passive-interface

!

interface 'Gig.*'

passive-interface

!

interface 'Loopback.*'

passive-interface

!

interface 'Bundle-Ether10\..*'

passive-interface

!

end-group

(speaking of grouping, in homage to Buzz Macallister ).

a) Although this group config is now configured, it doesn't seem to be having any effect whatsoever - ?

2) Not sure it's all that much simpler as the number of interface types grow. Also, the group stanza is far from near routing section in the config and could become 'hidden'.

D) I'd still vote for the ol' IOS global 'passive default' with explicit per-interface 'no passive' as it's fewer config lines.

All would be in the same section and be visibly deterministic on how it should be working.

xthuijs · ‎01-02-2014

hi Gary,

thanks for the follow up, yes I recognize that and I havea ddts open for that command taht I filed last time we spoke on that. You can track CSCug38048

Currently I have no determined release for that, but I'll check in with the respective owner/development manager to see when this can be done realistically.

regards

xander

Garry Peirce · ‎01-06-2014

re: CSCug38048 - right, yes thanks.

No great rush on my side, just a method I think worth restoring.

Garry Peirce · ‎04-03-2015

Now running 5.3.0 - just an update that sadly CSCug38048 has not seemed to have been addressed yet.

The workaround is per-interface passive config but also noting this is compounded when v6 is in use as well.

xthuijs · ‎04-03-2015

aik I just checked the ddts and I see that nothing serious has happened on this.

I have pulled this one into my usability program just now as I had in all honestly totally forgotten about it and expected the system to do its job, but I guess that was the wrong thing to do :)

Getting some answers on it now, standby.

xander

Garry Peirce · ‎07-01-2015

Having a reason to revisit this topic, the group config workaround works to an extent, but within the routing protocol config you still have to enable every interface to make it applicable. With a sizable config (multiple hundreds of interfaces) , this makes for a quite long/ugly config.

Ideally within a routing protocol it'd be nice to use a regexp to enable interfaces.

Although the group method could then be used to apply per-int configurations, why not just apply it here as I still think the group method, which sits well away the routing protocol config ,can become hidden.

ex.

router <routing protocol>

passive-interface default (reduce cpu cycles creating unnecesary HELLOs)

interface Be3\.*[1-3]{3} (interfaces BE3.100-399)

passive-interface

interface BE3.200 (overrides being more specific than the above)

no passive-interface