Archiv der Kategorie: JNCIE-ENT exam topics

Load-Balancing for IGP

In the following post I will explain you a usual configuration to achieve a load-balancing in JunOS. I will use the following topology for this example:

Topology for Load-Balancing
Topology for Load-Balancing

The routers are all configured as logical-systems on one M5 in my lab. The connection between them is made by one cross cable between port fe-0/2/2 and fe-0/2/3 via VLANs.

For this example I use OSPF as IGP with every router in Area 0.

IGP - OSPF
IGP – OSPF

 

Default Behavior

The default configuration in JunOS doesn’t have load-balancing enabled. Even if your IGP learned multiple equal-paths to the same destination, it shows you them in your routing-table, but only one next-hop is choosen to get installed into your forwarding-table.

We will take a  look at the loopback address of R4 from the point of view of R1. R1 see two equal-paths to 10.0.2.4, one goes to R2, the other one goes via R3. In the routing-table we can see that R1 „selected“  the route with the next-hop of R3. Also this next-hop got installed into the forwarding-table:

admin@router:R1> show route 10.0.2.4 extensive

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
10.0.2.4/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.0.2.4/32 -> {10.0.1.6}
 *OSPF Preference: 10
 Next hop type: Router
 Address: 0x8fd1078
 Next-hop reference count: 2
 Next hop: 10.0.1.2 via fe-0/2/2.50
 Next hop: 10.0.1.6 via fe-0/2/2.51, selected
 State: <Active Int>
 Age: 8:43 Metric: 2
 Area: 0.0.0.0
 Task: OSPF
 Announcement bits (1): 2-KRT
 AS path: I

admin@router:R1> show route forwarding-table destination 10.0.2.4 detail
Logical system: R1
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.0.2.4/32 user 0 10.0.1.6 ucst 1046 5 fe-0/2/2.51
<snip>

What does it mean for us? Only the next-hop pointing R3 will used to forward traffic to the destination 10.0.2.4 – ever! The next-hop will only change, if link goes down and the IGP has to choose another path.

Per-Packet or Per-Flow?

The load-balancing configuration in JunOS is a little bit misleading. It use a configuration option named „per-packet“. In fact every current platform (like MX) use a per-flow load-balancing. Only the early M20/M40 ABC-chipsets got a chip called C-chip, also known as „Internet Processor I“, which only could do per-packet load-balancing. Every later chipsets, including newer ABC-chipsets with Cf-chip „Internet Processor II“, do per-flow load-balancing. So don’t bother about it, just know it is always a per-flow load-balancing.

IGP Load-Balancing

To activate per-flow load-balancing you must configure a policy with an then-action „load-balance per-packet“. You can influence the load-balancing by adding a route-filter to the policy. Additionally youm ust apply this policy to the forwarding-table.

Here is configuration example:

admin@router:R1> show configuration | compare rollback 1
[edit logical-systems R1]
+ policy-options {
+     policy-statement load-balance {
+         then {
+             load-balance per-packet;
+         }
+     }
+ }
+ routing-options {
+     forwarding-table {
+         export load-balance;
+     }
+ }

admin@router:R1>

This configuration now allow the router to install all (upto 16 per default) equal-cost next-hops into your forwarding-table. With multiple next-hops your chipset now can do the per-flow load-balancing.

admin@router:R1> show route forwarding-table destination 10.0.2.4

 Logical system: R1
 Routing table: default.inet
 Internet:
 Destination Type RtRef Next hop Type Index NhRef Netif
 10.0.2.4/32 user 0 ulst 262142 3
 10.0.1.2 ucst 1044 5 fe-0/2/2.50
 10.0.1.6 ucst 1046 5 fe-0/2/2.51

Influence hashing

The hashing algorithm determine a flow by source/destination IP address and doesnt‘ include the TCP/UDP ports. If you want to include the layer-4 informations, you must apply the following configuration:

admin@router# show | compare

[edit]
+ forwarding-options {
+     hash-key {
+         family inet {
+             layer-3;
+             layer-4;
+         }
+     }
+ }

[edit]
admin@router#

(if you work with logical systems you cannot configure the hash-key, you must configure this globally…)

Configuration

Here you can download my configuration of the  Logical-Systems.

In one of my next posts, I will explain BGP multipath configuration and VPN load-balancing.

VRRPv2 interface and route tracking

This post is a followup to my previous post about VRRPv2 and explain simple interface and route tracking conifguration for VRRP.

Why do we need tracking?

In most cases you want check your uplink states to your core routers. Because the VRRP Master should be able to route your traffic into your core and should not be a black hole if your core router fails.

The VRRP configuration gives you two options to achieve this. With interface tracking, you can specify one or more interfaces to track on. This allows you to track for the physical link properties. The other option is route tracking, which allow you to track for a specific route which must be present in your routing-table.  Both options give you the ability to track your uplink states in a more or less simple way.

Interface Tracking

You can add a tracking for one or multiple interfaces. The tracked interface need a priority-cost, which will be substracted from the configured priority if the interface goes down.

vrrpv2_interface_tracking

admin@ROUTER:R2# show
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                        authentication-type md5;
                        authentication-key "$9$NC-wgoaUiHmg4QF/9pu"; ## SECRET-DATA
                        track {
                            interface fe-0/2/3.0 {
                                priority-cost 20;
                            }
                        }
                    }
                }
            }
        }
    }
}

Verify operation:

admin@ROUTER:R2> show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24
  Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 90, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.101s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:23:50
  Tracking: enabled
    Current priority: 90, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: enabled, Interface count: 1
      Interface     Int state   Int speed   Incurred priority cost
      fe-0/2/3.0    up               100m                       0
    Route tracking: disabled

admin@ROUTER:R2> edit
Entering configuration mode

[edit]
admin@ROUTER:R2# set interfaces fe-0/2/3 unit 0 disable

[edit]
admin@ROUTER:R2# commit
run sh vrrp decommit complete

[edit]
admin@ROUTER:R2# run show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24  
Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 70, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.325s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:24:40
  Tracking: enabled
    Current priority: 70, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: enabled, Interface count: 1
      Interface     Int state   Int speed   Incurred priority cost
      fe-0/2/3.0    down                0                      20
    Route tracking: disabled

[edit]
admin@ROUTER:R2#

Route Tracking

You can add a tracking for one or multiple routes. You must specify the exact prefix and the routing-instance, which is for inet.0 the name “default”.

vrrpv2_route_tracking

admin@ROUTER:R2# show
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                        authentication-type md5;
                        authentication-key "$9$NC-wgoaUiHmg4QF/9pu"; ## SECRET-DATA
                        track {
                            route 20.0.0.0/8 routing-instance default priority-cost 20;
                        }
                    }
                }
            }
        }
    }
}

This example output show you the active route tracking for 20.0.0.0/8. Because the route is not present in inet.0 the priority-cost of 20 will be substracted from the configured priority.

admin@ROUTER:R2# run show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24
  Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 70, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.315s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:35:49
  Tracking: enabled
    Current priority: 70, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: disabled
    Route tracking: enabled, Route count: 1
      Route               VRF name     Route state      Priority cost
      20.0.0.0/8          default      down                        20
 
[edit]
admin@ROUTER:R2#

VRRPv2 first steps and simple configuration

VRRPv2 for IPv4

To provide a LAN redundancy you could use Virtual Router Redundancy Protocol (VRRP). You must specify a Virtual IP Address (VIP) on the LAN, which should be available even if one router fails. A VRRP router could have two roles:  master or backup. A master router send hello packets to multicast mac destination. Everything is fine as long as the backup receive those packets. In case of a failure, for e.g. primary router shut down, the backup router don’t reveive any hello packet for a period of time it takeover the master role. This will trigger multiple actions:

  1. Sends out a gracious ARP to make sure that all switches refresh her CAM tables
  2. Accept traffic to the VIP (if accept-data configured)
  3. Reply to ARP request for the VIP
  4. Start sending VRRP hello packets periodically

The following topology shows you, that R1 and R2 using VRRP to provide LAN redundancy in the subnet 10.0.1.0/24 with VIP 10.0.1.1. Both routers also need an own interface address, which must be chosen from the subnet.

vrrpv2_basic

The configuration of VRRP belong to the ip address of the unit. You must specify a VRRP group which must be the same on both routers. This is an example for R1:

R1@ROUTER:R1> show configuration
interfaces {
   fe-0/2/0 {
       unit 0 {
           family inet {
               address 10.0.1.2/24 {
                   vrrp-group 1 {
                       virtual-address 10.0.1.1;
                   }
               }
           }
        }
    }
}

You can verify the prober operation of VRRP with “show vrrp” command.

R1@ROUTER:R1> show vrrp
Interface     State       Group   VR state VR Mode   Timer    Type   Address
fe-0/2/0.0    up              1   backup   Active      D  3.274 lcl    10.0.1.2
                                                               vip    10.0.1.1
                                                               mas    10.0.1.3

R1@ROUTER:R1> show vrrp detail
Physical interface: fe-0/2/0, Unit: 0, Address: 10.0.1.2/24
 Index: 69, SNMP ifIndex: 656, VRRP-Traps: disabled
 Interface state: up, Group: 1, State: backup, VRRP Mode: Active
 Priority: 100, Advertisement interval: 1, Authentication type: none
 Delay threshold: 100, Computed send rate: 0
 Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
 Dead timer: 3.510s, Master priority: 100, Master router: 10.0.1.3
 Virtual router uptime: 00:08:14
  Tracking: disabled
R1@ROUTER:R1>

As you can see, R1 is currently in backup state and R2 with address 10.0.1.3 is the master which provide the VIP.

The master/backup election is based on priority, which is per default 100  and as second tie-breaker the highest numerical ip address of the physical interface. That’s why R2 is currently the master.

Priority

You can influence the master election by changing the priority. In the following example we will change the priority of R2 to 90 which should result in a master switch to R1.

vrrpv2_priority

We add the priority option  to the configuration:

admin@ROUTER:R2> show configuration
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                    }
                }
            }
        }
    }
}

Now we can see that R1 is getting VRRP mastership:

R1@ROUTER:R1> show vrrp
interface     State       Group   VR state VR Mode   Timer    Type   Address
fe-0/2/0.0    up              1   master   Active      A  0.111 lcl    10.0.1.2 vip    10.0.1.1
R1@ROUTER:R1>

Authentification

We can add some security to the VRRP hello packets if we enable authentification. We can use plain-text or HMAC-MD5-96 authentication type.

admin@ROUTER:R2# show
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                        authentication-type md5;
                        authentication-key "$9$NC-wgoaUiHmg4QF/9pu"; ## SECRET-DATA
                    }
                }
            }
        }
    }
}

In fact authentication doesn’t provide you more security….  It cannot prevent you of other vrrp speakers in your LAN which  send out Gratuitous ARP….

Accept-Data

Only traffic with destination MAC Address of the VIP get routed out of the box.  Normally the VIP must not reply for any incoming IP Traffic.  In some cases, for e.g. you need for troubleshooting a ping to VIP, you want that the VIP accept traffic. In order to activate this feature, you must add to your configuration the „accept-data“ option.

R1@ROUTER:R1> show configuration
interfaces {
   fe-0/2/0 {
       unit 0 {
           family inet {
               address 10.0.1.2/24 {
                   vrrp-group 1 {
                       virtual-address 10.0.1.1;
                       accept-data;
                   }
               }
           }
        }
    }
}

Did you know? 

Multiple VRRP groups are needed if you have multiple routers or firewalls running VRRP in the same subnet. You could have up to 256 groups per LAN. As you can see in the following image, there are 2  firewalls and 2 routers which provide redundancy via VRRP.

vrrpv2_two_groups

To distinguish both VIPs from layer 2 point of view, you need different MAC addresses. The last octet (the VRID) of the MAC is derived from the group number. The VIP in group 1 uses 00:00:5e:00:01:01 and the VIP in group 2 uses 00:00:5e:00:01:02. This is a usual case in production networks, but need some agreements….

 

…There are many more configurations knobs in VRRP to blog about…. maybe in one of my next posts we take a look at the VRRP route and interfac tracking, VRRP Process Delegation to FPC or VRRPv3 configuration including IPv6…

Aggregated Ethernet and LACP

Aggregated Ethernet

Aggregated Ethernet interfaces could be used, if you need a bundle of multiple homogenous links for load-sharing or redundancy.  In JunOS you can configure this kind of bundles with or without LACP.

A bundle will be created with the aeX interface in JunOS. The following image shows you, that the interface ge-1/0/0 and ge-1/0/1 on R4 and R5 forming a bundle interface ae0.

AE_Simple

You must configure a device-count with minimum of 1. This is needed to create the initial amount of aeX  interfaces in the system.

admin@R4# run show interfaces terse | match ae
[edit]
admin@R4# set chassis aggregated-devices ethernet device-count 1
[edit]
admin@R4# commit
commit complete

[edit]
admin@R4# run show interfaces terse | match ae
ae0                     up    down

[edit]
admin@R4#

A simple aggregated ethernet configuration contain only the member links and the ae interface. You must specify the 802.3ad option to member links and a reference to the ae interface.

The following configuration shows you such a configuration:

On R4:

chassis {
    aggregated-devices {
        ethernet {
            device-count 1;
        }
    }
}
interfaces { 
    ge-1/0/0 {
        gigether-options {
            802.3ad ae0;
        }
    }
    ge-1/0/1 {
        gigether-options {
            802.3ad ae0;
        }
    }
    ae0 {
        unit 0 {
            family inet {
                address 10.0.0.1/30;
            }
        }
    }
}

On R5:

chassis {
    aggregated-devices {
        ethernet {
            device-count 1;
        }
    }
}
interfaces {
    ge-1/0/0 {
        gigether-options {
            802.3ad ae0; 
        }
    }
    ge-1/0/1 {
        gigether-options {
            802.3ad ae0;
        }
    }
    ae0 {
        unit 0 {
            family inet {
                address 10.0.0.2/30;
            }
        }
    }
}

Where does the MAC Address comes from?

Every ethernet interface need a MAC Address. This rule also match on aggregated ethernet interfaces. The MAC Address is chosen from an internal MAC Address pool of the juniper router and  not from the member links:

admin@R4> show chassis mac-addresses
MAC address information:
Public base address     00:05:85:3d:98:00
Public count            1008
Private base address    00:05:85:3d:9b:f0    <<<<  Starting base
Private count           16 

admin@R4> show interfaces ae0 | match Current
Current address: 00:05:85:3d:9b:f0, Hardware address: 00:05:85:3d:9b:f0

admin@R4>

 

LACP

Link Aggregation Control Protocol or LACP sending frames over the ethernet links to discover the other side and forming an aggregated ethernet.

LACP knows 2 modes of operation:

  • Active – as written in 802.1ax is a preference to speak regardless, which means it always sending LACPDU to the other side
  • Passive –  as written in 802.1ax is a preference not to speak unless spoken to, which means it only reply to LACPDU

The aggregated ethernet only comes up in the following combinations:

  • Active/Active
  • Active/Passive

Keep in mind, that LACP will never comes up if both sides are in Passive/Passive mode!

This is an example of a Active/Passive configuration between R4 and R5:

LACP_simple

On R4:

interfaces {
    ae0 {
        aggregated-ether-options {
            lacp {
                active;
            }
        }
    }
}

On R5:

interfaces {
    ae0 {
        aggregated-ether-options {
            lacp {
                passive;
            }
        }
    } 
}

You can use LACP to provide a link protection between multiple links.  Link-Protection with LACP is based on the link priority. The link with the highest priority is chosen to be primary link. Traffic will only forwarded over the primary link. All other links will be backup links, the order depends on the priority.

LACP_with_link_protection

After a primary link fails and come back, LACP could use a revertive mode. That means the traffic goes back to primary link. The options for revertive mode are:

  • revertive – automatic switch from backup to primary link
  • non-revertive – no automatic switch

If you use „non-revertive“ mode, you have to use a request command for the manual switch:

admin@R4> request interface revert aex

Example configuration for link-protection with LACP:

On R4:

interfaces {
    ge-1/0/0 {
        gigether-options {
            802.3ad {
                lacp {
                    port-priority 128;
                }
            }
        }
    }
    ae0 {
        aggregated-ether-options {
             lacp { 
                 link-protection {
                     revertive;
                 }
             }
        }
    }
}

On R5:

interfaces {
    ae0 {
        aggregated-ether-options {
            lacp {
                link-protection {
                    revertive;
                }
            }
        }
    }
}

Link-Protection without LACP

You can configure a link protection for the member links in a primary/backup fashion. Traffic goes always over the primary link. If the primary link fails, the backup link would be used.  After failure of the primary link, the traffic will goes over the backup link. Even if the primary link comes back, the traffic will not automatically switch back. You have to use a request command for the manual switch:

admin@R4> request interface revert aex

Example configuration for link-protection without LACP:

AE_with_link_protection

On R4:

interfaces {
    ge-1/0/0 {
        gigether-options {
            802.3ad {
                ae0;
                primary;
            }
        }
    }
    ge-1/0/1 {
        gigether-options {
            802.3ad {
                ae0;
                secondary;
            }
        }
    }
    ae0 {
        aggregated-ether-options {
            link-protection;
        }
    }
}

On R5:

interfaces {
    ge-1/0/0 {
        gigether-options {
            802.3ad {
                ae0;
                primary;
            }
        }
    }
    ge-1/0/1 {
        gigether-options {
            802.3ad {
                ae0;
                secondary;
            }
        }
    }
    ae0 {
        aggregated-ether-options {
            link-protection;
        }
    }
}

Link Speed

To change the link speed of the bundle, you must configure on both routers:

interfaces {
    ae0 {
        aggregated-ether-options {
            link-speed 1g;
        }
    }
}

Minimum Member-Links

You can specify the minimum number of links, which should be up to form a link aggregation. Keep in mind that the default value is 1.

On both routers:

interfaces {
    ae0 {
        aggregated-ether-options {
            minimum-links 2;
        }
    }
}

Tagging with 802.1q

It is possible to configure 802.1q tagging on the ae interface. In order to do this you must configure  “vlan-tagging” on the ae interface and a “vlan-id <number>” on every unit.

AE_with_dot1q

On R4:

interfaces {
    ae0 {
        vlan-tagging;
        unit 100 { 
            vlan-id 100;
            family inet {
                address 10.0.0.1/30;
            }
        }
    }
}

On R5:

interfaces {
    ae0 {
        vlan-tagging;
        unit 100 {
            vlan-id 100;
            family inet {
                address 10.0.0.2/30;
            }
        }
    }
}

Load-Balancing

The load-balancing on aggregated ethernet is based on a hash-key. This hash-key include the source/destination mac addresses and the input logical interface number. If you want a load-balancing by source/destination ip addresses or layer-4 protocols  like udp/tcp then you must included them as well in the hash-key. This could be done by the following configuration:

forwarding-options {
    hash-key {
        family multiservice {
            source-mac;
            destination-mac;
            payload {
                ip {
                    layer-3;
                    layer-4;
                }
            }
        }
    }
}

If don’t want, that both source and destination ip address should be used, you can add the option “destination-ip-only” or “source-ip-only” to “layer-3”.