2008 December

Dec 15 2008

IPv4 BGP multicast

IPv4 BGP multicast announcements can be somewhat confusing. It took a while to get my head around it, so now that I have, I will try to explain.

I have set up the topology below.

Everything has been configured in the above scenario EXCEPT the IPv4 BGP multicast session between RP and ASBR-RP. I want to show how you can change the multicast path using IPV4 BGP multicast.

lets start by understanding BGP AS2

The receiver sends a join for group 224.1.1.1, Net-Edge2 receives the igmp join and forwards a PIM JOIN to ASBR-RP. We can now see a (*,G) entry in the multicast routing table as below.

ASBR-RP#show ip mroute (*, 224.1.1.1), 00:24:06/00:02:42, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:24:06/00:02:42

Pretty straight forward so far.

Now lets look at BGP AS1 from an IPv4 routing perspective

AS1 runs ISIS as the IGP. IPv4 192.168.1.0/24 and 2.2.2.2/32 prefixes are advertised into ISIS. ASBR1 is the only device which runs BGP in AS1. ASBR1 then advertises 192.168.1.0/24 and 2.2.2.2/32 to AS2 as IPv4 prefixes. If we examine the IPv4 routing table on ASBR-RP we can see it has an entry for 192.168.1.0/24 and 2.2.2.2/32 as below.

ASBR-RP#sh ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "bgp 2", distance 20, metric 10 Tag 1, type external Last update from 10.0.0.1 00:14:09 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:14:09 ago Route metric is 10, traffic share count is 1 AS Hops 1 Route tag 1

ASBR-RP#sh ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "bgp 2", distance 20, metric 20 Tag 1, type external Last update from 10.0.0.1 00:05:20 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:05:20 ago Route metric is 20, traffic share count is 1 AS Hops 1 Route tag 1

nothing majorly complicated here.

We now setup an MSDP session using the basic config between RP and ASBR-RP using the commands below on RP and ASBR-RP respectivly.

RP#sh run | in msdp ip msdp peer 10.0.0.6 connect-source FastEthernet1/1 remote-as 2 ip msdp cache-sa-state

ASBR-RP

ip msdp peer 10.0.0.5 connect-source FastEthernet1/0 remote-as 1 ip msdp cache-sa-state

no rocket science here.

Now lets kick off some multicast traffic from the source destined to 224.1.1.1 from 192.168.1.1

We should see an entry in the multicast routing table of RP in AS1.

RP#show ip mroute 224.1.1.1 (*, 224.1.1.1), 00:00:06/stopped, RP 2.2.2.2, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null

(192.168.1.1, 224.1.1.1), 00:00:06/00:02:53, flags: PA Incoming interface: FastEthernet1/0, RPF nbr 11.0.0.1 Outgoing interface list: Null

Everything good so far.

MSDP should now advertise this source to its peer ASBR-RP in AS 2. Lets check to see if this has happened.

ASBR-RP#show ip msdp sa-cache MSDP Source-Active Cache - 1 entries (192.168.1.1, 224.1.1.1), RP 2.2.2.2, BGP/AS 0, 00:01:50/00:05:29, Peer 10.0.0.5

yep we can see it.

Now lets check to see whether we can see the entry in the mcast table on ASBR-RP.

ASBR-RP#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:12:56/00:03:11, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:12:07/00:03:11

(192.168.1.1, 224.1.1.1), 00:12:56/00:03:28, flags: T Incoming interface: FastEthernet1/1, RPF nbr 10.0.0.1 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:12:07/00:03:11

Yep, we can see it, but notice that the incoming interface is being shown as fastethernet1/1 and the RPF neighbor is 10.0.0.1. This is due to the fact that the PIM Join message was sent using the ipv4 routing table and as such was routed via the lower link in the diagram. This is not what we were trying to acheive, we wanted the SPT tree to flow over the upper link, upon which we configured MSDP. To fix this we simply setup a IPv4 BGP multicast session as follows on RP.

router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.0.0.6 remote-as 2 ! address-family ipv4 multicast neighbor 10.0.0.6 activate no auto-summary network 192.168.1.0 exit-address-family

Check on ASBR-RP that the multicast IPv4 prefix is being learnt.

ASBR-RP#sh ip bgp ipv4 multicast Network Next Hop Metric LocPrf Weight Path *> 192.168.1.0 10.0.0.5 10 0 1 i ASBR-RP#

Its also worth noting that this prefix does not enter the unicast routing table as you can see below.

ASBR-RP#sh ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "bgp 2", distance 20, metric 20 Tag 1, type external Last update from 10.0.0.1 00:04:22 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:04:22 ago Route metric is 20, traffic share count is 1 AS Hops 1 Route tag 1

Now if we check the multicast routing table on ASBR-RP we will see the following.

ASBR-RP#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:25:48/00:03:06, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:24:59/00:03:06

(192.168.1.1, 224.1.1.1), 00:25:48/00:03:27, flags: T Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5, Mbgp Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:24:59/00:03:06

As you can see the incoming interface is now the upper link in the diagram and the RPF neighbor has changed to 10.0.0.5.

Therefore we can conclude the following, the IPv4 BGP multicast entries are used to send PIM Joins as well as conduct RPF checks on incoming multicast data traffic. To further prove that the IPv4 BGP multicast entries are used to forward PIM Join messages we could remove the IPv4 prefixes which are being advertised over the lower link and see if we still have a SPT to ASBR-RP.

ASBR-RP#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:01:19/00:03:26, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:01:03/00:03:26

(192.168.1.1, 224.1.1.1), 00:01:19/00:03:22, flags: T Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5, Mbgp Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:01:03/00:03:25

Yep, its still there.

However, now that we have withdrawn the IPv4 prefixes from AS2 Net-Edge2 will no longer we able to build an SPT to the source as it has no route to 192.168.1.1 but rather will have to use the shared tree as you can see below.

net-edge2#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 02:42:16/00:02:58, RP 4.4.4.4, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1 Outgoing interface list: Loopback0, Forward/Sparse, 02:42:16/00:02:17

(192.168.1.1, 224.1.1.1), 00:02:51/00:00:08, flags: LJ Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 00:02:51/00:02:17

If we reinject the IPv4 prefix 192.168.1.0/24 using BGP on ASBR1 and then reexamine the multicast entry for 224.1.1.1 on net-edge2 we see the following.

net-edge2#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:00:09/stopped, RP 4.4.4.4, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1 Outgoing interface list: Loopback0, Forward/Sparse, 00:00:09/00:02:50

(192.168.1.1, 224.1.1.1), 00:00:00/00:02:59, flags: LJT Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1 Outgoing interface list: Loopback0, Forward/Sparse, 00:00:00/00:02:59

As you can see net-edge2 is now using the (S,G) tree. MAGIC:-)

Anyway, I hope that makes sense.

By zismail • BGP, CCIE SP, MSDP, Multicast, PIM-SM • 2 • Tags: CCIE SP, IPv4 BGP Multicast, MSDP, Multicast

Dec 13 2008

ISIS Security

ISIS uses four types of packets they are, hello, LSPs, CSNPs and PSNPs. The different authentication methods insert passwords into different packets. Some of the security methods allow MD5 as well as clear text authentication. The 5 password configuration options for ISIS are as follows:-

1-area-password
2-domain-password
3-authentication key-chain
4-isis authentication key-chain
5-isis password

Both the area-password and domain-password options will insert a clear text password into LSPs, CSNPs and PSNPs. However the area-password will only insert a password in level-1 LSPs, CSNPs and PSNPs and the domain-password will only insert a password into level-2 LSPs, CSNPs and PSNPs. Both commands are applied at the router configuration mode. Both commands do NOT insert a password into the ISIS hello packet.

Click here to see a Level-1 capture using the area-password
Click here to see a Level-2 capture using the domain-password

Options 3 and 4 above ie authentication key-chain and isis authentication key-chain give the user the option of using either clear text or MD5 authentication. The fundamental difference between authentication key-chain and isis authentication key-chain is that the former is applied at router configuration mode and inserts a password into all LSPs, CSNPs and PSNPs whereas the latter is applied at the interface level and only applies a password into hello packets.

Click here to see a capture using a clear text authenication key (router configuration mode)
Click here to see a capture using a MD5 authenication key (router configuration mode)

Click here to see a capture using a clear text isis authenication key (interface configuration mode)

Option 5 ie the isis password only provides for clear text authentication and is applied at the interface configuration level.

Click here to see a capture using the clear text isis password (interface configuration mode)

Now lets see what happens if we configure an MD5 authentication key under the router configuration mode and a clear text password under the interface configuration mode using the isis authentication key.

We will use the syntax below.

authentication key under router configuration mode

key chain ZARAR key 1 key-string ZARAR

router isis authentication mode md5 authentication key-chain ZARAR

isis authentication key under interface configuration mode

key chain ZARAR-OVERRIDE key 1 key-string ZARAR-OVERRIDE

interface FastEthernet1/0 isis authentication mode text isis authentication key-chain ZARAR-OVERRIDE

As you can see from the capture using wireshark, all the level-1 LSPs, CSNPs are using MD5 authentication and all Level-1 hellos are using a clear text password ZARAR-OVERRIDE

Click here to see wireshark capture of the above configuration.

To summarize

Method	Clear Text	MD5	Password inserted into LSP	Password inserted into CSNP	Password inserted into PSNP	Password inserted into Hello
area-password	yes	no	yes	yes	yes	no
domain-password	yes	no	yes	yes	yes	no
authentication-key	yes	yes	yes	yes	yes	no
isis authentication-key	yes	yes	no	no	no	yes
isis password	yes	no	no	no	no	yes

For further information please click the link below.

http://www.cisco.com/en/US/partner/docs/ios/iproute/command/reference/irp_is1.html#wp1012820

By zismail • CCIE SP, IS-IS • 1 • Tags: CCIE SP, IS-IS

Dec 4 2008

CCIE Service Provider Resource

Congratulations to Matt Dinham for passing his SP exam, and thanks even more for sharing the link with us http://pwp.netcabo.pt/amsoares/dynamips/dynamips.htm. I’ve just had a quick look and this guy Antonio Soares has done a lot of hard work.

Please Enjoy

By zismail • CCIE SP • 2 • Tags: CCIE SP

Dec 4 2008

Multicast – PIM Sparse Mode

Consider the topology below.

Once your IGP and infrastrucutre links are all configured use the following to enable multicast sparse mode.

Step 1 – Enable multicast globally on all routers

multicast-routing

Step 2 – Enable multicast on all interfaces

interface Serial1/0.1 point-to-point ip pim sparse-mode

Step 3 – Configure an RP on a devices

ip pim rp-address 2.2.2.2

When you enable pim sparse mode on an interface you will see the following.

R2#sh ip pim interface

Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.0.0.2 Serial1/0.1 v2/S 1 30 1 0.0.0.0 10.0.0.5 FastEthernet2/0 v2/S 0 30 1 10.0.0.5 R2#

Notice on FastEthernet2/0 there are 0 neighbors. This is due to the fact that we havent enabled PIM sparse mode on R3.

Lets enable PIM sparse mode on R3 and see what happens.

R3(config)#interface FastEthernet1/0 R3(config-if)#ip pim sparse-mode R3(config-if)# 00:34:46: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 10.0.0.6 on interface FastEthernet1/0 (vrf default) R3(config-if)#end

Now if we go back to R2 and run the sh ip pim interface command we should see be able to see the neighbor.

R2#sh ip pim interface

Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.0.0.2 Serial1/0.1 v2/S 1 30 1 0.0.0.0 10.0.0.5 FastEthernet2/0 v2/S 1 30 1 10.0.0.6 R2#

If we then simulate a igmp join on R3 using the commands below and we debug ip igmp we can see R3 send a Report for 224.1.1.1 as below.

interface FastEthernet0/0 ip address 20.20.20.20 255.255.255.0 ip pim sparse-mode ip igmp join-group 224.1.1.1

00:46:08: IGMP(0): Send v2 Report for 224.1.1.1 on FastEthernet0/0 00:46:08: IGMP(0): Received v2 Report on FastEthernet0/0 from 20.20.20.20 for 224.1.1.1 00:46:08: IGMP(0): Received Group record for group 224.1.1.1, mode 2 from 20.20.20.20 for 0 sources 00:46:08: IGMP(0): Updating EXCLUDE group timer for 224.1.1.1 00:46:08: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,224.1.1.1) by 0 R3(config-if)#end

Now lets check the mroute table on R3

R3#sh ip mroute IP Multicast Routing Table (*, 224.1.1.1), 00:02:41/00:02:29, RP 2.2.2.2, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:41/00:02:29

the key things worth noting here are:- The *, G entry is using the RP 2.2.2.2. R3 is expecting to receive the multicast traffic on interface FastEthernet1/0. The RPF neighbor is 10.0.0.5. Finally the outgoing interface ie where the IGMP join was seen is FastEthernet0/0.

Now let us simulate an a source for this multicast group on R1.

R1#ping Protocol [ip]: Target IP address: 224.1.1.1 Repeat count [1]: 10000 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Interface [All]: FastEthernet2/1 Time to live [255]: Source address: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

If we turn on debugging on R2 using debug ip pim we see the following

00:57:45: PIM(0): Received v2 Register on Serial1/0.1 from 10.0.0.1 00:57:45: for 10.10.10.10, group 224.1.1.1 00:57:45: PIM(0): RPF lookup failed to source 10.10.10.10 00:57:45: PIM(0): Send v2 Register-Stop to 10.0.0.1 for 10.10.10.10, group 224.1.1.1

As you can see the RPF failed. This is because i have forgotten to advertise the 10.10.10.10 into IS-IS.

Lets see what happens once we advertise the 10.10.10.10 into IS-IS.

00:58:50: PIM(0): Received v2 Register on Serial1/0.1 from 10.0.0.1 00:58:50: PIM(0): Send v2 Register-Stop to 10.0.0.1 for 0.0.0.0, group 0.0.0.0

The source has registered successfully with the RP, however there are no subscribers at the moment so a register stop is generated.

If we examine the multicast routing table on R2 we see the following.

R2#sh ip mroute (*, 224.1.1.1), 00:01:37/stopped, RP 2.2.2.2, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null

(10.10.10.10, 224.1.1.1), 00:01:37/00:01:23, flags: P Incoming interface: Serial1/0.1, RPF nbr 10.0.0.1 Outgoing interface list: Null

As you can see there is an S,G entry for the group however the outgoing interface list(OIL) is Null.

Now lets resimulate the igmp join in R3 and see the change in the multicast routing table.

R2#sh ip mroute (*, 224.1.1.1), 00:05:20/00:02:50, RP 2.2.2.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:00:40/00:02:50

(10.10.10.10, 224.1.1.1), 00:02:18/00:00:41, flags: Incoming interface: Serial1/0.1, RPF nbr 10.0.0.1 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:00:40/00:02:49

As you can see the OIL now contains FastEthernet 2/0 which is the interface connected to R3.

Also if we check the mroute table on R3 we see the following.

R3#sh ip mroute (*, 224.1.1.1), 00:03:41/00:00:44, RP 2.2.2.2, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:03:39/00:02:08

(10.10.10.10, 224.1.1.1), 00:02:16/00:00:44, flags: LJ Incoming interface: Null, RPF nbr 10.0.0.10 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:16/00:02:08

As you can see the incoming interface for the multicast traffic is fastethernet 1/0.

Now lets bring a PIM neighborship between R1 and R3.

If we check the mroute table on R3 we can see that the R3 has joined the source tree.

R3#sh ip mroute (*, 224.1.1.1), 00:09:49/00:00:39, RP 2.2.2.2, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:09:48/00:02:58

(10.10.10.10, 224.1.1.1), 00:02:21/00:00:39, flags: LJ Incoming interface: FastEthernet1/1, RPF nbr 10.0.0.10 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:21/00:02:58

If we look at R1 we can see the source of the tree.

R1#sh ip mroute (*, 224.1.1.1), 00:18:01/stopped, RP 2.2.2.2, flags: SPF Incoming interface: Serial1/0.1, RPF nbr 10.0.0.2 Outgoing interface list: Null

(10.10.10.10, 224.1.1.1), 00:18:01/00:03:25, flags: FT Incoming interface: FastEthernet2/1, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:04:36/00:02:38 Serial1/0.1, Forward/Sparse, 00:10:18/00:03:26

By zismail • CCIE SP, Multicast, PIM-SM • 0 • Tags: CCIE SP, Multicast, PIM

Dec 3 2008

RPF Check

To prevent loops in a multicast network, an RPF check is carried out on all multicast traffic.

When a multicast packet enters a router, the router carries out an RPF check on the source address of the packet using the the unicast routing table.

Lets examine the toplogy below.

Now lets suppose the source sends a multicast packet to R1 who then forwards it to R2. R2 checks the source address of the multicast packet against the unicast routing table. If the exit interface in the unicast routing table for that source does not match the interface on which the multicast packet was received the RPF check fails and the multicast packet is dropped.

By zismail • CCIE SP, Multicast • 0 • Tags: CCIE SP, Multicast, RPF

Dec 2 2008

Traffic Engineering – Fast Reroute

Fast reroute (FRR) is one of the main drivers for implementing Traffic Engineering. Fast Reroute uses the concept of a backup tunnel. When the path used by the primary tunnel is detected as down, traffic is dynamically switched over to the backup tunnel.

Fast reroute provides two types of protection.

1-Link Protection

2-Node Protection

Lets examine the topology below.

Link Protection

Lets suppose the primary path for a tunnel whose headend is at PE1 and tailend is at PE2, that the primary path is via PE3.

If the link between PE1 and PE3 fails then fast reroute link protection reroutes the traffic using the following path.

PE1–>P1–>PE3–>PE2

As you can see the reroute mechanism has rereouted around the failed link. These type of FRR backup tunnel are known as Next-Hop back tunnels(NHOP).

Node Protection

Lets suppose the primary path for a tunnel whose headend is at PE1 and tailend is at PE2, that the primary path is via PE3 and not P1.

If the node PE3 fails then fast reroute link protection reroutes the traffic using the following path.

PE1–>P1–>PE2

As you can see the reroute mechanism has rereouted around the failed node. These type of FRR backup tunnels are known as Next-Next Hop back tunnels(NNHOP).

Configuring FRR

The configuration of Traffic engineering has evolved over the years, In the beginning both the primary and backup tunnel had to be configured manually. Then the backup tunnel evolved to be dynamic configuration and now even the primary tunnel is almost fully automated.

Below we will show an how to configure an autotunnel Primary and Backup

To configure the autotunnel on PE1 simply enter the following command.

PE1(config)#mpls traffic-eng auto-tunnel primary onehop

You will then see a primary tunnel comeup for each directly connected traffic engineering enabled neighbor.

00:06:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65336, changed state to up 00:06:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65337, changed state to up

PE1#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT PE1_t65336 4.4.4.4 - Fa2/0 up/up PE1_t65337 2.2.2.2 - Se1/1.1 up/up Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails

To configure the backup tunnels use the following command:

PE1(config)#mpls traffic-eng auto-tunnel backup

Shortly after entering the above command you will see 2 backup tunnels come up.

PE1(config)# 00:03:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65436, changed state to up 00:03:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel65437, changed state to up

The command below shows that tunnels 65436 and 65437 are acting as backup tunnels for 65336 and 65337.

PE1#show ip rsvp fast-reroute Primary Protect BW Backup Tunnel I/F BPS:Type Tunnel:Label State Level Type ------ ------- -------- ------------- ------ ----- ------ PE1_t65337 Se1/1.1 0:G Tu65436:0 Ready any-unl Nhop PE1_t65336 Fa2/0 0:G Tu65437:0 Ready any-unl Nhop

I’ll talk more about these tunnels in another post.

By zismail • CCIE SP, Traffic Engineering • 0 • Tags: CCIE SP, TE, Traffic Engineering

Dec 2 2008

How does TE detect a neighbor-down

There are three “down notifications” which cause MPLS nodes to switch traffic onto their FRR backup tunnels.

1-Interface “down notification”

2-RSVP Hello neighbor “down notification”

3-BFD neighbor “down notification”

Some interfaces such as POS have very quick interface down notification ie around 50ms. If a router detects a link down it reroutes the traffic via a backup tunnel.

There are some instances where the router may not experience an interface down due to an intermediary device such as an ethernet switch. In these cases the router can rely on either RSVP hello neighbor “down notifications” or BFD “down notifications”.

RSVP hello protocol mechanics

An RSVP hello enabled router sends out RSVP hellos every interval. An RSVP hello enabled neighbor responds with an RSVP hello Ack. If the sending node does not receive an RSVP hello Ack for four intervals it declares the neighbor as down and notifies FRR.

There are two configurable paramaters for RSVP hellos.

1-Hello interval

2-Number of Ack misses before declaring a neighbor as down.

The hello interval is configured using the following command.

ip rsvp signalling hello fast-reroute refresh interval

The default value is 10000 milliseconds (10 seconds), which is hardly fast convergence. The interval values which can be configured are from 1000 to 30000 (1 to 30 seconds). Which even if use 1 second is not that fast.

The number of Ack misses before declaring a neighbor down can be configured using.

ip rsvp signalling hello fast-reroute refresh misses msg-count

The default for the msg-count argument is 4.

BFD protocol mechanics

BFD establishes a session with neighboring routers. BFD then sends accelerated control messages similar to IGP hellos.

To enable BFD for use with FRR there are two configuration steps.

1-Enable BFD globally

2-Enable BFD at interface level.

To enable BFD globally use the command.

ip rsvp signalling hello bfd

To enable BFD at interface level use the command.

interface gig1/0 ip rsvp signalling hello bfd bfd interval milliseconds min_rx milliseconds multiplier interval-multiplier

BFD has the advantage over RSVP hellos in that it can acheive sub-second convergence.

By zismail • CCIE SP, Traffic Engineering • 2 • Tags: BFD, CCIE SP, TE, Traffic Engineering

Dec 1 2008

Configuring Traffic Engineering using the explicit path-option

Lets start by configuring a dynamic tunnel between PE1 and PE2 using the tunnel configuration below.

interface Tunnel100 ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 512 tunnel mpls traffic-eng path-option 1 dynamic

Now lets examine the path the tunnel takes.

PE1#show mpls traffic-eng tunnels tunnel 100

Name: PE1_t100 (Tunnel100) Destination: 3.3.3.3 Status: Admin: up Oper: up Path: valid Signalling: connected

path option 1, type dynamic (Basis for Setup, path weight 20)

Config Parameters: Bandwidth: 512 kbps (Global) Priority: 5 5 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 512 bw-based auto-bw: disabled

InLabel : - OutLabel : Serial1/1.1, 20 RSVP Signalling Info: Src 1.1.1.1, Dst 3.3.3.3, Tun_Id 100, Tun_Instance 3 RSVP Path Info: My Address: 10.0.0.1 Explicit Route: 10.0.0.2 10.0.0.6 3.3.3.3 Record Route: NONE Tspec: ave rate=512 kbits, burst=1000 bytes, peak rate=512 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=512 kbits, burst=1000 bytes, peak rate=512 kbits Shortest Unconstrained Path Info: Path Weight: 20 (TE) Explicit Route: 10.0.0.2 10.0.0.6 3.3.3.3 History: Tunnel: Time since created: 4 minutes, 50 seconds Time since path change: 3 minutes, 53 seconds Current LSP: Uptime: 3 minutes, 53 seconds Selection: reoptimation Prior LSP: ID: path option 1 [2] Removal Trigger: configuration changed PE1#

If you examine the Explicit Route you can see the actual path the tunnel takes(Due to the limited topology there is only one path the tunnel could take). If we want we can actually force the tunnel to take this path by defining an explicit path.

Defining an explicit path takes two steps.

Step 1 – Define the explicit-path ie the path the TE tunnel will take

PE1(config)#ip explicit-path name DEBUGALL enable PE1(cfg-ip-expl-path)# PE1(cfg-ip-expl-path)#next-address 10.0.0.2 Explicit Path name DEBUGALL: 1: next-address 10.0.0.2 PE1(cfg-ip-expl-path)#next-address 10.0.0.6 Explicit Path name DEBUGALL: 1: next-address 10.0.0.2 2: next-address 10.0.0.6 PE1(cfg-ip-expl-path)#next-address 3.3.3.3 Explicit Path name DEBUGALL: 1: next-address 10.0.0.2 2: next-address 10.0.0.6 3: next-address 3.3.3.3 PE1(cfg-ip-expl-path)#exit

Step 2 – attach the explicit path to the TE tunnel.

interface Tunnel100 tunnel mpls traffic-eng path-option 1 explicit name DEBUGALL

Verify the tunnel is up and using the explicit path.

PE1#show mpls traffic-eng tunnels tunnel 100

Name: PE1_t100 (Tunnel100) Destination: 3.3.3.3 Status: Admin: up Oper: up Path: valid Signalling: connected

path option 1, type explicit DEBUGALL (Basis for Setup, path weight 20)

Looks good.

By zismail • CCIE SP, Traffic Engineering • 3 • Tags: CCIE SP, TE, Traffic Engineering

1 2

Categories

Tags