Access-list policy and selective routing between VLANs in a VR

  • 0
  • 1
  • Problem
  • Updated 4 years ago
  • Solved
Ran into a weird issue:

I have a few VLANs one a VR.

VLAN "World", 172.20.0.0/24 (and potentially routes other IP networks as well)
VLAN "FOO", 10.1.0.0/24

Goal:
From "World" I can route to "FOO" (only 172.20.0.0, though!)
From "FOO" I can route to "World" (BUT only to 172.0.0.0, though)
I need to DENY from FOOanywhere else.
(Actually, there will be multiple "foo" VLANs, all NOT allowed to talk to each other, and only to WORLD's 172 network, but I'm starting small)

So my idea was to enable ipforwarding on that VR and all VLANs and then add a nice access-list policy that I would apply to vlan FOO and BAR

entry AllowFromDC {
        if {
                source-address 172.20.0.0/24;
        } then {
                permit;
                count OK1;
        }
}
entry AllowToDC {
        if {
                destination-address 172.20.0.0/24;
        } then {
                permit;
                count OK2;
        }
}

entry DenyRest {
        if {
        } then {
                deny;
                count Deny;
        }


According to what I used to understand and read, this should work when applied as an ingress (default setting) rule on VLAN "FOO". If the source matches, permit. If the destination matches, permit. "DenyRest" being the catch-all from the manuals, and deny!

Well, this goes badly! Pinging from a workstation 172.20.0.99, I get no answer and I see these counters:

# sh access-list counter
Policy Name       Vlan Name        Port   Direction 
    Counter Name                   Packet Count         Byte Count          
==================================================================
DC2SA             FOO        *      ingress  
    Deny                           12                                       
    OK1                            0                                        
    OK2                            0                                        


Now, if I rewrite the "DenyRest" rule to this:

entry DenyRest {
        if {
                source-address 0.0.0.0/0;
        } then {
                deny;
                count Deny;
        }


then I'm successful and the counters look like this:

# sh access-list counter
Policy Name       Vlan Name        Port   Direction 
    Counter Name                   Packet Count         Byte Count          
==================================================================
DC2SA                 FOO  *      ingress  
    Deny                           0                                        
    OK1                            0                                        
    OK2                            4                                        


Looks like I'm actually counting the reply packets. The target machine of the Ping was actually directly connected to the 8806, so that kinda makes sense.

Still: Huh?

It appears that the condition "if {} then {...}" does not quite behave as I expected it. The 'Good Book' (Exos Concepts Guide 15_3, pdf, page 642) talks about the difference in ingress and egress, and that egress conditions can't be empty, but this is ingress! Or did I miss something somewhere (in a patchnote)?

Also note, I'm using the simple "if {" which gets duly translated to "if match all {"

Thanks
   Frank
Photo of Frank

Frank

  • 3,776 Points 3k badge 2x thumb

Posted 4 years ago

  • 0
  • 1
Photo of Jarek

Jarek

  • 2,398 Points 2k badge 2x thumb
Hi Frank,

with ACL : entry DenyRest {         if {         } then {                 deny;                 count Deny;         }

you deny also the ARP packets. You must add ACL that allow ARP.

--
Jarek

Photo of Frank

Frank

  • 3,776 Points 3k badge 2x thumb
Oh, I guess that might be an issue.
So would I have to insert:

if {
  arp;
} then {
  permit;
}

or how do you test for arp?

It would, however, be awesome if the documentation would have useable examples - I've seen this example not only in the documentation as recent as the 15.3, but also a few times across the forum. They all say "here's a 'deny rest' after 'allow IP this and allow IP that'".
Photo of Jarek

Jarek

  • 2,398 Points 2k badge 2x thumb


There is an info in the Conept Guide 15.3, page 680 says:

---------------------------------------------------

Since the deny section does not specify an Ethernet type, all traffic other than IP packets destined to
10.200.250.2/32 are blocked, including the ARP packets. To allow ARP packets, add an entry for the
Ethernet type, 0x0806, as shown below.
entry test_policy_5 {
if {
ethernet-type 0x0806;
} then {
permit;
count test_policy_permit;
}
}

---------------------------------------------------

But, I have read your post one more time, you want to deny all traffic form vlan FOO to the network, exept  172.20.0.0/24.
You apply the ACL on ingress, then you need:

entry AllowToDC {
        if {
                destination-address 172.20.0.0/24;
        } then {
                permit;
                count OK2;
        }
}

entry DenyToRest {
        if {
                destination-address 0.0.0.0/0;
        } then {
                deny;
                count Deny;
        }
}

--
Jarek


(Edited)
Photo of Frank

Frank

  • 3,776 Points 3k badge 2x thumb
Thanks for pointing that ARP rule out (in my version it's 4 pages earlier, I may have to see if there's a newer concept guide out if I'm missing 4 pages!)

I have to admit, I might not have read that far down the section, and if I did, I certainly didn't make the connection between "this is how you allow ARP traffic" and "you'll pretty much deny everything you want to do here if you don't allow ARP" :)

Thank you for you help - now what happened makes sense!

    Frank