Discovering changes in topology table

[s_milidrag]

Hello Checkmates,

What is the difference between "Get Interface Without Topology" and "Get Interface With Topology"  ?

What will firs and what will second option do ?

When to use "Get Interface With Topology" and when "Get Interface Without Topology" in discovering topology changes.

I have R80.20

[Mark_Mitchell]

Hi Slobodan,

The get Interfaces with topology option will interrogate the gateway to retrieve the interfaces, it will also calculate the topology and also set the interfaces (this network only etc) for the purposes of anti-spoofing based on the routing table .

Using only the "Get Interfaces without topology" will get all interfaces without changing your existing topology. 

From experience I only use the "with" option when configuring a new gateway. As performing a topology get on an existing gateway/cluster may change your desired topology if you have set some specific spoofing groups up. 

Personally I like to control the topology and will more than likely make changes to the topology even when using the "with topology:" option. 

Hope this helps. 

Cheers

Mark

[s_milidrag]

Thanks Mark,

I've noticed in a case I have changes in routing (add static routes) and run "Get Interface Without Topology", gateway will not update topology table, so I need to run "Get Interface With Topology" 

[Maarten_Sjouw]

Slobodan, even though this might look fancy and is easy when you add routes, however, did you see how these networks are created in the objects database? Irrelevant if the network already exists or not a new network object is created in a semi-hidden state. What I mean by that is that you cannot add that network to a access rule or a group as it just does not show up in the listing. So later on when that network is removed from your environment, your stuck with a hidden object for a non existing network.

In a network with many changes this is not something you want 

Specifically in Cluster environments I would not use the With topology option, as mentioned by  Vladimir Yakovlev below.

[Mark_Mitchell]

Happy to help. 

Yes, if you are using the "Determine Topology based on route table" setting under the gateway/cluster that is correct otherwise then topology needs to be defined manually .

Cheers

Mark

[Vladimir]

On existing production gateway or cluster, the difference between "Get Interface Without Topology" and "Get Interface With Topology" is typically 2 to 4 hours of troubleshooting

Seriously though, when you already have manually defined topology and antispoofing settings, the "With Topology" may wreck a havoc on your infrastructure. See this thread for example: Cluster Sync lost after Get Interfaces with topology 

It may also create a duplicate network objects.

[AlekseiShelepov]

I totally agree.

The safest way is to choose "without topology" for existing devices. If there are some legacy configurations, if some part of the network is not documented, if there are many people managing firewalls, if there are just many vlans, better to just add manually the new network to the group.

Also, adding to duplicate objects, you can have some naming convention that this automatic retreival will not care about, of course.

[Support_Team_Pi]

Hi Vladimir,

So what happens if you don't use neither of the options, but just create manually and then policy push?
When testing this, it seems like the topology information where specific groups were defined before adding new VLAN interface are now disappeared and I am seeing anti-spoofing blocks on entirely different interfaces than the new ones I added..

Any idea?

KC.