Reserved MPLS labels

A table showing some of the more important reserved MPLS labels. I’ll add more on these labels in a later post.

Label Value LDP TDP
0 IPv4 Explicit Null IPv4 Implicit Null
1 Router Alert IPv4 Implicit Null
2 IPv6 Explicit Null Router Alert
3 IPv4 Implicit Null IPv6 Explicit Null

eBGP multihop

eBGP multihop can be used to loadshare traffic across multiple links between eBGP peers.

Consider the topology below.

ebgp-multihop

By default eBGP sessions can only be established between directly connected interfaces.  If you want to connect to a non-connected interface or to a non-connected neighbor, you have to use the eBGP-multihop feature.

For this to work, you need to add a static route or routes if you want to load share so that BGP knows how to reach the non-connected interface.

To prevent the creation of loops through oscillating routes, the multihop will not be established if the only route to the multihop peer is the default route (0.0.0.0).(CCO)

The Video below shows how eBGP-multihop can be used to load-share traffic across multiple links between eBGP peers.  Only a single eBGP-multihop session is required, the underlying static routes will load share the traffic.  This can be confirmed in the FIB.

(Download and watch the video below on your iPod or iPhone).

The Flash plugin is required to view this object.

The commands used in the above scenario can be found below.

R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet1/0
ip address 10.0.0.1 255.255.255.252
!
interface FastEthernet1/1
ip address 10.0.0.5 255.255.255.252
!
router bgp 1
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
!
ip route 2.2.2.2 255.255.255.255 10.0.0.2
ip route 2.2.2.2 255.255.255.255 10.0.0.6

R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
ip address 10.0.0.2 255.255.255.252
!
interface FastEthernet1/1
ip address 10.0.0.6 255.255.255.252
!
interface Loopback1
ip address 192.168.1.1 255.255.255.0
!
router bgp 2
network 192.168.1.0
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
!
ip route 1.1.1.1 255.255.255.255 10.0.0.1
ip route 1.1.1.1 255.255.255.255 10.0.0.5

BGP – Prefix aggregation using a static route

My previous post on BGP prefix aggregation used the bgp “aggregate-address” command.  Another way to generate an aggregate is by using a static route.

Consider the toplology below.

bgp-small2Watch the video below to see how to configure a BGP aggregate using a static route.  Alternatively down the video here and watch it on your iPod.

The Flash plugin is required to view this object.

The commands used in the above video are listed below.

R1
!
interface FastEthernet1/0
ip address 10.0.0.1 255.255.255.252
!
router bgp 1
neighbor 10.0.0.2 remote-as 2
no auto-summary

R2
!
interface Loopback0
ip address 192.168.0.1 255.255.255.0
!
interface Loopback1
ip address 192.168.1.1 255.255.255.0
!
interface Loopback2
ip address 192.168.2.1 255.255.255.0
!
interface Loopback3
ip address 192.168.3.1 255.255.255.0
!
interface FastEthernet1/0
ip address 10.0.0.2 255.255.255.252
!
router bgp 2
no synchronization
bgp log-neighbor-changes
network 192.168.0.0
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
redistribute static
neighbor 10.0.0.1 remote-as 1
no auto-summary

BGP peer-groups and dynamic update peer groups

One of many optimizations for BGP is the peer-groups feature.

BGP peer-groups allow you to group BGP peers which have the same outbound policy.  There are 2 obvious benefits for doing this.

  1. Reduced the amount of configuration required.
  2. BGP can send a single update to many peers.

Both of these need some clarification.

Consider the topology below.

peer-groups

Lets look at the first benefit ie reducing the amount of configuration required.

If we did not use peer-group then we would have to configure additional lines of configuration to acheive the same thing.  Take the simple example below.

neighbor ipv4-iBGP peer-group
neighbor ipv4-iBGP remote-as 1
neighbor ipv4-iBGP update-source Loopback0

to then provision a new bgp peer we need to simple add the config below.

neighbor 2.2.2.2 peer-group ipv4-iBGP

lets talk numbers, suppose we had 20 iBGP peers in total we need 20  + 3 ie 23 line of config.  Without peer-groups we would need 20 *2 = 40 lines of config.

Now lets talk about the 2nd benefit ie the ability to generate a single update for multiple peers.

For BGP to send an update to its neighbor it first walks through the entire BGP table.  BGP tables can easily have over 100,000 prefixes.  Without peer-groups BGP must walk through the entire BGP table for each peer.  Assume you have 20 neighbors that amounts to walking through 100,000 * 20 = 2,000,000 prefixes, Ouch!.  Wouldn’t it be great if we could walk through the BGP table once and then replicate the update to all the peers.  Well thats were peer-groups come in handy.  If you have 20 peers in the same peer-group, BGP walks through the BGP table once and then replicates the update for all neighbors saving a lot of CPU cycles.

The downside of peer-groups is its lack of flexibility ie it is unlikely your vpnv4 sessions will share the same policy as your ipv4 sessions.  Ideally you would like to group your ipv4 sessions into one update group and your vpnv4 session into another group.  This is where dynamic update peer groups come into play.

Lets suppose you have an ipv4 and vpnv4 session between r1, r2 and r3.  ie a single session carrying multip AFI/SAFI pairs.  you would want to group your ipv4 sessions using one update policy and your vpnv4 sessions using another policy.  dynamic update peer groups lets you do just that.

There are some other benfits to using dynamic update peer policy – namely in the flexibility to modify policies as well as the fact that update groups are dynamically created by BGP.

The configuration used to configure dynamic update peer groups on R1 can be found below.

R1
!
router bgp 1
template peer-policy ipv4
send-community
exit-peer-policy
!
template peer-policy vpnv4
send-community extended
exit-peer-policy
!
template peer-session ipv4-iBGP
remote-as 1
update-source Loopback0
exit-peer-session
!
neighbor 2.2.2.2 inherit peer-session ipv4-iBGP
neighbor 3.3.3.3 inherit peer-session ipv4-iBGP
!
address-family ipv4
neighbor ipv4-iBGP send-community extended
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 inherit peer-policy ipv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 inherit peer-policy ipv4
!
exit-address-family
!
address-family vpnv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 inherit peer-policy vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 inherit peer-policy vpnv4
exit-address-family
!

Frame-Relay LMI

What is LMI?

LMI stands for Local Management Interface.

LMI messages are exchanged between routers(DTE) and frame-relay(DCE) switches.  At its very basic we can say the LMI messages act as keepalives between the router and frame-relay switch.  LMI messages also contain information which allows routers to detect new PVCs dynamically.  Cisco IOS currently supports 3 types of LMI Cisco, ANSI Annex D and Q.933-A.  In order for LMI to work you must use the same LMI type on both the router and frame-relay switch.

All three LMI types listen for LMI messages on reserverd DLCIs.

ANSI and q.933 listen for messages on DLCI 0 and Cisco LMI listens for messages on DLCI 1023.

Consider the topology below.

lmi

As you can see the LMI needs to match between the local DTE and the DCE ie they need to be speaking the same language.

Cisco IOS actually supports an LMI autosense feature which allows a router(DTE) to dynamically detect the LMI type configured on the connected frame-relay switch.

Also worth noting on the diagram.  I preconfigured a PVC on the frame-relay switch with a DLCI if 102 facing R1.  From the debug information you can see that this DLCI is passed to R1.

Virtual Private LAN service – VPLS

VPLS is a layer 2 VPN architecture which was designed for multipoint connectivity and broadcast capability.

Enterprisees who wish to appear connected on the same LAN segment can use this service.

Enterprise CE switches connect to PE routers who are enabled for VPLS.  When you configure VPLS on a PE you are effectivley creating a virtual switch inside the router.  CEs connect to the virtual switch via attachment circuits.  In a single VPLS domain you may have multiple PEs ie multiple virtual switches connected together using pseudowires.

I’ve tried to explain the concept of VPLS using the diagram below.

vpls1

ISIS Security part 2 – Video

A while ago I wrote a post on ISIS security. Here is a video to accompany the post.

Consider the topology below.

isis-security

There are five ways to configure ISIS authentication.  The methods differ in which packets they authenticate.  Some authentication methods will tear down ISIS adjacencies if there is an authentication mismatch, others will remove any ISIS routes.

In summary we said the following 5 authentication configuration options were available in IOS.

1-area-password command

2-domain-password command

3-isis authentication key command

4-authentication key command

5-isis password command.

We can group the 5 methods into 2 categories, those which authenticate ISIS hello packets and those which authenticate ISIS LSP, CSNP and PSNP packets.

The isis-authentication key and isis password commands are used to authenticate ISIS hello packets.

The area-password, domain-password and authentication key commands are used to authenticate ISIS LSP, CSNP and PSNP packets.

The video below shows how to configure the above options.  Click here to download and watch the video on your iPod.

The Flash plugin is required to view this object.

IRDP an alternative to HSRP, VRRP or GLBP

IRDP is an alternative technology to HSRP, VRRP, GLBP and the like.

IRDP makes use of ICMP messages to inform hosts of a default gateway they can use.

Consider the toplogy below.

irdp1

R2 and R3 announce themselves as default gateways to R1.  R2 is configured with an IRDP preference of 10 and R3 is configured with an IRDP preference of 20.  R1 chooses the lowest preference as the default gateway ie R2, however the Cisco implementation of this seem to conflict with the RFC(RFC 1256) which states:-

A Router Advertisement includes a “preference level” for each advertised router address.  When a host must choose a default router address it is expected to choose from those router addresses that have the highest preference level.

Watch the video below or click here to download and watch it on your iPod.

The Flash plugin is required to view this object.

The commands used in the irdp configuration can be found below.

R1
!
no ip routing
!
ip gdp irdp
!
interface FastEthernet1/0
ip address 10.0.0.1 255.255.255.0

R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
ip address 10.0.0.2 255.255.255.0
ip irdp
ip irdp preference 10

R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet1/0
ip address 10.0.0.3 255.255.255.0
ip irdp
ip irdp preference 20

Redistributing ISIS into OSPF

Someone asked me recently for an example of ISIS redistribution into OSPF. So here goes.

Consider the toplogy below.

isis-into-ospf

We redistribute ISIS into OSPF and vice versa on R2. We should then be able to ping R1 loopback from R3 loopback and vice versa.

Watch the video below or alternativly click here to download and watch it on your iPod.

The Flash plugin is required to view this object.

The commands used in the above video can be found below.

R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet1/0
description :connected to R2 fa1/0:
ip address 10.0.0.1 255.255.255.252
ip ospf network point-to-point
!
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.0.0.0 0.0.0.3 area 0
!

R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
description :connected to R1 fa1/0:
ip address 10.0.0.2 255.255.255.252
ip ospf network point-to-point
!
interface FastEthernet1/1
description :connected to R3 fa1/0:
ip address 10.0.0.5 255.255.255.252
ip router isis
!
router ospf 1
log-adjacency-changes
redistribute isis level-2 subnets
network 2.2.2.2 0.0.0.0 area 0
network 10.0.0.0 0.0.0.3 area 0
!
router isis
net 49.0001.0000.0000.0002.00
is-type level-2-only
redistribute ospf 1
!

R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet1/0
description :connected to R2 fa1/1:
ip address 10.0.0.6 255.255.255.252
ip router isis
!
router isis
net 49.0001.0000.0000.0003.00
is-type level-2-only
passive-interface Loopback0
!

ISIS level-1, level-2 areas, ISIS redistribution and ISIS default route origination.

I’m going to cover following three things in this post.

  1. Level-1, Level-1-2 and Level-2-only routers.  How to configure and what is the att bit
  2. Investigate the default behavior of the various levels with respect to routing updates.  ie are level-2 prefixes by default advertised to level-1 routers.
  3. Finally we will cover how to originate a default route within a level-2 area.

Consider the topology below.

isis-att-redist-area

Some important points worth noting:

  1. level-1-2 router HAVE to be in the same area as level-1 routers otherwise level-1 routers will not be able to form an adjacency with them.
  2. the level-1-2 router must have a level-2 adjacency with a router in another area for the att bit to be set in outgoing level-1 updates.
  3. By default level-1 routes are advertised to level-2 routers.
  4. By default level-2 routes are NOT advertised to level-1 routers.

Watch the video below or alternatively download the video and watch it on your iPod .

The Flash plugin is required to view this object.

The command used for the above configuration are:

R1

frame-relay switching
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Serial1/0
ip address 10.0.0.1 255.255.255.252
ip router isis
encapsulation frame-relay
clockrate 128000
no arp frame-relay
frame-relay map clns 200 broadcast
frame-relay map ip 10.0.0.2 200
no frame-relay inverse-arp
frame-relay intf-type dce
!
router isis
net 49.0001.0000.0000.0001.00
is-type level-1
passive-interface Loopback0
!

R2
!
frame-relay switching
!
interface Serial1/0
ip address 10.0.0.5 255.255.255.252
ip router isis
encapsulation frame-relay
no fair-queue
serial restart-delay 0
clockrate 128000
no arp frame-relay
frame-relay map ip 10.0.0.6 200
frame-relay map clns 200 broadcast
no frame-relay inverse-arp
frame-relay intf-type dce
isis circuit-type level-2-only
!
interface Serial1/1
ip address 10.0.0.2 255.255.255.252
ip router isis
encapsulation frame-relay
no arp frame-relay
frame-relay map clns 200 broadcast
frame-relay map ip 10.0.0.1 200
no frame-relay inverse-arp
isis circuit-type level-1
!
router isis
net 49.0001.0000.0000.0002.00
redistribute isis ip level-2 into level-1 distribute-list 100
!
access-list 100 permit ip any any

R3

interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Serial1/0
ip address 10.0.0.6 255.255.255.252
ip router isis
encapsulation frame-relay
serial restart-delay 0
no arp frame-relay
frame-relay map clns 200 broadcast
frame-relay map ip 10.0.0.5 200
no frame-relay inverse-arp
!
router isis
net 49.0002.0000.0000.0003.00
is-type level-2-only
passive-interface Loopback0
default-information originate