SRX conflicting entry

[google]

SRX conflicting entry

[finfinack]

[Haven't followed threads here for a while but just saw this coming in and decided to have a look.]

This is is a specific check in the junipersrx.py:

       for application_set in self.applications:
          if (term.name == application_set['name'] and
              new_application_set != application_set):
            raise ConflictingApplicationSets(
                'Application set %s has a conflicting entry' % term.name)

https://github.com/google/capirca/blob/master/lib/junipersrx.py#L481

This specifically checks for all policy names that over all policy terms globally, none has the same name.

Just now I don't have an SRX handy to check whether policy names have to be unique just within a scr/dst zone tuple or globally. I tried to find some Juniper docs but didn't find anything conclusive:
http://www.juniper.net/documentation/en_US/junos15.1x49/topics/concept/policy-rule-understanding.html

Do you have an SRX around or a pointer to docs that confirm it's ok to have dupes in policy names?

[XioNoX]

It is okay to have dupes as long as they are in different source/destination zones tuples.
This example is from our current prod SRXs and was working with Capirca before the recent large commit.

[finfinack]

Thanks!

Yeah looks like this check was introduced by the sync @ankenyr is working on:
d450b92?diff=split

Rob, thoughts? Seems to be easy enough to just iterate over the term names in the same src/dst zone tuple.

[ankenyr]

The SRX generator has had problems with its address book since I first created it. Most of these have to do with the fact that it tries to preserve the naming.py definition names.

I have it on our wishlist / roadmap that we would like to rethink SRX addressbooks and how they work.

There are other problems that we have found such as if a definition is used in two different places and the second one collapses differently, it will affect the addressbook and likely make an unintended change to the other places it was used.

The way I am currently leaning is to change addressbook to have entries for each term.

Therefore the ACL would look something like the following

global {
address test-icmp-src_0 10.0.0.1/32;
address test-icmp-src_1 10.0.0.2/32;
address-set test-icmp {
test-icmp-src_0;
test-icmp-src_1;
}
from-zone foo to-zone bar {
policy test-icmp {
match{
source-address test-icmp-src
then {
......

The benefit of this is it works more like every other generator where the addresses are a set of the IPs in its source and destination. The downside is we would lose the brevity we have with the current address book. If there are duplicate entries they will not be re-used.

[ankenyr]

Ok took a look at things and I feel this is working as intended.
The error comes up when there would be a conflicting name but the application sets are not equal

In other words the following is valid

header {
  target:: srx from-zone a to-zone b
}

term accept-http {
 destination-address:: WEB_SERVERS
 destination-port:: HTTP
 protocol:: tcp
 action:: accept
}

header {
  target:: srx from-zone c to-zone b
}
term accept-http {
 destination-address:: WEB_SERVERS
 destination-port:: HTTP
 protocol:: tcp
 action:: accept
}

both terms are named the same and expose the same ports and thus the application-set will not be modified.

Switching one destination-port to something like SSH will cause this error and I feel that is correct. I don't see how you would resolve this besides renaming the term. Let me know if you disagree.