Configure Layer 2 Bridging
Configuring a Bridge Domain
A bridge domain must include a set of logical interfaces that participate in Layer 2 learning and forwarding. You can optionally configure a VLAN identifier and a routing interface for the bridge domain to also support Layer 3 IP routing.
To enable a bridge domain, include the following statements:
[edit]
bridge-domains {
bridge-domain-name {
domain-type bridge:
interface interface-name;
routing-interface routing-interface-name;
vlan-id (none | all | number);
vlan-id-list [ vlan-id-numbers ];
vlan-tags outer number inner number);
}
}
The Layer 2 CLI configurations and show commands for ACX5048 and ACX5096 routers differ compared to other ACX Series routers. For more information, see Layer 2 Next Generation Mode for ACX Series.
You cannot use the slash (/) character in bridge domain names. If you do, the configuration does not commit and an error is generated.
For the vlan-id statement, you can specify either
a valid VLAN identifier or the none or all options.
For information about VLAN identifiers and VLAN tags for a bridge
domain, see Configuring VLAN Identifiers for Bridge Domains and
VPLS Routing Instances.
To include one or more logical interfaces in the bridge domain,
specify an interface-name for an Ethernet
interface you configured at the [edit interfaces] hierarchy
level.
A maximum of 4000 active logical interfaces are supported on a bridge domain or on each mesh group in a virtual private LAN service (VPLS) instance configured for Layer 2 bridging.
To configure a layer 2 logical interface to be included in a bridge domain, you can
either include the encapsulation vlan-bridge statement under the
logical interface, or the encapsulation ethernet-bridge statement
under the physical interface.
On ACX Series routers, a maximum of 1000 logical interfaces can be configured on a physical interface. You can configure a maximum of 3000 bridge domains on an ACX Series router.
By default, each bridge domain maintains a Layer 2 forwarding database that contains media access control (MAC) addresses learned from packets received on the ports that belong to the bridge domain. You can modify Layer 2 forwarding properties, including disabling MAC learning for the entire system or a bridge domain, adding static MAC addresses for specific logical interfaces, and limiting the number of MAC addresses learned by the entire system, the bridge domain, or a logical interface.
You can also configure spanning tree protocols to prevent forwarding loops. .
In Junos OS Release 8.5 and later, you can configure IGMP snooping for a bridge domain. For more information, see the Junos OS Multicast Protocols User Guide.
Integrated routing and bridging (IRB) provides simultaneous
support for Layer 2 bridging and Layer 3 routing on the
same interface. IRB enables you to route packets to another routed
interface or to another bridge domain that has an IRB interface configured.
You configure a logical routing interface by including the irb statement at the [edit interfaces] hierarchy level and
include that interface in the bridge domain. For more information
about how to configure a routing interface, see the Junos OS Network
Interfaces Library for Routing Devices.
You can include only one routing interface in a bridge domain.
To configure a bridge domain with IRB support, include the following statements:
[edit] bridge-domains { bridge-domain-name { domain-type bridge; interface interface-name; routing-interface routing-interface-name; service-id number; vlan-id (none | number); vlan-tags outer number inner number; } }
For each bridge domain that you configure, specify a bridge-domain-name. You must also specify the value bridge for the domain-type statement.
For the vlan-id statement, you can specify either
a valid VLAN identifier or the none option.
If you configure a routing interface to support IRB in
a bridge domain, you cannot use the all option for the vlan-id statement.
The vlan-tags statement enables you to specify a
pair of VLAN identifiers; an outer tag and an inner tag.
For a single bridge domain, you can include either the vlan-id statement or the vlan-tags statement, but
not both.
For MC-LAG bridge domains, when the VLAN identifier is none, use the service-id statement to facilitate
media access control (MAC) and Address Resolution Protocol (ARP) synchronization
among MC-LAG peers.
To include one or more logical interfaces in the bridge domain,
specify the interface name for each Ethernet interface to include
that you configured at the [edit interfaces] hierarchy
level.
A maximum of 4000 active logical interfaces are supported on a bridge domain or on each mesh group in a VPLS routing instance configured for Layer 2 bridging.
To associate a routing interface with a bridge domain, include
the routing-interface routing-interface-name statement and specify a routing-interface-name you configured at the [edit interfaces irb] hierarchy
level. You can configure only one routing interface for each bridge
domain. For more information about how to configure logical and routing
interfaces, see the Junos OS Network Interfaces Library for Routing Devices.
In Junos OS Release 9.0 and later, IRB interfaces are supported for multicast snooping. For more information about multicast snooping, see the Understanding Multicast Snooping and VPLS Root Protection.
In Junos 11.4 and later, IP multicast is supported on Layer 2 trunk ports through IRB interfaces using the Trio chipset.
In Junos OS Release 9.6 and later, in multihomed VPLS configurations,
you can configure VPLS to keep a VPLS connection up if only an IRB
interface is available by configuring the irb option for
the connectivity-type statement at the [edit routing-instances routing-instance-name protocols vpls] hierarchy
level. The connectivity-type statement has two options, ce and irb. The ce option is the default and
specifies that a CE interface is required to maintain the VPLS connection.
By default, if only an IRB interface is available, the VPLS connection
is brought down. For more information about configuring VPNs, see
the Junos VPN Configuration Guide.
When you configure IRB interfaces in more than one logical system on a device, all of the of the IRB logical interfaces share the same MAC address.
Integrated Bridging
and Routing (IRB) interfaces are used to tie together Layer 2 switched
and Layer 3 routed domains on MX routers. MX routers support classifiers
and rewrite rules on the IRB interface at the [edit class-of-service
interfaces irb unit logical-unit-number] level of the hierarchy.
All types of classifiers and rewrite rules are allowed, including
IEEE 802.1p.
The IRB classifiers and rewrite rules are used only for routed packets; in other words, it is for traffic that originated in the Layer 2 domain and is then routed through IRB into the Layer 3 domain, or vice versa. Only IEEE classifiers and IEEE rewrite rules are allowed for pure Layer 2 interfaces within a bridge domain.
Configuring VLAN Identifiers for Bridge Domains and VPLS Routing Instances
For a bridge domain that is performing Layer 2 switching only, you do not have to specify a VLAN identifier.
For a bridge domain that is performing Layer 3 IP routing, you must specify either a VLAN identifier or dual VLAN identifier tags.
For a VPLS routing instance, you must specify either a VLAN identifier or dual VLAN identifier tags.
You can configure VLAN identifiers for a bridge domain or a VPLS routing instance in the following ways:
By using the input-vlan-map and the
output-vlan-mapstatements at the[edit interfaces interface-name]or[edit logical-systems logical-system-name interfaces interface-name]hierarchy level to configure VLAN mapping. For information about configuring input and output VLAN maps to stack and rewrite VLAN tags in incoming or outgoing frames, see the Junos OS Network Interfaces Library for Routing Devices.By using either the
vlan-idstatement or thevlan-tagsstatement to configure a normalizing VLAN identifier. This topic describes how normalizing VLAN identifiers are processed and translated in a bridge domain or a VPLS routing instance.
The vlan-id and vlan-tags statements
are used to specify the normalizing VLAN identifier under the bridge
domain or VPLS routing instance. The normalizing VLAN identifier is
used to perform the following functions:
Translate, or normalize, the VLAN tags of received packets received into a learn VLAN identifier.
Create multiple learning domains that each contain a learn VLAN identifier. A learning domain is a MAC address database to which MAC addresses are added based on the learn VLAN identifier.
You cannot configure VLAN mapping using the input-vlan-map and output-vlan-map statements if you configure a normalizing
VLAN identifier for a bridge domain or VPLS routing instance using
the vlan-id or vlan-tags statements.
To configure a VLAN identifier for a bridge domain, include
either the vlan-id or the vlan-tags statement
at the [edit interfaces interface-name unit logic-unit-number family bridge] or [edit logical-systems logical-system-name interfaces interface-name unit logic-unit-number family bridge] hierarchy level, and then include that logical interface in the
bridge domain configuration. For more information about configuring
a bridge domain, see Configuring a Bridge
Domain.
For a VPLS routing instance, include either the vlan-id or vlan-tags statement at the [edit interfaces interface-name unit logic-unit-number] or [edit logical-systems logical-system-name interfaces interface-name unit logic-unit-number] hierarchy level, and then include that logical interface
in the VPLS routing instance configuration. For more information about
configuring a VPLS routing instance, see the Junos OS VPNs Library for Routing Devices.
The maximum number of Layer 2 interfaces that you can associate with a bridge domain or a VPLS instance on MX Series routers is 4000.
For a single bridge domain or VPLS routing instance, you
can include either the vlan-id or the vlan-tags statement, but not both. If you do not configure a vlan-id, vlan-tags, or vlan-id-list [ vlan-id-numbers ] for the bridge domain or the VPLS routing instance, the Layer
2 packets received are forwarded to the outbound Layer 2 interface
without having the VLAN tag modified unless an output-vlan-map is configured on the Layer 2 interface. This results in a frame
being forwarded to a Layer 2 interface with a VLAN tag that is different
from what is configured for the Layer 2 interface. Note that a frame
received from the Layer 2 interface is still required to match the
VLAN tag(s) specified in the interface configuration. The invalid
configuration may cause a Layer 2 loop to occur.
The VLAN tags associated with the inbound logical interface are compared with the normalizing VLAN identifier. If the tags are different, they are rewritten as described in Table 1. The source MAC address of a received packet is learned based on the normalizing VLAN identifier.
You do not have to specify a VLAN identifier for a bridge domain that is performing Layer 2 switching only. To support Layer 3 IP routing, you must specify either a VLAN identifier or a pair of VLAN tags. However, you cannot specify the same VLAN identifier for more than one bridge domain within a routing instance. Each bridge domain must have a unique VLAN identifier.
If the VLAN tags associated with the outbound logical interface and the normalizing VLAN identifier are different, the normalizing VLAN identifier is rewritten to match the VLAN tags of the outbound logical interface, as described in Table 2.
For the packets sent over the VPLS routing instance to be tagged by the normalizing VLAN identifier, include one of the following configuration statements:
vlan-id number to tag all packets that are sent over the VPLS virtual tunnel (VT) interfaces with the VLAN identifier.
vlan-tags outer number inner number to tag all packets sent over the VPLS VT interfaces with dual outer and inner VLAN tags.
Use the vlan-id none statement to have the VLAN tags
removed from packets associated with an inbound logical interface
when those packets are sent over VPLS VT interfaces. Note that those
packets might still be sent with other customer VLAN tags.
The vlan-id all statement enables you to configure
bridging for several VLANs with a minimum amount of configuration.
Configuring this statement creates a learning domain for:
Each inner VLAN, or learn VLAN, identifier of a logical interface configured with two VLAN tags
Each VLAN, or learn VLAN, identifier of a logical interface configured with one VLAN tag
We recommend that you do not use customer VLAN IDs in a VPLS routing instance because customer VLAN IDs are used for learning only.
You should use the service VLAN ID in a VPLS routing instance, as in the following configuration:
[edit]
interface ge-1/1/1 {
vlan-tagging;
unit 1 {
vlan-id s1; /* Service vlan */
encapsulation vlan-vpls;
input-vlan-map pop; /* Pop the service vlan on input */
output-vlan-map push; /* Push the service vlan on output */
}
}
interface ge-1/1/2 {
encapsulation ethernet-vpls;
unit 0;
}
routing-instance {
V1 {
instance-type vpls;
vlan-id all;
interface ge-1/1/1.1;
interface ge-1/1/2.0;
}
}
If you configure the vlan-id all statement
in a VPLS routing instance, we recommend using the input-vlan-map
pop and output-vlan-map push statements on the logical
interface to pop the service VLAN ID on input and push the service
VLAN ID on output and in this way limit the impact of doubly-tagged
frames on scaling. You cannot use the native vlan- id statement
when the vlan-id all statement is included in the configuration.
The vlan-id-list [ vlan-id-numbers ] statement enables you to configure bridging for multiple
VLANs on a trunk interface. Configuring this statement creates a learning
domain for:
Each VLAN listed:
vlan-id-list [ 100 200 300 ]Each VLAN in a range:
vlan-id-list [ 100-200 ]Each VLAN in a list and range combination:
vlan-id-list [ 50, 100-200, 300 ]
The following steps outline the process for bridging
a packet received over a Layer 2 logical interface when you specify
a normalizing VLAN identifier using either the vlan-id number or vlan-tags statement for a bridge
domain or a VPLS routing instance:
- When a packet is received on a physical port, it is accepted only if the VLAN identifier of the packet matches the VLAN identifier of one of the logical interfaces configured on that port.
- The VLAN tags of the received packet are then compared with the normalizing VLAN identifier. If the VLAN tags of the packet are different from the normalizing VLAN identifier, the VLAN tags are rewritten as described in Table 1.
- If the source MAC address of the received packet is not present in the source MAC table, it is learned based on the normalizing VLAN identifier.
- The packet is then forwarded toward one or more outbound Layer 2 logical interfaces based on the destination MAC address. A packet with a known unicast destination MAC address is forwarded only to one outbound logical interface. For each outbound Layer 2 logical interface, the normalizing VLAN identifier configured for the bridge domain or VPLS routing instance is compared with the VLAN tags configured on that logical interface. If the VLAN tags associated with an outbound logical interface do not match the normalizing VLAN identifier configured for the bridge domain or VPLS routing instance, the VLAN tags are rewritten as described in Table 2.
The tables below show how VLAN tags are applied for traffic
sent to and from the bridge domain, depending on how the vlan-id and vlan-tags statements are configured for the bridge
domain and on how VLAN identifiers are configured for the logical
interfaces in a bridge domain or VPLS routing instance. Depending
on your configuration, the following rewrite operations are performed
on VLAN tags:
pop—Remove a VLAN tag from the top of the VLAN tag stack.
pop-pop—Remove both the outer and inner VLAN tags of the frame.
pop-swap—Remove the outer VLAN tag of the frame and replace the inner VLAN tag of the frame.
swap—Replace the VLAN tag of the frame.
push—Add a new VLAN tag to the top of the VLAN stack.
push-push—Push two VLAN tags in front of the frame.
swap-push—Replace the VLAN tag of the frame and add a new VLAN tag to the top of the VLAN stack.
swap-swap—Replace both the outer and inner VLAN tags of the frame.
Table 1 shows specific examples of how the VLAN tags for packets sent to the bridge domain are processed and translated, depending on your configuration. “–” means that the statement is not supported for the specified logical interface VLAN identifier. “No operation” means that the VLAN tags of the received packet are not translated for the specified input logical interface.
VLAN Identifier of Logical Interface |
VLAN Configurations for Bridge Domain |
|||
|---|---|---|---|---|
vlan-id none |
vlan-id 200 |
vlan-id all |
vlan tags outer 100 inner 300 |
|
none |
No operation |
push 200 |
– |
push 100, push 300 |
200 |
pop 200 |
No operation |
No operation |
swap 200 to 300, push 100 |
1000 |
pop 1000 |
swap 1000 to 200 |
No operation |
swap 1000 to 300, push 100 |
vlan-tags outer 2000 inner 300 |
pop 2000, pop 300 |
pop 2000, swap 300 to 200 |
pop 2000 |
swap 2000 to 100 |
vlan-tags outer 100 inner 400 |
pop 100, pop 400 |
pop 100, swap 400 to 200 |
pop 100 |
swap 400 to 300 |
vlan-id-range 10-100 |
– |
– |
No operation |
– |
vlan-tags outer 200 inner-range 10-100 |
– |
– |
pop 200 |
– |
Table 2 shows specific examples of how the VLAN tags for packets sent from the bridge domain are processed and translated, depending on your configuration. “–” means that the statement is not supported for the specified logical interface VLAN identifier. “No operation” means that the VLAN tags of the outbound packet are not translated for the specified output logical interface.
VLAN Identifier of Logical Interface |
VLAN Configurations for Bridge Domain |
|||
|---|---|---|---|---|
vlan-id none |
vlan-id 200 |
vlan-id all |
vlan tags outer 100 inner 300 |
|
none |
no operation |
pop 200 |
– |
pop 100, pop 300 |
200 |
push 200 |
No operation |
No operation |
pop 100, swap 300 to 200 |
1000 |
push 1000 |
swap 200 to 1000 |
No operation |
pop 100, swap 300 to 1000 |
vlan-tags outer 2000 inner 300 |
push 2000, push 300 |
swap 200 to 300, push 2000 |
push 2000 |
swap 100 to 2000 |
vlan-tags outer 100 inner 400 |
push 100, push 400 |
swap 200 to 400, push 100 |
push 100 |
swap 300 to 400 |
vlan-id-range 10-100 |
– |
– |
No operation |
– |
vlan-tags outer 200 inner-range 10-100 |
– |
– |
push 200 |
– |
Configuring VLAN Identifiers for Bridge Domains in ACX Series
You can configure VLAN identifiers for a bridge domain for normalization in the following ways:
Configure VLAN mapping by using the input-vlan-map and the
output-vlan-mapstatements at the[edit interfaces interface-name]hierarchy level.Configure an implicit normalizing VLAN identifier under the bridge domain by using the vlan-id statement at the
[edit bridge-domains bridge-domain-name]hierarchy level.
You cannot configure VLAN mapping by using the input-vlan-map and output-vlan-map statements if you configure a normalizing
VLAN identifier for a bridge domain by using the vlan-id statement.
You can use the vlan-id-list [ vlan-id-numbers ] statement to configure bridging for multiple VLANs. Configuring
this statement creates a bridge domain for:
Each VLAN listed—for example,
vlan-id-list [ 100 200 300 ]Each VLAN in a range—for example,
vlan-id-list [ 100-200 ]Each VLAN in a list and range combination—for example,
vlan-id-list [ 50, 100-200, 300 ]
Example: Configuring Basic Layer 2 Switching on MX Series
This example shows how to configure Layer 2 switching with all interfaces participating in a single VLAN.
Requirements
No special configuration beyond device initialization is required before configuring this example.
This example uses an MX Series device to perform Layer 2 switching.
Overview
In this example, a single MX Series device is configured to act as a basic single-VLAN switch. Three connections are in place. The connections from the MX Series device attach to Junos OS routers, but the routers are used here for testing purposes only. In place of routers, you can use any IP networking devices.
Topology
Figure 1 shows the sample network.
CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
Configuration
CLI Quick Configuration
To quickly configure
this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match
your network configuration, and then copy and paste the commands into
the CLI at the [edit] hierarchy level.
Device S1
set interfaces ge-2/0/0 vlan-tagging set interfaces ge-2/0/0 encapsulation extended-vlan-bridge set interfaces ge-2/0/0 unit 0 vlan-id 600 set interfaces ge-2/0/1 vlan-tagging set interfaces ge-2/0/1 encapsulation extended-vlan-bridge set interfaces ge-2/0/1 unit 0 vlan-id 600 set interfaces ge-2/0/2 vlan-tagging set interfaces ge-2/0/2 encapsulation extended-vlan-bridge set interfaces ge-2/0/2 unit 0 vlan-id 600 set bridge-domains customer1 domain-type bridge set bridge-domains customer1 interface ge-2/0/0.0 set bridge-domains customer1 interface ge-2/0/2.0 set bridge-domains customer1 interface ge-2/0/1.0
Device R1
set interfaces ge-1/3/2 vlan-tagging set interfaces ge-1/3/2 unit 0 vlan-id 600 set interfaces ge-1/3/2 unit 0 family inet address 10.0.0.1/24
Device R2
set interfaces ge-3/1/0 vlan-tagging set interfaces ge-3/1/0 unit 0 vlan-id 600 set interfaces ge-3/1/0 unit 0 family inet address 10.0.0.2/24
Device R3
set interfaces ge-2/0/1 vlan-tagging set interfaces ge-2/0/1 unit 0 vlan-id 600 set interfaces ge-2/0/1 unit 0 family inet address 10.0.0.3/24
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device S1:
Configure the device interfaces.
[edit interfaces] user@S1# set interfaces ge-2/0/0 vlan-tagging user@S1# set interfaces ge-2/0/0 encapsulation extended-vlan-bridge user@S1# set interfaces ge-2/0/0 unit 0 vlan-id 600 user@S1# set interfaces ge-2/0/1 vlan-tagging user@S1# set interfaces ge-2/0/1 encapsulation extended-vlan-bridge user@S1# set interfaces ge-2/0/1 unit 0 vlan-id 600 user@S1# set interfaces ge-2/0/2 vlan-tagging user@S1# set interfaces ge-2/0/2 encapsulation extended-vlan-bridge user@S1# set interfaces ge-2/0/2 unit 0 vlan-id 600
Configure the bridge domain.
[edit interfaces] user@S1# set bridge-domains customer1 domain-type bridge user@S1# set bridge-domains customer1 interface ge-2/0/0.0 user@S1# set bridge-domains customer1 interface ge-2/0/2.0 user@S1# set bridge-domains customer1 interface ge-2/0/1.0
Results
From configuration mode, confirm your configuration
by entering the show interfaces and show bridge-domains commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@S1# show interfaces
ge-2/0/0 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
ge-2/0/1 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
ge-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
user@S1# show bridge-domains
customer1 {
domain-type bridge;
interface ge-2/0/0.0;
interface ge-2/0/2.0;
interface ge-2/0/1.0;
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Confirming the MAC Address Learning
- Making Sure That the Attached Devices Can Reach Each Other
- Checking the Bridge Domain
- Checking the Bridge Statistics
- Checking the Bridge Flooding
- Checking Layer 2 Learning
Confirming the MAC Address Learning
Purpose
Display Layer 2 MAC address information.
Action
From Device S1, run the
show bridge mac-tablecommand.user@S1> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : default-switch Bridging domain : customer1, VLAN : NA MAC MAC Logical NH RTR address flags interface Index ID 00:12:1e:ee:34:dd D ge-2/0/2.0 00:1d:b5:5e:86:79 D ge-2/0/0.0 00:21:59:0f:35:2b D ge-2/0/1.0From Device S1, run the
show bridge mac-table extensivecommand.user@S1> show bridge mac-table extensive MAC address: 00:12:1e:ee:34:dd Routing instance: default-switch Bridging domain: customer1, VLAN : NA Learning interface: ge-2/0/2.0 Layer 2 flags: in_hash,in_ifd,in_ifl,in_vlan,in_rtt,kernel,in_ifbd Epoch: 1 Sequence number: 0 Learning mask: 0x00000004 MAC address: 00:1d:b5:5e:86:79 Routing instance: default-switch Bridging domain: customer1, VLAN : NA Learning interface: ge-2/0/0.0 Layer 2 flags: in_hash,in_ifd,in_ifl,in_vlan,in_rtt,kernel,in_ifbd Epoch: 1 Sequence number: 0 Learning mask: 0x00000004 MAC address: 00:21:59:0f:35:2b Routing instance: default-switch Bridging domain: customer1, VLAN : NA Learning interface: ge-2/0/1.0 Layer 2 flags: in_hash,in_ifd,in_ifl,in_vlan,in_rtt,kernel,in_ifbd Epoch: 3 Sequence number: 0 Learning mask: 0x00000004
Meaning
The output shows that the MAC addresses have been learned.
Making Sure That the Attached Devices Can Reach Each Other
Purpose
Verify connectivity.
Action
user@R1> ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=1.178 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.192 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=1.149 ms ^C --- 10.0.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.149/1.173/1.192/0.018 ms
user@R1> ping 10.0.0.3 PING 10.0.0.3 (10.0.0.3): 56 data bytes 64 bytes from 10.0.0.3: icmp_seq=0 ttl=64 time=1.189 ms 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=1.175 ms 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=1.178 ms 64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=1.133 ms ^C --- 10.0.0.3 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.133/1.169/1.189/0.021 ms
user@R2> ping 10.0.0.3 PING 10.0.0.3 (10.0.0.3): 56 data bytes 64 bytes from 10.0.0.3: icmp_seq=0 ttl=64 time=0.762 ms 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.651 ms 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.722 ms 64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.705 ms ^C --- 10.0.0.3 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.651/0.710/0.762/0.040 ms
Meaning
The output shows that the attached devices have established Layer 3 connectivity, with Device S1 doing transparent Layer 2 bridging.
Checking the Bridge Domain
Purpose
Display bridge domain information.
Action
user@S1> show bridge domain extensive
Routing instance: default-switch
Bridge domain: customer1 State: Active
Bridge VLAN ID: NA
Interfaces:
ge-2/0/0.0
ge-2/0/1.0
ge-2/0/2.0
Total MAC count: 3 Meaning
The output shows that bridge domain is active.
Checking the Bridge Statistics
Purpose
Display bridge statistics.
Action
user@S1> show bridge statistics
Local interface: ge-2/0/0.0, Index: 65543
Broadcast packets: 0
Broadcast bytes : 0
Multicast packets: 80
Multicast bytes : 8160
Flooded packets : 0
Flooded bytes : 0
Unicast packets : 1
Unicast bytes : 64
Current MAC count: 1 (Limit 1024)
Local interface: ge-2/0/2.0, Index: 324
Broadcast packets: 0
Broadcast bytes : 0
Multicast packets: 80
Multicast bytes : 8160
Flooded packets : 1
Flooded bytes : 74
Unicast packets : 52
Unicast bytes : 4332
Current MAC count: 1 (Limit 1024)
Local interface: ge-2/0/1.0, Index: 196613
Broadcast packets: 2
Broadcast bytes : 128
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 1
Flooded bytes : 93
Unicast packets : 51
Unicast bytes : 4249
Current MAC count: 1 (Limit 1024)Meaning
The output shows that bridge domain interfaces are sending and receiving packets.
Checking the Bridge Flooding
Purpose
Display bridge flooding information.
Action
user@S1> show bridge flood extensive
Name: __juniper_private1__
CEs: 0
VEs: 0
Name: default-switch
CEs: 3
VEs: 0
Bridging domain: customer1
Flood route prefix: 0x30003/51
Flood route type: FLOOD_GRP_COMP_NH
Flood route owner: __all_ces__
Flood group name: __all_ces__
Flood group index: 1
Nexthop type: comp
Nexthop index: 568
Flooding to:
Name Type NhType Index
__all_ces__ Group comp 562
Composition: split-horizon
Flooding to:
Name Type NhType Index
ge-2/0/0.0 CE ucst 524
ge-2/0/1.0 CE ucst 513
ge-2/0/2.0 CE ucst 523
Flood route prefix: 0x30005/51
Flood route type: FLOOD_GRP_COMP_NH
Flood route owner: __re_flood__
Flood group name: __re_flood__
Flood group index: 65534
Nexthop type: comp
Nexthop index: 565
Flooding to:
Name Type NhType Index
__all_ces__ Group comp 562
Composition: split-horizon
Flooding to:
Name Type NhType Index
ge-2/0/0.0 CE ucst 524
ge-2/0/1.0 CE ucst 513
ge-2/0/2.0 CE ucst 523 Meaning
If the destination MAC address of a packet is unknown to the device (that is, the destination MAC address in the packet does not have an entry in the forwarding table), the device duplicates the packet and floods it on all interfaces in the bridge domain other than the interface on which the packet arrived. This is known as packet flooding and is the default behavior for the device to determine the outgoing interface for an unknown destination MAC address.
Checking Layer 2 Learning
Purpose
Display Layer 2 learning information for all the interfaces.
Action
user@S1> show l2-learning interface
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-2/0/2.0 0
custom.. 1024 Forwarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-2/0/0.0 0
custom.. 1024 Forwarding
Routing Instance Name : default-switch
Logical Interface flags (DL -disable learning, AD -packet action drop,
LH - MAC limit hit, DN - Interface Down )
Logical BD MAC STP Logical
Interface Name Limit State Interface flags
ge-2/0/1.0 0
custom.. 1024 Forwarding