Looking for better understanding of ifgroup default group

Hi Dynamox,

I'm not a ddboost expert so engaged one of my colleagues to help answer your question.

> I am setting up a brand new DD9500 that will be used by Avamar/DDBoost for RMAN.  I have been looking through a lot of documentation on ifgroups/ddboost and while i can see a lot of  explanation on ifgroups/clients i don't see anything that explains how default group works.

> Let's say i have 3 groups:

> dmz  192.168.150.1, 192.168.150.2 (client 192.168.1.0/24)

> private 192.168.160.1, 192.168.160.2 (client 192.168.2.0/24)

> default 192.168.170.1, 192.168.170.2  (client *)

> also this is set : system.ENFORCE_IFGROUP_RW=TRUE

So first lets, just cover what ENFORCE_IFGROUP_RW does.

It's probably best to look at the ddboost admin guide for an explanation incase anyone else is following this thread.

From https://support.emc.com/docu61771_Data_Domain_Boost_for_OpenStorage_3.2.1_Administration_Guide.pdf?language=en_US :

================================================

From page 25:

Interface Enforcement

The Dynamic Interface Group (DIG) feature gives you the ability to enforce private network

connectivity, ensuring that a failed job does not reconnect on the public network after

network errors. When interface enforcement is enabled, a failed job can only retry on an

alternative private network IP address. Interface enforcement is only available for clients

that use DIG interfaces.

Interface enforcement is off (FALSE) by default. To enable interface enforcement, you

must add the following setting to the system registry:

system.ENFORCE_IFGROUP_RW=TRUE

Note

In the previous example, ifgroup refers to the interface group.

After you've made this entry in the registry, you must do a filesys restart for the

setting to take effect.

The following illustration shows the decision flow for DIG connections. If interface

enforcement is on (TRUE), the system always attempts to reconnect on a private IP

address when a job fails. If a private IP address is not available, the job is canceled, and

a Cancel job for non-ifgroup interface error message is generated. If

interface enforcement is off (FALSE), a failed job resumes using a public IP address.

================================================

> 1) so let's say i am trying to connect from 192.168.3.0/24 subnet. Since my subnet is not

> matching any clients will i be denied connectivity or i will allowed to connect to interfaces in default subnet ?

Since the default ifgroup has been configured with “*” (all clients), that client will be allowed connectivity to that ifgroup.

> 2) so let's say i am trying to connect from 192.168.1.0/24 subnet. Since my subnet is matching

> dmz group will i be allowed to connect to interfaces in dmz group only  or dmz and default interfaces ?

dmz only as the client will be “caught” in the rules explained above.

> Basically trying to figure out if "default" group is like a "catch all" group that if none of

> the groups are  matched, connect to default group.

The “*” is not a catch all group as such but a group that will catch what hasn’t been caught by all previous (in the group selection) rules.

The exact order In which the group selection will occur (again extracted from the ddboost guide above):

================================================

A Dynamic Interface Group (DIG) client is a member of a single interface group

and may consist of:

- A fully qualified domain name (FQDN) such as ddboost.datadomain.com

- Wild cards such as *.datadomain.com or “*”

- A short name for the client, such as ddboost

- Client public IP range, such as 128.5.20.0/24

Prior to write or read processing, the client requests a DIG IP address from the server. To

select the client DIG association, the client information is evaluated according to the

following order of precedence (see Figure 6 on page 27):

1. IP address of the connected Data Domain system. If there is already an active

connection between the client and the Data Domain system, and the connection

exists on the interface in the DIG, then the DIG interfaces are made available for the

client.

2. Connected client IP range. An IP mask check is done against the client source IP; if

the client's source IP address matches the mask in the DIG clients list, then the DIG

interfaces are made available for the client.

- For IPv4, xx.xx.xx.0/24 (128.5.20.0/24 in Figure 6 on page 27) provides

a 24-bit mask against the connecting IP. The /24 represents what bits are masked

when the client's source IP address is evaluated for access to the DIG. For IPv4,

16, 20, 24, 28, and 32 bit masks are supported.

- This host-range check is useful for separate VLANs with many clients where there isn't

a unique partial hostname (domain).

3. Client Name: abc-11.d1.com

4. Client Domain Name: *.d1.com

5. All Clients: *

================================================

I hope this helps explain things further?

cheers, Rich.

My Answers Inline,

1) so let's say i am trying to connect from 192.168.3.0/24 subnet. Since my subnet is not matching any clients will i be denied connectivity or i will allowed to connect to interfaces in default subnet ? as you have set this value system.ENFORCE_IFGROUP_RW=TRUE, then the backup will fail. Due to this setup fallback mechanism would not work.

2) so let's say i am trying to connect from 192.168.1.0/24 subnet. Since my subnet is matching dmz group will i be allowed to connect to interfaces in dmz group only  or dmz and default interfaces ? It depends on the clients. If the client falls under DMZ group then all the backup will go through DMZ.

thank you for your feedback, i have done some extensive testing this weekend (using ddpconnchk utility) and will reply to my own questions. Keep in mind that dmz, private and default groups in my example are separated by firewalls, they can't talk to each other

1) so let's say i am trying to connect from 192.168.3.0/24 subnet. Since my subnet is not matching any clients will i be denied connectivity or i will allowed to connect to interfaces in default subnet ?

Just like Gautam mentioned this backup fails. My client does not match any client lists so it  tries to connect to interface in default group but since it's in a default group and there is a firewall between us, the client tries to go back to the "registered interface" and this "bounce back" is blocked by system.ENFORCE_IFGROUP_RW=TRUE.

In this same scenario if default group is empty even though client does not match any groups it uses registered interface, even though system.ENFORCE_IFGROUP_RW=TRUE is in place.  For some reason i expected this to be blocked as well.

2) so let's say i am trying to connect from 192.168.1.0/24 subnet. Since my subnet is matching dmz group will i be allowed to connect to interfaces in dmz group only  or dmz and default interfaces ?

i think we all agree on this one and my testing shows that as well, we are simply connecting to the group that matches our client.

Thanks for the update Dynamox. I'm going to feed this back to the person I contacted regarding your initial question.

Rich,

I actually prefer that with default group being empty, it allowed client connectivity on the registered interface even though "system.ENFORCE_IFGROUP_RW=TRUE" is in place.

I suspect that it's a bug in DDOS 5.7 where you don't allow clients to be added in any format other than /24 , by allowing connectivity to at least my registered interface i can move forward with my implementation. Once you add support for /23, /25, /26 ..etc, i will be able to add my client subnets to correct group and route traffic to interfaces that belong to dynamic ip groups.

Hi Dynamox,

Do you have a support contract with EMC as my ddboost colleague is interested in looking at your configuration etc live via a WebEx, which we can only offer if you have a valid support contract in place?

If so, raise a support case, let me know the support case reference and i'll engage my colleague directly.

cheers, Rich.

i think we have a slight misunderstanding there with question #1.  Host does not match any client lists so it tries to connect to default group, it is my firewall that is preventing that connectivity, not the DD. Since the host cannot get to any IPs in default group, it tries to "jump" back to registered interface and it gets blocked by ENFORCE_IFGROUP_RW=TRUE.  To me it sounds it's working as designed ?

Rich,

I do have a support contact, what part of my config is your ddboost colleague interested in ?

Hi Dynamox,

> what part of my config is your ddboost colleague interested in?

Actually it all stems from your question (1) above really. He mentioned that he still thinks it should function the way as per my reply. However he did mention there have been changes between DDOS's in regards to this functionality, so wanted to look at your configuration live and see the issue - to ensure it's not a bug.

cheers, Rich.

Thanks Dynamox for the clarification.

My ddboost colleague agrees that it was a misunderstanding, so yes, it appears it's working as designed.

Jonathan,

i don't think so either, i am on DDOS 5.7.2

Any correlation between RPF and my issue with SBS DDOS Source Based Routing ?

Apologies for the delayed reply - was on vacation.

It's far from something I am massively familiar with but...

I think when we refer to "source routing" we are basically talking about RPF, this can be set in strict, loose etc... We had enforced "strict" and that can catch people unawares, this is entirely to do with static routes on the DD.

What I think you are hoping to leverage is "source routing" where you state in the packet 'what path you want it to take'.

I don't think DD can leverage that, we don't appear to support the 2 IP header options that would state the path without a route on the DD to force it.

Source based (on DD) refers to RPF and that it will always try to reply on the path you want where a static route exists, when there is no static route, then it will use the only stated route - which is the default gateway and so you DO get a reply (with your 5.7.2.0) but it's not the path you want - with strict RPF you would get no reply because there was an attempt by EMC to protect the DD by implementing this strict RPF into asymmetric routing environments.

I have to agree that it's easy to confuse the 2 entirely different methods in the admin guide but from the other thread, it seems that what you see and experience on your DD, entirely supports this being the case.

As I say, this is not something I've played with much, so apologies if I've gone 'off piste' on your question.

Note; will post this here and in your other thread topic - you can reply on either if you have further questions.

Regards, Jonathan