[j-nsp] Policy based (firewall filter) VLAN Tag Manipulation on EX

[Chris Kawchuk]

Hey j-nsp Folks,

I'm pretty much at wit's end trying to get policy-based VLAN Tag Manipulation working on an EX in a nice/non-convoluted way.

As per JNPR's docs, you can do 1:1 swapping by using the "mapping" statement against an interface in the vlan declaration, in conjunction with declaring your interface as "access". This works because it dovetails in with the Q-in-Q abilities on the EX. ( kb.juniper.net/InfoCenter/index?page=content&id=KB16755 ). Note, you can also 'push' an outer VLAN tag onto an incoming VLAN as well, thus making it effectively QinQ; although there's easier ways of accomplishing this.

i.e.:

interfaces {
    ge-0/0/0 {
        mtu 9192;
        unit 0 {
            family ethernet-switching {
                port-mode access;
            }
        }
    }
}

vlans {
    customer {
        vlan-id 100;
        interface {
           ge-0/0/0.0 {
               mapping {
                    30 {
                        swap;
                    }
                }
            }
       }
   }
}

This successfully makes ge-0/0/0 a trunk port, looking for incoming VLAN 30, and translates to VLAN 100 and dumps the frame into my "customer" VLAN. (and vice versa for egress traffic.. it gets re-written as VLAN 30 on egress). (Note: you don't actually need to declare 'dot1q-tunneling' in the VLAN definition stanza for this to work.. as it's just a straightforward 'swap' as per JNPR's own docs).

Caveat:

You need to declare a mapping for every VLAN you want to use on that port (since it's basically an access port now).
- You cannot declare the port as being 'trunk', lets say, to allow some non-translcated tags to pass, and selectively translate others.
- i.e. I have 200 VLANs on that trunk, and only need to swap one of them, I actually have to swap all 200 of them, albeit most of then just 'swap' to the same VLAN ID.
- result: Nasty convoluted config to handle 1 vlan translation as an exception.

_________________________________________________________________________

Better way:

So, the JNPR docs mention the ability to do "policy-based" (i.e. 'firewall filter based') translation instead (Of course, no examples given that I could see).
( http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/qinq-tunneling-ex-series.html ) - See the section on "Firewall filters allow you to map an interface to a VLAN based on a policy....", which requires use of "firewall filter to map to a VLAN, the vlan option has to be configured as part of the firewall filter and the mapping policy option must be specified in the interface configuration for each logical interface using the filter."

Which works like this:

interfaces {
    ge-0/0/0 {
        mtu 9192;
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members [ 2222 3333 ];
                }
                filter {
                    input vlan-translations;
                }
            }
        }
}

firewall {
    family ethernet-switching {
        filter vlan-translations {
            term map {
                from {
                    dot1q-tag 30;
                }
                then {
                    accept;
                    vlan customer;  // you could also say 'vlan 100' here.. either works.
                }
            }
            term accept-all-else {
                then {
                    accept;       // Unless you like black-holing traffic... =)      
                }
            }
        }
    }
}


vlans {
    customer {
        vlan-id 100;
        interface {
            ge-0/0/0.0 {
                mapping {
                    policy;
                }
            }
        dot1q-tunneling;   // this time you need to include it, or it doesn't work
        }
    }
}


So, this method allows you to use, say, vlan 2222 and 3333 as 'normal' trunked VLANs, and if the port ever sees VLAN 30 come in, it'll translate it to VLAN 100. This makes the configuration nice (as you can use a standard trunk port now, and just call the input filter to translate the 'exceptions' you need).

This actually works, but alas, it seems to work only in one direction....

Result:
- Incoming Tag 30 gets translated to Tag 100. 
- Outgoing Tag 100 stays as Tag 100. (I though the whole point of declaring 'mapping policy' was to make the EX 'aware' that you needed bi-directional translation)
- I assume I'm doing something "Just Plain Wrong[tm]"... i.e. the EX was never meant to do bi-directional translation this way.

tcpdump:

Incoming: Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP, arp who-has 10.102.255.3 tell 10.102.255.1
Outgoing: ethertype 802.1Q (0x8100), length 60: vlan 100, p 0, ethertype ARP, arp reply 10.102.255.3 is-at 50:c5:8d:a0:5d:15

Incoming: Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP, arp who-has 10.102.255.3 tell 10.102.255.1
Outgoing: ethertype 802.1Q (0x8100), length 60: vlan 100, p 0, ethertype ARP, arp reply 10.102.255.3 is-at 50:c5:8d:a0:5d:15



Tested: EX4200-24T w/JunOS 10.4R7.5, JunOS 10.4R8.5, JunOS 11.4R1

Summary: Is there an easier way to accomplish this?

Comments/insights/suggestions/blueberry pies welcome.

- Chris.


P.S. No, I dont want to declare VLAN30 in the switch to translate incoming 100 back to 30 on the 'other side' of the switch, since this whole point is because I have a VLAN ID conflict with what some other carrier is 'dumping' out to me on a 1G interconnect; and I want to make "their" VLAN 30 into "my" VLAN 100... as I already have a VLAN 30 for someone else on the switch - however, all the 'other' VLANs I'm carrying between me and the other carrier do not conflict.

P.P.S. Yes, if it was an MX, this would all be moot. =)

P.P.P.S. Merry X-Mas to all my JNPR friends back in Canada.