Introduction

RBFS interface numbers match the port numbers on the switch faceplate. An interface is named in the ifp-<chassis-ID>/<front-panel-block-number>/<port> format. For example, ifp-0/0/1.

Virtual interfaces follow the same structure, for example, lo-0/0/1 or memif-0/0/1.

Logical interfaces are numbered: ifl-<Node ID>/<Chip ID>/<Port ID>/<Unit ID>, for example ifl-0/0/1/1.

You can tag an interface address with a community or extended community. RBFS will create a direct route for each interface address. If a community or extended community is configured for an interface address, RBFS will add it to the direct route. Communities can be used in policies. For example, when redistributing direct routes, you can match these communities and define desired policy rules.

An unnumbered interface is a point-to-point interface that is not explicitly configured with a dedicated IP address and subnet. Instead, it borrows (or links to) from a loopback interface, and uses it as the source IP address for packets originating from the interface. The unnumbered interface can "borrow" the IP address from another interface that is already configured on the switch, thereby conserving network and address space.

When configuring IP unnumbered on an interface:

RBFS supports various interfaces such as physical interface, logical interface, and LAG interface and it uses various indicators to show the various states of interfaces. All interfaces have different states such as the following:

Physical Interface States:

The physical interface states include:

Logical Interface States:

The logical interface states include:

LAG Interface States

The LAG interface states include:

The interface state can either be Up or Down. Up shows that it is ready to pass packets, and Down shows that it is not ready to transmit packets. The operational state shows that the interface is operational and is ready to transmit packets. Oper state is Up only if both the Admin state and Link state are Up.

Path MTU Discovery (PMTUD) is a mechanism for discovering the MTU (Maximum Transmission Unit) size of all routers on a network path. This mechanism finds the MTU size allowed for each device for a TCP/UDP connection path on the network between two hosts.

For the Path MTU Discovery to work, you should set a Don’t Fragment (DF) flag (for IPv4 packets) in the IP headers of outgoing packets. Any device whose MTU is smaller than the packet along the path cannot forward the packet to the destination, instead that sends an ICMP 'Fragmentation Needed' (Type 3, Code 4) message to the source router.

The IPv6 packets do not allow fragmentation in transit, so the IPv6 headers do not have the ‘Don’t Fragment’ option. So when a router on the network path receives IPv6 packet that exceeds the MTU, the routers drop the packets and send back the corresponding ICMP message to the source router.

The advantages of PMTUD include:

To enable Path MTU Discovery, you must configure the MTU profile with the action redirect-to-cpu. So the CPU sends an ICMP message (that contains the allowed MTU of the router) to the source router. In this way, routers learn the MTU size of all routers on the path, so that they can determine the packet size in the network to avoid packet fragmentation.

For disabling the Path MTU Discovery, you can configure MTU profile with the action drop.

When an RBFS device receives MTU-violated packets, it responds with the ICMP error messages. ICMP error messages contain error codes that are sent to the source if fragmentation is required. The following are the types of ICMP error messages for the IPv4 and IPv6 packets.

ICMPv4 Message Types

The type field identifies the type of the message sent by the host. The type field contains more specific information about the error condition.

The table below lists the ICMPv4 message types.

Destination Unreachable uses the following code values to further describe the function of the ICMP message being sent.

ICMPv6 Message Types

The type field identifies the type of the message sent by the host. The type field contains more specific information about the error condition.

The table below lists the ICMPv6 message type.

You can change this behavior by enabling fragmentation. For more information about enabling host path fragmentation, see the section "Enabling Hostpath Fragmentation".

All outgoing packets are validated against the defined MTU on the egress path.

For information about configuring the MTU profile, see [mtu-profile-config].

If the maximum transmission unit (MTU) of an outgoing interface is less than the original packet that needs to be routed, the packet needs to be fragmented. RBFS supports IP fragmentation on the Q2C platforms. The packets are sent to the CPU. CPU manages the fragmentation by sending an ICMP message (requesting packet fragmentation) to the source router.

If the packet needs to be fragmented and the Do-Not-Fragment (DF) flag is specified, then the device is going to send an ICMP Error code "Fragmentation Needed and DF set" to the source.

By default, IPv6 fragmentation is always handled at source as the IPv6 packets are not fragmented in transit. When the transit device receives an MTU-violated packet, it sends a "Packet Too Big" ICMPv6 message that it cannot forward the packet because it is larger than the MTU of the outgoing link.

The Maximum Transmission Unit (MTU) is the size of the packet that is allowed in the network. MTU is configured as a MTU profile in the hardware. MTU profile configuration enables you to specify MTU size, MTU attachment point type, and MTU action. These profiles are attached to the interface entities (points) such as IFP, IFL, PPP, and L3 interfaces.

In the new generation silicon like Broadcom Qumran2C (Q2C), resources are conserved by creating profiles of the resources, and multiple entities like IFP, IFL and L3 interfaces utilize these profiles. To better manage MTU resources and platform capabilities, RBFS supports configuring MTU profiles and attaching these profiles to the attachment points.

Attachment Points: The MTU profiles are attached to the interface entities such as physical (IFP), logical (IFL), PPP, and L3 interfaces. RBFS supports the following attachment points for the MTU profiles:

Drop: If a router on the network path finds that the MTU size of a packet is larger than the configured MTU size of that router, it simply drops that packet.

redirect-to-cpu: If a router on the network path finds that the MTU size of a packet is larger than the configured MTU size of that router, it redirects that packet to CPU. CPU sends an ICMP error message requesting a packet fragmentation to the source router. This ICMP message also contains the MTU size of the router, so that the source router can learn the MTU size of the router on the path.

Not all features are necessarily supported on each hardware platform. Refer to the Platform Guide for the features and the sub-features that are or are not supported by each platform.

An additional restriction applies to ports on QAX-based platforms: because of hardware design, physical ports are grouped into quads (groups of 4, also known as port groups). Each quad must have the same physical parameters: speed, link-training, duplex.

The following tables are provided for easy identification of ports that need to have the same physical settings:

A PHY Quad can be associated with network interface (NIF) ports of identical type only. For example, a quad cannot be a mix of XLGE and XE ports. An exception is GE and XE ports which can coexist in the same quad. This means all the ports in a port group should have the same physical interface configuration (that is, speed/duplex/link-training). Ports in a port group are only allowed to support 1G and 10G speeds; any other combination is not allowed. If a port within a port group is misconfigured, then it would require changing the speeds/interface type of all ports within the port group to a different type and then back into the original type.