# Service Instances
When configuring L2 services on an IOS-XE router, you use a service instance instead of a subinterface.
A subinterface is a routed port. For example:
```
int Gi1.100
encapsulation dot1q 100
ip add 10.100.100.1 255.255.255.0
```
A service instance allows you to create L2 services such as cross-connects, bridge domains, VPLS, and allows you do to rewrite operations (pop, translate, push)
A BDI is similar to an SVI on a switch. It is a routed virtual interface that belongs to a bridge domain.
The equivalent of the above configuration with a service instance would look like this:
```
int Gi1
service instance 100 ethernet
encapsulation dot1q 100
bridge-domain 100
rewrite ingress tag pop 1 symmetric
int BDI100
ip address 10.100.100.1 255.255.255.0
```
If you did not pop the tag, you would need the BDI interface to have **encapsulation dot1q 100**. This means that all ports in the bridge domain would have to be tagged with 100 though. So it is a little easier to pop each tag on the UNI port, and have the BDI untagged.
When you have an existing service instance on a physical interface, you can no longer create a subinterface with dot1q encapsulation. Instead you would need to do the service instance with a BDI.
This is the message you see if you try to create a dot1q subinterface on a physical port that has an existing service instance:
```
Router(config)#int gi2.3
Router(config-subif)#encapsulation dot1q 3
%Cannot configure vlan 3 on this interface since VLAN 1 is configured on the EFP service instance.
```
### EFP
This is a good time to mention that EFP (which you saw in the error message above) means Ethernet Flow Point. This name represents the idea that the service instance is not a strict encapsulation of frames, or in other words, an instruction to push a dot1q header on frames, but rather it matches frames with a certain attributes (tags or CoS values) in the L2 header.
For example, **encapsulation dot1q 3** will match traffic that is single-tagged with vlan 3, or double-tagged with the first tag as vlan 3. This command is a match statement, instead of an encapsulation instruction. On a dot1q subinterface, the router tags traffic that is originated from itself with the specified tag. But on a service instance it acts like IOS-XR l2transport where it is a match statement.
You can also use ranges to match multiple vlans, such as this:
```
encapsulation dot1q 1-10,20-22
```
The **default** keyword is used to match any frames that don’t match a more specific service instance.
The **untagged** keyword matches only untagged traffic
You can use **cos** to match on cos-values
You can use **etype** to match the ethertype (ipv4, ipv6, or pppoe)
### Frame manipulation
#### Remove the outermost tag
```
rewrite ingress tag pop 1 symmetric
```
#### Remove two tags
```
rewrite ingress tag pop 2 symmetric
```
The symmetric keyword means that the tag(s) are removed on ingress, but then pushed on egress. You can only configure this if you do **not** have a range in your encapsulation matching statement. (This is because the router knows which tag to push upon egress based on the match statement. If you match on a range of tag values, the router doesn't know which one to use when pushing on egress).
#### Push a vlan tag
```
rewrite ingress tag push dot1q 2 symmetric
```
#### Push two vlan tags
```
rewrite ingress tag push dot1q 2 second-dot1q 100 symmetric
```
The symmetric keyword here means that the tag is pushed on ingress, and then removed on egress
#### Translate 1-to-1, 1-to-2, 2-to-1, 2-to-2
```
rewrite ingress tag translate 1-to-1 dot1q 200 symmetric
```
The encapsulation must be a specific VLAN. So if encap dot1q 100 is configured, then frames with 100 are translated to 200 ingress. Because the **symmetric** keyword is specified, frames with vlan 200 are translated to 100 upon egress.
####
### Bridge Domains
A bridge domain is VLAN-agnositc, meaning that multiple service instances can be in the same bridge domain, and each can have different encapsulation matches and rewrite operations
Multiple service instances on the same interface can belong to the same bridge domain
While INE mentions that the bridge domain must exist, like this:
```
bridge-domain 10
exit
```
I have found this not to be the case. On both CSR1000v and production ASR920, interface service instances can belong to the bridge, and the bridge number does not need to be explicitly defined.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ccnp-sp.gitbook.io/studyguide/l2vpn-and-ethernet/ios-xe-ethernet-services/service-instances.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.