SRX

Oh and make sure to edit stuff that we don't need to see 🙂  My scenario is Cisco 2950->SRX240 via VLAN trunk.

I could swear I am following docs to the tee but I still can reach my Internet gateway.

Thanks in Advance!

I attached my configuration

Attachment(s)

config.txt   8 KB 1 version

I applied the fix, but still no go. It is strange since I can see the server via arp:

root@srx240a> show arp
MAC Address       Address         Name                      Interface           Flags
00:1e:4f:b4:6a:1e 10.0.1.33       10.0.1.33                 vlan.23             none

I can't ping from the firewall to this machine. Also, the machine sees 10.0.1.1 via ARP but can't ping

the gateway. Is there something that needs to be configured with native VLAN?

Once again, if anyone has a working configuration that they can share that would be awesome. VLAN trunking from Cisco to SRX.

Thanks!

You'll need to add interface vlan.23 to your security zone, not the physical interface (ge-0/0/10.0).

The basic rule of thumb is that interfaces of type "family inet" are put into security zones, whether they be a physical interface (such as your ge-0/0/14.0) or vlan interfaces (vlan.23, vlan.0).   Interfaces that are in family ethernet-switching are simply "transports" and don't interact with security zones -- all security zone processing happens to/from/between "family inet" interfaces.

Hope that helps.

Hmm. There is a note in the KB that native vlan tags are not supported. Can you configure the Cisco to send VLAN 1 with a tag, as well, or choose another VLAN ID for that purpose? I seem to remember that the use of VLAN 1 was generally frowned upon in a Cisco world.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB14586&pmv=print

I'm not quite sure whether using ethernet-switching would allow you to use native tags after all - but given that you don't succeed, my bet is on "nope, not supported."

You can use VLANs on the physical interface without switching support, btw. You simply configure them as units of the physical interface.

Here is an example config. For ease of management, units are labeled according to the VLAN ID. This is not required, but makes it easier to read the config at a glance when troubleshooting.

interfaces {

   ge-0/0/0 {

        vlan-tagging;

        unit 8 {

            description <desc-vlan8>;

            vlan-id 8;

            family inet {

                address <ip/cidr>;

            }

        }

        unit 20 {

            description <desc-vlan20>;

            vlan-id 20;

            family inet {

                address <ip/cidr>;

            }

        }

    }

}

Ok, will give it a try... Will let you know how it goes tomorrow.

I tried as follows:

ge-0/0/10 {
        vlan-tagging;
        unit 10 {
            description "Native VLAN";
            vlan-id 10;
            family inet {
                address 172.19.0.1/24;
            }
        }
        unit 23 {
            vlan-id 23;
            family inet {
                address 10.0.1.1/24;
            }
        }
    }

Then I hooked up a cisco 2950 to this port. Switchport mode trunk is enabled. Trunking Native Mode VLAN is set to 10. and Trunking VLANs enabled are 10,23.

I hooked a UNIX box to port 14 on the 2950 and set the same settings. One the box I have 10.0.1.33 IP Address set and on VLAN 23 and VLAN 10 enabled.  I can see the 10.0.1.33 in the arp table:

root@srx240a# run show arp
MAC Address       Address         Name                      Interface           Flags
00:1e:4f:b4:6a:1e 10.0.1.33       10.0.1.33                 ge-0/0/10.23        none

Although it is there, I can't ping it from the firewall. Also, I can't ping 10.0.1.1 from the linux box, nor DNS (8.8.8.8), etc.. even tho I have policies enabling it.

The point I was making is that you can't use native VLANs. Tag all VLANs and this will work. What you have named "Native" expects a VLAN tag of 10.

That was the message of the KB article I linked: Mixed native/tagged configurations are not supported on SRX/J-Series.

Tagging issues aside, the L3 interface needs to be assigned to the proper security zone.  In the previous config, the L2 interface was assigned to the security zone rather than the L3 interface.

Native VLANs are fine if you're in family ethernet-switching.

Kr - I am not following the L3 interface bit. The following shows the interface being part of a zone. If it is not in ethernet-switching mode, then is it considered L3? So, the following should be correct?

security-zone example {
            host-inbound-traffic {
                protocols {
                    all;                
                }
            }
            interfaces {
                ge-0/0/9.0 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                    }
                }
            }
        }

I have a saying when it comes to Juniper products.  It's an adaptation of a famous superhero movie quote:

"With great power comes great confusion."

In Junos on the SRX, there are many ways to do things.  Because there is not just one way to configure things, it can get quite confusing at times.

A L3 interface is an interface that has an IP address and performs routing functions.  A L2 interface is one that is simply carrying VLAN traffic.

In your example, you have ge-0/0/9.0 added to your "example" security zone.  Using the device configuration that you posted in an earlier post, you have interface ge-0/0/9.0 defined like this:

interfaces {
    ge-0/0/9 {
        unit 0 {
            family inet {
                address 10.0.0.1/24;
            }
        }
    }
}

In this case, ge-0/0/9.0 is a L3 interface, because it is defined as "family inet" and has an IP address, and will perform routing functionality when necessary.

Therefore, in your example, having ge-0/0/9.0 configured in the "example" security zone is correct, because ge-0/0/9.0 is a L3 interface.

However, in earlier posts the question was about interface ge-0/0/10.0, which is the VLAN trunk to your Cisco switch.

You have interface ge-0/0/10.0 defined as follows:

interfaces {
    ge-0/0/10 {
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members all;
                native-vlan-id 1;       
            }
        }
    }
}

In this case, ge-0/0/10.0 is a L2 interface, because it is configured in "family ethernet-switching."  There is no IP address associated with ge-0/0/10.0, therefore it is not a L3 interface.

You are coming from an internal server on IP 10.0.1.33/24.  That server needs a gateway IP to route out, and the gateway IP is 10.0.1.1/24, which is assigned to the VLAN interface for VLAN 23:

interfaces {
    vlan {
        unit 23 {
            family inet {
                address 10.0.1.1/24;
            }
        }
    }
}

Here, this is a virtual interface rather than a physical interface.  The physical interface ge-0/0/10.0 is where the wire plugs in, however it has no IP address to act as the gateway.  The virtual interface here, called interface vlan.23 (unit 23 of the vlan virtual interface) is the L3 interface for VLAN 23.

SRX security zones are based on L3 decisions.  When traffic comes into the box, the SRX makes a routing decision based on the destination of the traffic.  If the routing decision results in the traffic needing to cross security boundaries (for example, if the ingress L3 interface is in zone trust, and the egress L3 interface is in zone untrust), then security policies are checked from zone trust to zone untrust to see if the traffic should be permitted or denied.  If permitted, it will forward the traffic out the egress port.

Since the SRX is a Layer 3 box, you must assign the proper L3 interfaces to the proper security zones.

Here you have:

security {
    zones {
        security-zone trust {
            tcp-rst;
            host-inbound-traffic {
                system-services {       
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            http;
                            https;
                            ssh;
                            telnet;
                            dhcp;
                        }
                    }
                }
                vlan.0;
            }
        }
        security-zone untrust {
            screen untrust-screen;
            host-inbound-traffic {
                system-services {
                    ping;
                    ssh;
                    https;
                }
            }
            interfaces {
                ge-0/0/14.0 {
                    host-inbound-traffic {
                        protocols {
                            all;
                        }
                    }
                }
            }
        }
    }
}

Here, you have interfaces ge-0/0/0.0 and vlan.0 assigned to your trust security zone. ge-0/0/0.0 doesn't actually have any VLANs assigned to it, so that one is useless at this point.  Interface vlan.0 is the L3 interface defined with IP address 192.168.1.1/32 -- which is going to cause problems as a /32, but that's another issue for another day. Basically, both of the interfaces assigned to your trust security zone are useless right now.

Assuming your internal server is meant to be in your "trust" zone, you must assign interface vlan.23 to the trust zone.  Assinging ge-0/0/10.0 will not work, as that is not a L3 interface, it is a L2 interface.

Then, the model works:  Your ingress physical port is ge-0/0/10.0 -- however the ingress L3 interface is actually interface vlan.23, which is the gateway for your server.  The egress port is ge-0/0/14.0, as that appears to be the uplink to your ISP.  You have ge-0/0/14.0 assigned to the untrust security zone, which is correct, becuase ge-0/0/14.0 is a L3 interface (again, it is defined as "family inet").  Traffic ingresses on vlan.23, the SRX looks at the routing table and decides it that the destination of that traffic (Internet) must egress from ge-0/0/14.0. Since vlan.23 and ge-0/0/14.0 are in different security zones, the SRX will check the security policies from the trust to untrust zone, and will permit the traffic because you have a policy defined that permits all traffic from trust to untrust.

Sorry for the long post, but I hope this helps to clear up some of the confusion.

Excellent post, Keith!

Thanks!  I really appreciate it and I see how one configures a VLAN using ethernet-switching mode.

1) configure vlan interface which creates the "virtual routing VLAN"

set interface vlan UNIT <unit id> family inet address <CIDR>

Example:

set interface vlan unit 10 family inet address 172.19.0.1/24

2) create VLAN

set vlans <vlan name> vlan-id <unit id> l3-interface vlan.<unit-id>

Example:

set vlans ExampleVLAN vlan-id 10 l3-interface 10

3) create interface

set interface <interface> unit <unit-id> family ethernet-switching port mode trunk

set interface <interface> unit <unit-id> family ethernet-switching vlan members <vlan name>

Example:

set interface ge-0/0/4 unit 10 family ethernet-switching port mode trunk

set interface ge-0/0/4 unit 10 family ethernet-switching vlan members ExampleVLAN

4) Final step would be to insure the vlan is added to a zone, for example trust:

set security zones security zones trust interfaces vlan.10

Now, lets say I want to do the same thing on a physical port. Once again great power, great confusion.

1) First need to enable vlan tagging on physical interface

set interface <interface> vlan-tagging

Example:

set interface ge-0/0/4 vlan-tagging

2) Next add unit information and vlan

set interface <interface> unit <unit-id> family inet address <address>

Example:

set interface ge-0/0/4 unit 10 family inet address 172.19.0.1/24

3) Once again the final step would be to insure the interface is added to a zone, for example trust:

set security zones security zones trust interfaces ge-0/0/4

So, would the 3 steps work, and if so when to use ethernet switching and when to use physical interface on the SRX for trunking to a switch.

---

@wbathurst wrote:

Example:

set interface ge-0/0/4 unit 10 family inet address 172.19.0.1/24

 

3) Once again the final step would be to insure the interface is added to a zone, for example trust:

 

set security zones security zones trust interfaces ge-0/0/4

---

You've got the right idea, just remember to specify the unit number on the physical port as well.  Where you have:

set security zones security-zone trust interfaces ge-0/0/4

It should be:

set security zones security-zone trust interfaces ge-0/0/4.10

The reason for that is because your physical interface can have multiple units configured, and you can actually treat each unit separately and even put different units into different security zones.

---

@wbathurst wrote:

So, would the 3 steps work, and if so when to use ethernet switching and when to use physical interface on the SRX for trunking to a switch.

---

The decision on when to use switching vs. trunked L3 interfaces is going to depend on a few factors, and will vary from scenario to scenario.

One factor is simply personal preference.  Some people prefer the trunked L3 interfaces, because it's "cleaner" (read:  more old-school router type configuration).  Some prefer VLANs and VLAN interfaces because it's more akin to how more modern routers/switches/L3 switches work, and it makes more sense to some people.

For each scenario, determine if there is any need for switched ports.  Will there be more than one port on the SRX that needs to be in a certain VLAN?  Do you need any layer 2 protocols such as Spanning Tree for your topology?

There are other things to consider, too, which are becoming slightly less critical with newer Junos releases, but for the first few years of the SRX's life, there were things that simply did not work using the VLAN/switched approach.  For example, I remember this one well -- it used to be that multicast traffic was dropped on L3 VLAN interfaces, meaning you couldn't run OSPF on a VLAN interface.  This has since been fixed.  There have always been extreme caveats with using switched ports on the SRX if you use chassis clusters at all, which again, are becoming less critical but there are still caveats.

At the end of the day, find what works for you and what makes sense to you and go with it.  If one method lends itself to a simpler design, simpler configuration, or it makes more sense to you, go for it (noting any potential caveats, of course, that may tie your hands to choose one method vs. another).

Me?  Personally?  I use switched ports and VLAN interfaces whenever feasible rather than L3 physical interfaces.  I like LLDP to work between my network devices, for starters.  Also, L3 physical interfaces get really bitchy when they receive untagged traffic (such as LLDP or STP broadcasts) and register a lot of discarded packets on the interfaces when my NMS polls the interface stats with SNMP.  Also, using switched ports and VLANs gives me flexibility in the future if I need to add a port to a VLAN for testing or supporting a new service or need, or if I need to move things around it's easier (in my opinion) to just move VLANs rather than have to reconfigure every physical interface.  These are just MY opinions, there are many here who will disagree with me and they're just as valid in their points.  Your mileage may vary, professional driver on a closed course, don't try this at home, etc.