Abstract

This publication briefly covers the use of 3rd party next-hops in OSPF, RIP, EIGRP and BGP routing protocols. Common concepts are introduced and protocol-specific implementations are discussed. Basic understanding of the routing protocol function is required before reading this blog post.

Overview

Third-party next-hop concept appears only to distance vector protocol, or in the parts of the link-state protocols that exhibit distance-vector behavior. The idea is that a distance-vector update carries explicit next-hop value, which is used by receiving side, as opposed to the “implicit” next-hop calculated as the sending router’s address – the source address in the IP header carrying the routing update. Such “explicit” next-hop is called “third-party” next-hop IP address, allowing for pointing to a different next-hop, other than advertising router. Intitively, this is only possible if the advertising and receiving router are on a shared segment, but the “shared segment” concept could be generalized and abstracted. Every popular distance-vector protocols support third party next-hop – RIPv2, EIGRP, OSPF and BGP all carry explicit next-hop value. Look at the figure below – it illustrates the situation where two different distance-vector protocols are running on the shared segment, but none of them runs on all routers attached to the segment. The protocols “overlap” at a “pivotal” router and redistribution is used to provide inter-protocol route exchange.

Per the default distance-vector protocol behavior, traffic from one routing domain going into another has cross the “pivotal” router, the router where the two domains overlap (R3 in our case) – as opposed to going directly to the closes next-hop on the shared segment. The reason for this is that there is no direct “native” update exchange between the hops running different routing protocols. In situations like this, it is beneficial to rewrite the next-hop IP address to point toward the “optimum” exit point, using the “pivotal” router’s knowledge of both routing protocols.

OSPF is somewhat special with respect to the 3rd party next-hop implementation. It supports third-party next-hop in Type-5/7 LSAs (External Routing Information LSA and NSSA External LSA). These LSAs are processed in “distance-vector manner” by every receiving router. By default, the LSA is assumed to advertise the external prefix “connected” to the advertising router. However, if the FA is non-zero, the address in this field is used to calculate the forwarding information, as opposed to default forwarding toward the advertising router. Forwarding Address is always present in Type-7 LSAs, for the reason illustrated on the figure below:

Since there could be multiple ABRs in NSSA area, only one is elected to perform 7-to-5 LSA translation – otherwise the routing information will loop back in the area, unless manual filtering implemented in the ABRs (which is prone to errors). Translating ABR is elected based on the highest Router-ID, and may not be on the optimum path toward the advertising ASBR. Therefore, the forwarding address should prompt the more optimum path, based on the inter-area routing information.

EIGRP

We start with the scenario where we redistribute RIP into EIGRP.

Notice that EIGRP will not insert the third-party next-hop until you apply the command no ip next-hop-self eigrp on R3’s connection to the shared segment. Look at the routing table output prior to applying the no ip next-hop-self eigrp command.

R1#show  ip route eigrp 
     140.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
D EX    140.1.2.2/32
           [170/2560002816] via 140.1.123.3, 00:00:27, FastEthernet0/0

After the command has been applied to R3’s interface:

R1#show  ip route eigrp
     140.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
D EX    140.1.2.2/32
           [170/2560002816] via 140.1.123.2, 00:00:04, FastEthernet0/0

The same behavior is observed when redistributing OSPF into EIGRP, but not when redistributing BGP. For some reason, BGP’s next-hop is not copied into EIGRP, e.g. in the example below, EIGRP will NOT insert the BGP’s next-hop into updates. Notice that you may enable or disable the third-party next-hop behavior in EIGRP using the interface-level command ip next-hop-self eigrp.

RIP

RIP passes the third-party next-hop from OSPF, BGP or EIGRP. For instance, assume EIGRP redistribution into RIP. You have to turn on the no ip split-horizon on R3’s Ethernet connection to get this to work:

R2#show ip route rip 
     140.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
R       140.1.1.1/32 [120/1] via 140.1.123.1, 00:00:17, FastEthernet0/0

Notice the following RIP debugging output, which lists the third-party next-hop:

RIP: received v2 update from 140.1.123.3 on FastEthernet0/0
     140.1.1.1/32 via 140.1.123.1 in 1 hops
     140.1.123.0/24 via 0.0.0.0 in 1 hops

Surprisingly, there is NO need to enable the command no ip split-horizon on the interface when redistributing BGP or OSPF routes into RIP. Seem like only EIGRP to RIP redistribution requires that. Keep in mind, however, that split-horizon is OFF by default on physical frame-relay interfaces. Here is a sample output of redistributing BGP into RIP using the third-party next-hop:

R3#show ip route bgp 
     140.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
B       140.1.2.2/32 [20/0] via 140.1.123.2, 00:22:13
R3#

R1#show ip route rip 
     140.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
R       140.1.2.2/32 [120/1] via 140.1.123.2, 00:00:09, FastEthernet0/0

RIP’s third-party next-hop behavior is fully automatic. You cannot disable or enable it, like you do in EIGRP.

OSPF

Similarly to RIP, OSPF has no problems picking up the third-party next-hop from BGP, EIGRP or RIP. Here is how it would look like (guess which protocol is redistributed into OSPF, based solely on the commands output):

R1#sh ip route ospf 
     140.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
O E2    140.1.2.2/32 [110/1] via 140.1.123.2, 00:34:59, FastEthernet0/0

R1#show ip ospf database external 

            OSPF Router with ID (140.1.1.1) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 131
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 140.1.2.2 (External Network Number )
  Advertising Router: 140.1.123.3
  LS Seq Number: 80000002
  Checksum: 0xF749
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 140.1.123.2
        External Route Tag: 200

If you’re still guessing, the external protocol is BGP, as could have been seen observing the automatic External Route Tag – OSPF set’s it to the last AS# found in the AS_PATH.

There are special conditions to be met by OSPF for the FA address to be used. First, the interface where the third party next-hop resides should be advertised into OSPF using the network command. Secondly, this interface should not be passive in OSPF and should not have network type point-to-point or point-to-multipoint. Violating any of these conditions will stop OSPF from using the FA in type-5 LSA created for external routes. Violating any of these conditions prevents third-party next-hop installation in the external LSAs.

OSPF is special in one other respect. Distance vector-protocols such as RIP or EIGRP modify the next-hop as soon as they pass the routing information to other devices. That is, the third party next-hop is not maintained through the RIP or EIGRP domain. Contrary to these, OSPF LSAs are flooded within their scope with the FA unmodified. This creates interesting problem: if the FA address is not reachable in the receiving router’s routing table, the external information found in type 7/5 LSA is not used. This situation is discussed in the blog post “OSPF Filtering using FA Address”.

BGP

When you redistribute any protocol into BGP, the system correctly sets the third-party next-hop in the local BGP table. Look at the diagram below, where EIGRP prefixes are being redistributed into BGP AS 300:

R3’s BGP process installs R1 Loopback0 prefix into the BGP table with the next-hop value of R1’s address, not “0.0.0.0” like it would be for locally advertised routes. You will observe the same behavior if you inject EIGRP prefixes into BGP using the network command.

R3#sh ip bgp
BGP table version is 9, local router ID is 140.1.123.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 140.1.1.1/32     140.1.123.1         156160         32768 ?

Furthermore, BGP is supposed to change the next-hop to self when advertising prefixes over eBGP peering sessions. However, when all peers share the same segment, the prefixes re-advertised over the shared segment do not have their next-hop changed. See the diagram below:

Here R1 advertises prefix 140.1.1.1/24 to R3 and R3 re-advertises it back to R2 over the same segment. Unless non-physical interfaces are used to form the BGP sessions (e.g. Loopbacks), the next-hop received from R1 is not changed when passing it down to R2. This implements the default third-party next-hop preservation over eBGP sessions. Look at the sample output for the configuration illustrated above: R1 receives R2’s prefix with unmodified next-hop.

R1#show ip bgp 
BGP table version is 3, local router ID is 140.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 140.1.1.1/32     0.0.0.0                  0         32768 i
*> 140.1.2.2/32     140.1.123.2                            0 300 200 i

There is a way to disable this default behavior in BGP. A logical assumption would be that using the command neighbor X.X.X.X next-hop-self would work, and it does indeed, in the recent IOS versions. The older IOS, such as 12.2T did not have this command working for eBGP sessions, and your option would have been using a route-map with set ip next-hop command. The route-map method may still be handy, if you want insert totally “bogus” IP next-hop from the shared segment – receiving BGP speaker will accept any IP address that is on the same segment. That is not something you would do in the production environment too often, but definitely an interesting idea for lab practicing. One good use in production is changing the BGP next-hop to an HSRP virtual IP address, to provide physical BGP speaker redundancy. Here is a sample code for setting an explicit next-hop in BGP update:

router bgp 300
 neighbor 140.1.123.1 remote-as 100
 neighbor 140.1.123.1 route-map BGP_NEXT_HOP out
!
route-map BGP_NEXT_HOP permit 10
 set ip next-hop 140.1.123.100

Summary

All popular distance-vector protocols support third-party next-hop insertion. This mechanism is useful on multi-access segments, in situations when you want pass optimum path information between routers belonging to different routing protocols. We illustrated that RIP implements this function automatically, and does not allow any tuning. On the other hand, EIGRP supports third-party next-hop passing from any protocol, other than BGP, and you may turn this function on/off on per-interface basis. Furthermore, OSPF’s special feature is propagation of the third-party next-hop within an area/autonomous system, unlike the distance-vector protocols that reset the next-hop at every hop (considering AS a being a “single-hop” for BGP). Thanks to that feature, OSPF offers interesting possibility to filter external routing information by blocking FA prefix from the routing tables. Finally, BGP gives most flexibility when it comes to the IP next-hop manipulation, allowing for changing it to any value.

Further Reading

Common Routing Problem with OSPF Forwarding Address
OSPF Prefix Filtering Using Forwarding Address
BGP Redundancy using HSRP

Are you a CCNP or CCIE student looking to challenge your perfect knowledge of Catalyst switchport commands?

Take the latest SWITCH Command Recall exam by clicking the link below. Good luck – and let us know how you scored in the comments area of this post.

Remember to read, AND TYPE, very carefully! I failed my first attempt due to just plain sloppiness.

SWITCH Command Recall Exam – L2/L3 Ports

For success designing and implementing Cisco Wireless solutions, a CCNA Wireless student needs to be familiar with the options for various wireless topologies. Two were defined by the 802.11 committees, while others were made possible thanks to excellent developments by wireless vendors like Cisco Systems.

The 802.11 Topologies

Ad Hoc Mode

While not popular, it is possible to have wireless devices communicate directly with no central device managing the communications. This is called the Ad Hoc network topology and is one of the two topologies defined by the 802.11 committees. In the Ad Hoc type topology, one device sets a group name and radio parameters, and another device uses this information to connect to the wireless network.

This type of wireless network topology is referred to as an Independent Basic Service Set (IBSS). This is easy to remember as we know the devices are working independently of an access point (AP).

Network Infrastructure Mode

When an access point is used to create the network, the official term is network infrastructure mode for the network. There is a Basic Service Set (BSS) setup that uses a single access point, or the Extended Service Set (ESS) that uses multiple access points in order to extend the reach of the wireless network.

Access points running in the network infrastructure mode are often described as a cross between hubs and bridges. The APs act like hubs in that they service a single collision domain and must operate in a half duplex fashion. Fortunately for the AP, it does possess intelligence beyond a simple hub, however, and processes frames and forwards these based on MAC address information.

Vendor-Specific Topology Extensions

Workgroup Bridge

Perhaps your network contains clients that you want to connect to the wired infrastructure but these devices are in a location where it is difficult to extend actual physical wires. This is the perfect time to have the access point function as a workgroup bridge. The access point extends the wired LAN out to these wireless devices.

Repeater

In this case, the job of the access point is to strengthen the wireless signal from another access point. Perhaps it is strengthening the signal of an access point acting in the workgroup bridge role. When repeaters are used, there must be overlap in the access point cell coverage. In order to provide optimal performance, the overlap needs to be 50%.

Outdoor Wireless Bridge

These access points are typically used within a few miles of each other and are used to connect two or more LANs. The Cisco technology allows the configuration of point-to-point or point-to-multipoint topologies.

Outdoor Mesh Networks

The outdoor mesh network features an access point acting as a root device. This AP has an Ethernet connection to a distribution network and it associates with a Wireless LAN Controller (WLC). The other access points in the design act as mesh APs. All these devices need is power and can act as repeaters as required in order to allow all devices to reach the root access point. While the IEEE is working on a mesh standard called 802.11s, the Cisco solution features Adaptive Wireless Path Protocol (AWPP). AWPP promotes the mesh devices finding the best path back to the root AP.

One of the frequent questions I hear regarding L3VPNs, is regarding the bottom VPN label.  In this article, we will focus on the control plane that provides both the VPN and transit labels, and then look at the data plane that results because of those labels.

In the topology, there are 2 customer sites (bottom right, and bottom left).  The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane.   Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.

A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.

R2 has learned the route from R1, has assigned a VPN label for it, and has exported it from the VRF into BGP.  This lucky route was assigned the local label of 16 by R2.

We can also look at the MPLS forwarding table on R2 to see the same tag information.

This prefix, as a VPNV4 route, is sent as an update to the iBGP peer R4.   We can force an update with refresh.

The update can be seen on the wire between R2 and R3, (on its way to R4) using a protocol analyzer.  You may also notice that R2 uses outgoing label 19 for forwarding this update to 4.4.4.4   The label can be seen in the MPLS forwarding output above.

The VPN label being advertised in the update is Label 16, which is R2’s local label for the 1.1.1.1 network.

On R4, which will be the ingress PE for transit traffic destined for 1.1.1.1, we can see that the VPN label of 16 is associated with destination network of 1.1.1.1  The next hop of 2.2.2.2 to reach the 1.1.1.1 network, is due to R2 assigning next-hop-self for updates it sends to R4.

We can also see the outgoing MPLS label that R4 will use to reach the next hop of 2.2.2.2.  The label of 18 below, was advertised by R3, as the label to use to reach 2.2.2.2

We can also verify that the route (1.1.1.1) has been imported by R4 into the customer vrf.

So when a transit packet is sent from R5 to 1.1.1.1, R4 should impose 2 labels.   The bottom label will be 16 (the VPN label) for the 1.1.1.1 network (R2 told us about that via the iBGP update), and the top label should be 18 (advertised via LDP from R3), to reach the next hop of 2.2.2.2

On R4 a quick check of the CEF table for the vrf can verify both labels.

A simple trace from R5, to the destination network of 1.1.1.1 should prove all the labels in the path.

The top label of 18 is used to reach the next hop of 2.2.2.2, and the bottom label of 16, which is meaningful to R2, because he sourced it, will be used by R2 in forwarding the transit traffic destined to 1.1.1.1 to the next hop, which is R1.

R3 will pop the transit label off, due to R2 advertising implicit-null for the network 2.2.2.2 (itself).

For more information and step by step training on MPLS, take a look at our newest MPLS self paced course!

If you like, an 8 minute video, that reviews the same steps, may be viewed here.

Thanks for reading!

Keith Barker

In this blog post we’re going to discuss the fundamental logic of how MPLS tunnels allow applications such as L2VPN & L3VPN to work, and how MPLS tunnels enable Service Providers to run what is known as the “BGP Free Core”. In a nutshell, MPLS tunnels allow traffic to transit over devices that have no knowledge of the traffic’s final destination, similar to how GRE tunnels and site-to-site IPsec VPN tunnels work. To accomplish this, MPLS tunnels use a combination of IGP learned information, BGP learned information, and MPLS labels.

In normal IP transit networks, each device in the topology makes a routing decision on a hop-by-hop basis by comparing the destination IP address of the packet to the routing or forwarding table. In MPLS networks, devices make their decision based on the MPLS label contained in the packet that is received. In this manner, MPLS enabled Label Switch Routers (LSRs for short) do not necessarily need IP routing information about all destinations, as long as they know how to forward traffic based on an MPLS label. To demonstrate how this process works, we’ll examine the above topology in two sample cases, first with normal IP packet forwarding, and secondly with IP packet forwarding plus MPLS.

In this topology R4, R5, and R6 represent the Service Provider network, while SW1 and SW2 represent customers that are using the Service Provider for transit. In each example case, the goal of our scenario will be to provide IP packet transport between the 10.1.7.0/24 network attached to SW1, and the 10.1.8.0/24 network attached to SW2.

Case 1: Normal IP Forwarding

In case 1, the devices in the topology are configured as follows. AS 100, which consists of R4, R5, and R6, runs OSPF as an IGP on all internal interfaces, along with a full mesh of iBGP. AS 7, which consists of SW1, and AS 8, which consists of SW2, peer EBGP with AS 100 via R4 and R6 respectively, and advertise the prefixes 10.1.7.0/24 & 10.1.8.0/24 respectively into BGP. The relevant device configurations are as follows. Note that these configs assume that layer 2 connectivity has already been established between the devices.

R4#
interface Loopback0
 ip address 10.1.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.47.4 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.1.45.4 255.255.255.0
 ip ospf 1 area 0
!
router bgp 100
 neighbor 10.1.6.6 remote-as 100
 neighbor 10.1.6.6 update-source Loopback0
 neighbor 10.1.6.6 next-hop-self
 neighbor 10.1.45.5 remote-as 100
 neighbor 10.1.45.5 next-hop-self
 neighbor 10.1.47.7 remote-as 7

R5#
interface FastEthernet0/0
 ip address 10.1.45.5 255.255.255.0
 ip ospf 1 area 0
!
interface FastEthernet0/1
 ip address 10.1.56.5 255.255.255.0
 ip ospf 1 area 0
!
router bgp 100
 neighbor 10.1.45.4 remote-as 100
 neighbor 10.1.56.6 remote-as 100

R6#
interface Loopback0
 ip address 10.1.6.6 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip ospf 1 area 0
!
interface FastEthernet0/1
 ip address 10.1.68.6 255.255.255.0
!
router bgp 100
 neighbor 10.1.4.4 remote-as 100
 neighbor 10.1.4.4 update-source Loopback0
 neighbor 10.1.4.4 next-hop-self
 neighbor 10.1.56.5 remote-as 100
 neighbor 10.1.56.5 next-hop-self
 neighbor 10.1.68.8 remote-as 8

SW1#
interface Loopback0
 ip address 10.1.7.7 255.255.255.0
!
interface Vlan47
 ip address 10.1.47.7 255.255.255.0
!
router bgp 7
 network 10.1.7.0 mask 255.255.255.0
 neighbor 10.1.47.4 remote-as 100

SW2#
interface Loopback0
 ip address 10.1.8.8 255.255.255.0
!
interface Vlan68
 ip address 10.1.68.8 255.255.255.0
!
router bgp 8
 network 10.1.8.0 mask 255.255.255.0
 neighbor 10.1.68.6 remote-as 100

Next, let’s examine the hop-by-hop packet flow as traffic moves between the 10.1.7.0/24 and 10.1.8.0/24 networks, starting at SW1 towards SW2, and then back in the reverse direction. Note that verification should be done in both directions, as packet flow from the source to destination is independent of packet flow from the destination back to the source.

SW1#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 7", distance 20, metric 0
  Tag 100, type external
  Last update from 10.1.47.4 00:21:13 ago
  Routing Descriptor Blocks:
  * 10.1.47.4, from 10.1.47.4, 00:21:13 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 100

On SW1, the prefix 10.1.8.0 is learned via BGP from R4, with a next-hop of 10.1.47.4. Next, SW1 performs a second recursive lookup on the next-hop to see which interface must be used for packet forwarding.

SW1#show ip route 10.1.47.4
Routing entry for 10.1.47.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Vlan47
      Route metric is 0, traffic share count is 1

The result of this lookup is that SW1 should use interface Vlan47, which connects towards R4. Assuming that underlying IP address to MAC address resolution is successful, packets going to 10.1.8.0 should be properly routed towards R4. Next, the lookup process continues on R4.

R4#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 100", distance 200, metric 0
  Tag 8, type internal
  Last update from 10.1.6.6 00:25:19 ago
  Routing Descriptor Blocks:
  * 10.1.6.6, from 10.1.6.6, 00:25:19 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 8

R4 is learning the prefix 10.1.8.0 via iBGP from R6, with a next-hop value of 10.1.6.6, R6’s Loopback0 interface. R4 must now perform an additional recursive lookup to figure out what interface 10.1.6.6 is reachable out.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.1.45.5 on FastEthernet0/1, 00:25:26 ago
  Routing Descriptor Blocks:
  * 10.1.45.5, from 10.1.6.6, 00:25:26 ago, via FastEthernet0/1
      Route metric is 3, traffic share count is 1

R4 knows 10.1.6.6 via OSPF from R5, which uses interface FastEthernet0/1. Assuming layer 2 connectivity is working properly, packets towards 10.1.8.0 are now routed to R5, and the lookup process continues.

R5#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 100", distance 200, metric 0
  Tag 8, type internal
  Last update from 10.1.56.6 00:24:36 ago
  Routing Descriptor Blocks:
  * 10.1.56.6, from 10.1.56.6, 00:24:36 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 8

R5 is learning the prefix 10.1.8.0 via iBGP from R6, with a next-hop of 10.1.56.6. A recursive lookup on the next-hop, as seen below, indicates that R5 should use interface FastEthernet0/1 to forward packets towards 10.1.8.0.

R5#show ip route 10.1.56.6
Routing entry for 10.1.56.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/1
      Route metric is 0, traffic share count is 1

The lookup process now continues on R6, as seen below.

R6#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "bgp 100", distance 20, metric 0
  Tag 8, type external
  Last update from 10.1.68.8 00:28:58 ago
  Routing Descriptor Blocks:
  * 10.1.68.8, from 10.1.68.8, 00:28:58 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 8

R6 is learning the prefix 10.1.8.0 via EBGP from SW2, with a next-hop of 10.1.68.8.

R6#show ip route 10.1.68.8
Routing entry for 10.1.68.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/1
      Route metric is 0, traffic share count is 1

A recursive lookup on 10.1.68.8 from R6 dictates that interface FastEthernet0/1 should be used to forward traffic on to SW2.

SW2#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Advertised by bgp 8
  Routing Descriptor Blocks:
  * directly connected, via Loopback0
      Route metric is 0, traffic share count is 1

SW2’s lookup for 10.1.8.0 indicates that the destination is directly connected, and packets are routed to the final destination. For return traffic back to 10.1.7.0, a lookup occurs in the reverse direction similar to what we saw above, starting as SW2, and moving to R6, R5, R4, and then finally SW1.

This example shows how the hop-by-hop routing paradigm works in IPv4 networks. While this type of design works, one of the limitations of IPv4 forwarding is that all devices in the transit path must have routing information for all destinations they are forwarding packets towards. If AS 100 was used for Internet transit in this example, each router in the transit path would need 300,000+ routes in their routing tables in order to provide transit to all Internet destinations. This is just one of the many applications for which MPLS can be helpful. By introducing MPLS into this design, the need for large routing tables can be avoided in the core of the Service Provider network.

Case 2: MPLS Forwarding

By enabling MPLS in the Service Provider network of AS 100, BGP can be disabled in the core, lightening the load on devices that are possibly already taxed for resources. The configuration for MPLS in this scenario is very simple, but the understanding of what happens behind the scenes can be intimidating when learning the technology for the first time. To help with this learning curve, we’ll look at the step by step process that occurs when an MPLS tunnel is functional in AS 100.

The configuration changes necessary to implement MPLS in AS 100 are as follows:

R4#
mpls label protocol ldp
!
interface FastEthernet0/1
 mpls ip
!
router bgp 100
 no neighbor 10.1.45.5 remote-as 100

R5#
mpls label protocol ldp
!
interface FastEthernet0/0
 mpls ip
!
interface FastEthernet0/1
 mpls ip
!
no router bgp 100

R6#
mpls label protocol ldp
!
interface FastEthernet0/0
 mpls ip
!
router bgp 100
 no neighbor 10.1.56.5 remote-as 100

Once MPLS is enabled inside AS 100, BGP can be disabled on R5, and the additional BGP peering statements removed on R4 and R6. The end result of this change is surprising for some, as seen below.

R5#show ip route 10.1.7.0
% Subnet not in table
R5#show ip route 10.1.8.0
% Subnet not in table

SW1#ping 10.1.8.8 source 10.1.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Although R5 no longer has a route to the prefixes 10.1.7.0/24 or 10.1.8.0/24, it can still provide transit for traffic between them. How is this possible you may ask? The key is that an MPLS tunnel has now been formed between the ingress and egress routers of the Service Provider network, which are R4 and R6 in this case.  To see the operation of the MPLS tunnel, we’ll follow the same lookup process as before, but now R4, R5, and R6 will add an additional MPLS label lookup.

Below SW1 looks up the route for 10.1.8.0/24, and finds that it recurses to R4’s next-hop value reachable via the Vlan47 interface.

SW1#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
 Known via "bgp 7", distance 20, metric 0
 Tag 100, type external
 Last update from 10.1.47.4 01:02:56 ago
 Routing Descriptor Blocks:
 * 10.1.47.4, from 10.1.47.4, 01:02:56 ago
 Route metric is 0, traffic share count is 1
 AS Hops 2
 Route tag 100

SW1#show ip route 10.1.47.4
Routing entry for 10.1.47.0/24
 Known via "connected", distance 0, metric 0 (connected, via interface)
 Routing Descriptor Blocks:
 * directly connected, via Vlan47
 Route metric is 0, traffic share count is 1

Next, R4 receives packets for this destination and performs its own lookup.

R4#show ip route 10.1.8.0
Routing entry for 10.1.8.0/24
 Known via "bgp 100", distance 200, metric 0
 Tag 8, type internal
 Last update from 10.1.6.6 01:05:15 ago
 Routing Descriptor Blocks:
 * 10.1.6.6, from 10.1.6.6, 01:05:15 ago
 Route metric is 0, traffic share count is 1
 AS Hops 1
 Route tag 8

Like before, R4 finds the route via BGP from R6, with a next-hop of 10.1.6.6.  R4 must now perform a recursive lookup on 10.1.6.6 to find the outgoing interface to reach R6.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
 Known via "ospf 1", distance 110, metric 3, type intra area
 Last update from 10.1.45.5 on FastEthernet0/1, 01:06:22 ago
 Routing Descriptor Blocks:
 * 10.1.45.5, from 10.1.6.6, 01:06:22 ago, via FastEthernet0/1
 Route metric is 3, traffic share count is 1

R4’s recursive lookup finds the outgoing interface FastEthernet0/1 with a next-hop of 10.1.45.5.  In normal IP forwarding, the packet would now be sent to the interface driver for layer 2 encapsulation.  However in this case, R4 first checks to see if the interface FastEthernet0/1 is MPLS enabled, as seen below.

R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/1        Yes (ldp)     No       No  No     Yes

Since interface FastEthernet0/1 is running MPLS via Label Distribution Protocol (LDP), R4 now consults the MPLS Label Forwarding Information Base (LFIB) to see if there is an MPLS label assigned to the next-hop we’re trying to reach, 10.1.6.6.

R4#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.56.0/24      0             Fa0/1      10.1.45.5
17     17            10.1.6.6/32       0             Fa0/1      10.1.45.5
18     18            10.1.68.0/24      0             Fa0/1      10.1.45.5

R4 finds an entry for 10.1.6.6/32 in the LFIB, and uses the outgoing label value of 17.  This means that for traffic going to 10.1.8.0/24, the label 17 will be added to the packet header.  In reality this lookup process occurs as one step, which is the lookup in the CEF table.  The below output of the CEF table for the final destination on R4 shows that label 17 will be used, because it is inherited from the next-hop of 10.1.6.6.

R4#show ip cef 10.1.8.0 detail
10.1.8.0/24, epoch 0
 recursive via 10.1.6.6
 nexthop 10.1.45.5 FastEthernet0/1 label 17

Now that the MPLS label lookup is successful, the packet is label switched to R5, which leads us to the key step in this example.  When R5 receives the packet, it sees that it has an MPLS label in the header.  This means that R5 performs a lookup in the MPLS LFIB first, and not in the regular IP routing table.  Specifically R5 sees the label number 17 coming in, which has a match in the LFIB as seen below.

R5#show mpls forwarding-table

Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop

Label  Label or VC   or Tunnel Id      Switched      interface

16     Pop Label     10.1.4.4/32       15447         Fa0/0      10.1.45.4

17     Pop Label     10.1.6.6/32       15393         Fa0/1      10.1.56.6

18     Pop Label     10.1.68.0/24      0             Fa0/1      10.1.56.6

The local label 17 is associated with the destination 10.1.6.6/32.  Although our packets are going to the final destination 10.1.8.0/24, knowing how to get towards the next-hop 10.1.6.6/32 is sufficient for R5, because we know that R6 actually does have the route for the final destination.  Specifically R5’s operation at this point is to remove the label 17 from the packet, and continue to forward the packet towards R6 without an additional label.  This operation is known as the “pop” operation, or label disposition.  This occurs because R5 sees the outgoing label as “no label”, which causes it to remove any MPLS labels from the packet, and continue forwarding it.

On the return trip for packets from 10.1.8.0/24 back to 10.1.7.0/24, R6 adds the label 16 and forwards the packet to R5, then R5 removes the label 16 and forwards the packet to R4.  This can be inferred from the LFIB and CEF table verifications below.

R6#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     16            10.1.4.4/32       0             Fa0/0      10.1.56.5
17     Pop Label     10.1.45.0/24      0             Fa0/0      10.1.56.5   

R6#show ip cef 10.1.7.0 detail
10.1.7.0/24, epoch 0
  recursive via 10.1.4.4
    nexthop 10.1.56.5 FastEthernet0/0 label 16

R5#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     No Label      10.1.4.4/32       17606         Fa0/0      10.1.45.4
17     No Label      10.1.6.6/32       17552         Fa0/1      10.1.56.6
18     Pop Label     10.1.68.0/24      0             Fa0/1      10.1.56.6

To see this operation in action, we can send traffic from 10.1.7.0/24 to 10.1.8.0/24, and look at the debug mpls packet output on R5.

R5#debug mpls packet
Packet debugging is on

SW1#ping 10.1.8.8 source 10.1.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

R5#
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data
MPLS les: Fa0/0: rx: Len 118 Stack {17 0 254} - ipv4 data
MPLS les: Fa0/1: rx: Len 118 Stack {16 0 254} - ipv4 data

The beauty of this MPLS design is that for any new routes AS 7 or AS 8 advertise into the network, AS 100 does not need to allocate new MPLS labels in the core.  As long as MPLS transport is established between the BGP peering address of the Provider Edge routers (R4 and R6 in this case), traffic for any destinations can transit over the Service Provider’s network without the core needing any further forwarding information.

R4#show ip route 10.1.6.6
Routing entry for 10.1.6.6/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.1.45.5 on FastEthernet0/1, 01:06:22 ago
Routing Descriptor Blocks:
* 10.1.45.5, from 10.1.6.6, 01:06:22 ago, via FastEthernet0/1
Route metric is 3, traffic share count is 1

R4#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/1        Yes (ldp)     No       No  No     Yes
R4#show mpls forw
R4#show mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     10.1.56.0/24      0             Fa0/1      10.1.45.5
17     17            10.1.6.6/32       0             Fa0/1      10.1.45.5
18     18            10.1.68.0/24      0             Fa0/1      10.1.45.5
R4#show ip cef 10.1.8.0 detail
10.1.8.0/24, epoch 0
recursive via 10.1.6.6
nexthop 10.1.45.5 FastEthernet0/1 label 17

We recently created a new self-paced MPLS course, which walks the learner step by step from concept to implementation for MPLS and L3 VPNs.  Click here for more information.

We wanted to provide our students with advance notification of some upcoming online classes here at INE. While we hope to see many students in the actual live events, on-demand versions will indeed be made available the week following the live, online version.

Join the INE Experts Online in September and October

September 13 – 17th, 2010     CCNA Wireless 5-Day Bootcamp

September 15 – 17th, 2010     Security for CCIE R&S Candidates 3-Day Bootcamp

September 29 – Oct 1, 2010    IPv4/IPv6 Multicast 3-Day Bootcamp

October 4 – 9th, 2010              Online 6-Day CCIE R&S Bootcamp with K. Barker and A. Sequeira

Our BGP class is coming up!  This class is for learners who are pursuing the CCIP track, or simply want to really master BGP.  I have been working through the slides, examples  and demos that we’ll use in class, and it is going to be excellent.  If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event.    More information, can be found by clicking here.

One of the common questions that comes up is “Why does the router choose THAT route?

We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.

So now for the question.   Take a look at the partial output of the show command below:

Regarding the 2.2.2.0/24 network, why did this router select the 192.168.68.8 next hop route, over the one just below it?

Post your ideas, and we will have a drawing next week, before the BGP class begins.   We’ll give 1 lucky winner some rack tokens for our preferred rack vendor, Graded Labs.   Everyone who comments, will be entered into the drawing.  I will update the post with the lucky winner.

Thanks for your ideas, and happy learning,

Keith Barker

Thank you to all who responded.  eBGP is preferred over iBGP, and that is what it came down to.

The winner of the graded labs tokens is Jon!  Congratulations.

For each new CCIE Testimonial we are extending the seven years of success sale! Share your INE success story and congratulations to the following new CCIE Testimonials who have extended the sale thus far!

Thomas Fischer, CCIE #26636 – Routing & Switching

I am proud to let you know, that I passed my CCIE R&S Lab in Brussels on Aug. 5th. This was my second attempt. I want to express my deepest appreciation for your Products. I am a self-paced student, using Vol1 (*****), Vol2 (****) and Vol4 (***). Thanks INE, it feels so good to have a social life again )

Matthew Ayre, CCIE #26654 – Service Provider

Big shout out for INE and their OEQ / lab preparation resources! I just cleared service provider on second attempt finishing about an hour and a half early. Was ~7% of passing the first time using INE 1 & 2 as my primary material then just drilled down on the finer details reading theory. The workbooks really developed the speed and confidence required to beat the exam!

Prateek Madaan, CCIE #26772 – Security

Had been a long and tough journey. Would really like to thank INE from the Core of my heart for facilitating in imparting the skills required not to just pass the exam but to DESERVE it as well…

There are many workbooks available which I prepared along with INE , do not want to name or list any one of them…or make any comparisons…But in comparisons INEs Security Workbooks may sound tough as compared to others BUT once you go through these workbooks is when you actually feel DESERVED the tag rather than just passing it.. Each of these workbooks and the tasks test each and every technology in detail and till the dead end….

In my last attempt on Version 2 I was deprived of the number by 1%, still followed and trusted INE workbooks and finally it helped….Today I am more happy not to procure the number but to actually have the feeling of confidence that ‘YES this time I deserve to be a CCIE’ and all due to the exhaustive INE workbooks….

Update!
Olusegun Olurotimi Medeyinlo, CCIE #26683 – Routing & Switching

I the Passed the CCIE R&S lab in Brussels on my Second attempt. I’d like to thank the instructors at INE for their excellent workbooks and blogs. Special thanks to Keith Barker for his encouragement and advice.


Now, I have my own CCIE number #22683.

Congratulations to everyone who passed the CCIE Lab Exam. Our instructors, authors, and staff have been committed to helping you pass your exam for the past seven years and we will continue to make your exam our number one priority. Only at INE.

Many businesses globally – large and small alike – have been converting calls from routing over traditional PSTN carrier trunks – such as E1 & T1 PRI or CAS – to much lower cost, yet still high performance, SIP ITSP (Internet Telephony Service Provider) trunks for years now. INE is no different than your business with regard to this – we have been using SIP trunks in lieu some traditional PSTN calling for years now as well. In fact, in response to a US Federal Communications Commission sub-commitee’s exploration on “PSTN Evolution” in December 2009, a representative from the US carrier AT&T described the traditional circuit-switched PSTN as “relics of a by-gone era”, and said that “Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete” – source: Reuters [emphasis mine].

The challenge however, becomes that every SIP ITSP carrier has a slightly different way of implementing these sorts of trunks, and each has different provider network equipment that you, the customer, must connect to, and interoperate (properly) with. If you are a large national or multinational business, you may for instance sometimes even connect to two or three different types of provider network equipment, between possibly having multiple contracts with multiple carriers, and even sometimes having to deal with different provider equipment within a single carrier’s network.

Now while you both speak the same agreed upon language (namely SIP), it seems more often than not that you don’t always seem to speak exactly the same dialect of that language. This presents a major challenge in that calls and supplementary services (such as Hold, Resume, Blind Transfer, Semi-Attended Transfer, Fully-Attended Transfer, Forwarding, Faxing, etc) don’t behave as expected, or worse, that some functions don’t work at all.

It is not that SIP isn’t fully mature yet (it will turn 15 years old next year and has been widely used for over 10 years now), or that it is fully standardized and therefore governed by those IETF standards and working groups, it is simply that – as every one of us in the field for any respectable amount of time now knows – not every equipment vendor chooses to implement every single extension and option defined in every IETF RFC for SIP. I mean, have you ever actually looked at how many RFCs there are that deal with not just the core functions, but describe every option and extension to the SIP protocol? There are well over 100 RFCs! Therein lies the problem.

So what are we to do? Cisco Unified Border Element to the rescue! Today we will cover just a few of CUBE’s ability to perform SIP Normalization to allow optimum interoperability with many various SIP ITSPs.

At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE  and the CUCMs on Dial-Peer’s 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T’s side that they have given us to peer with. We see this here:

!
ip domain retry 0
ip domain timeout 2
ip domain name ine.com
ip name-server 177.1.100.110
!
voice service voip
 address-hiding
 allow-connections sip to sip
 redirect ip2ip
 sip
  bind control source-interface Loopback0
  bind media source-interface Loopback0
  header-passing error-passthru
  midcall-signaling passthru
  g729 annexb-all
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
!
!
dial-peer voice 101 voip
 description ** TO/FROM CUCM SUBSCRIBER 1 **
 destination-pattern 2065011...$
 voice-class codec 1
 session protocol sipv2
 session target ipv4:177.1.10.20
 incoming called-number .
 dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 102 voip
 description ** TO/FROM CUCM SUBSCRIBER 2 **
 destination-pattern 2065011...$
 voice-class codec 1
 session protocol sipv2
 session target ipv4:177.1.10.25
 dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 1001 voip
 description ** TO/FROM SIP ITSP - AT&T SBC 1 **
 destination-pattern +T
 voice-class sip localhost dns:corphqr1.ine.com
 session protocol sipv2
 session target dns:sip1.att.com
 incoming called-number 2065011...$
 dtmf-relay rtp-nte
 codec g729br8
!
dial-peer voice 1002 voip
 description ** TO/FROM SIP ITSP - AT&T SBC 2 **
 destination-pattern +T
 voice-class sip localhost dns:corphqr1.ine.com
 session protocol sipv2
 session target dns:sip2.att.com
 incoming called-number 2065011...$
 dtmf-relay rtp-nte
 codec g729br8
!
dial-peer hunt 1
!

Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com   vs.   2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let’s look at what the SIP INVITE might look like prior to any modification to the above configuration:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@177.1.254.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

!
voice class sip-profiles 1
 request INVITE sip-header Contact modify "<sip:(.*)@(.*):5060>" "<sip:\1@ine.com:5060>"
!
dial-peer voice 1001 voip
 voice-class sip profiles 1
!
dial-peer voice 1002 voip
 voice-class sip profiles 1
!

Now let’s take a look at what that did to the contents of our Contact header in a new call, and thus a new SIP INVITE message that we send out to AT&T:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@ine.com:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Excellent! It did exactly what we asked it to!

There are many other things that the Cisco’s UBE can do for us, and we have only covered one small one here in this article. For a lot more great information on this product check out INE’s Class-on-Demand CCIE Voice Deep Dive for CUBE. By the way, Cisco’s implementation of what others in the industry might label a “SBC” (Session Border Controller), goes far beyond what other industry SBCs are able to offer in terms of both features and scalability (CUBE hardware support ranges from ISRs for SMBs, up through ISR-G2s and ASRs for Enterprises, up to the 12000 series routers for SPs). I will cover many more of the offered features of the CUBE in follow-up postings, so stay tuned!

I will leave you with a great Cisco article describing some basic functionality of CUBE and SIP Normalization, and also a lot of great Cisco configuration examples from live SIP ITSP trunks that Cisco has installed and tested with in their RTP labs, as well as live PBX integrations that they have performed, and subsequently written up these “recommended practice” documents.

As you may have noticed, INE does a wide variety of training in the Cisco space.      This blog post goes out to all those folks who have recently begun their Cisco training.

This month we delivered new live classes on CCNA and CCNP. We are excited for and encourage our students at every level in their journey.   In that light, we have gathered a collection of Videos Answers, targeted at the CCNA level, with a few topics leaking into security and CCNP.   These videos were primarily created as quick (under 10 minutes each) Video Answers to questions that various learners have had.

Take a look at the list of topics, and if there are 1 or 2 you feel you would benefit from, feel free to enjoy them.

Here are a few of the topics (in no particular order):

• How the network statement really works in IOS
• Setting up SSH
• Initial commands for sanity sake
• NAT with overload
• Router on a stick
• VRFs
• SDM Security Audit
• Adding your own PC to interact with GNS3 routers
• IPv6 basic implementation
• Converting Multicast address to MAC address for that group
• Frame relay mappings
• VLSM implementation
• SVIs
• HUBs Swtiches and Routers comparison
• Configure IOS to be a Frame Switch
• EIGRP offset lists
• Multicast GET VPN
• Context Based Access Control
• Zone Based Firewalls
• Dot1q Trunking
• ARP cache tutorial

and more…

You can view them using this link here on YouTube

You may also use this link:  http://www.youtube.com/user/Keith6783

If you want to look further into learning, we offer a full suite of self-paced workbooks, videos, and interactive learning tools.

Best wishes, and happy studies-

Keith