Shows how much memory is being consumed by each routing process.
To see information on OSPF Area Border Routers and Autonomous System Border Routers
#show ip ospf border-routers
OSPF Router with ID (10.0.0.2) (Process ID 100)
Base Topology (MTID 0)
Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route
i 10.0.0.3 [10] via 10.0.23.2, Ethernet0/1, ABR/ASBR, Area 0, SPF 9 i 10.0.0.1 [10] via 10.0.12.1, Ethernet0/0, ASBR, Area 1, SPF 5 I 10.0.0.4 [20] via 10.0.23.2, Ethernet0/1, ASBR, Area 0, SPF 92
Basically shows how your router is intended to reach each of the ABRs and ASBRs it knows about.
To see which routing information is originated by your OSPF-enabled router
#show ip ospf database self-originate
OSPF Router with ID (10.0.0.2) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count 10.0.0.2 10.0.0.2 156 0x80000006 0x005D69 1
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum 10.0.12.0 10.0.0.2 111 0x80000001 0x006EA5
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum 10.0.0.1 10.0.0.2 111 0x80000001 0x00EC2E
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count 10.0.0.2 10.0.0.2 156 0x80000003 0x00746B 1
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum 10.0.23.0 10.0.0.2 111 0x80000001 0x00F414 10.0.34.0 10.0.0.2 111 0x80000001 0x00DF14
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum 10.0.0.3 10.0.0.2 111 0x80000001 0x00D840 10.0.0.4 10.0.0.2 111 0x80000001 0x0033DA
The output above is taken from Router that is ABR, so you can see Summary (Type 3) LSAs that this router generates and sends to Area 1 to tell about the routes belonging to Area 0 and vice versa. Also you can see Summary ASB LSAs that it sends to inform routers in Area 0 about an ASBR it sees in Area 1 and routers in Area 1 about ASBRs in Area 1.
I have found for myself long ago that reading several articles and documents explaining the same thing, often using different approaches, helps me quite a lot to understand it. Trying to brush up my knowledge in Layer 3 MPLS VPN and doing some experiments in the lab environment I have decided to write a series of short posts on how it works with my way of explaining it. Hope it will help someone who also likes to read various materials on the same topic.
The solution, as many already know, consists of the following basic components:
VRF
Multiprotocol BGP
MPLS (label propagation and switching)
Some Interior Gateway Routing Protocol
And it all looks something like this (an example shows LDP as label propagation mechanism though it is not the only one possible):
The idea is to be able to pass Layer 3 private networks across some transport (MPLS-enabled) network leaving routing processes within these private networks independent of each other and of the ones that take place in the backbone network (unless you actually want to interchange some routing information).
The most difficult part is usually not to understand how each of the components works by itself, but go get the whole picture. I started by asking: “Why do we need all of these components to make the solution work?” Starting with the first one the question will be:
Why do we need VRF?
Remember the goal of L3 MPLS VPN – several independent Layer-3 networks should be able to send data over one transport network. This means we are going to have traffic of two or more private networks on the same router and we need to have separate routing instances for each of these networks. This is what VRF does.
How does it work?
VRF is often called Router Virtualization and is compared to Server/Desktop Virtualization. This analogy doesn’t seem very accurate to me. When you virtualize a server with let’s say VMWare ESXi you normally get all of it’s main components – CPU, RAM, disks, network cards, virtualized and managed separately from the same components of other virtual servers. In case of VRF what gets virtualized is just routing instance. You don’t manage how many hardware resources each virtual routing instance will get, router RAM and CPU resources remain shared.
What makes each VRF is its Layer-3 interface members and its proper routing table. To me an analogy with VLANs each having its Layer-2 port members and proper MAC-address table seems more correct.
A good example of network virtualization technology that gets really close to the server/desktop virtualization would be VDC in Cisco NX-OS, not VRF.
VRF instances are local to the router
This is an important thing to keep in mind. Two switches receiving Ethernet frames from each other across dot1q trunk understand which traffic belongs to which VLAN by looking at dot1q tag. There is nothing similar happening with VRF instances. Each VRF instance is local to the router where it is configured. There is no data in the packet that could indicate which VRF it comes from.
Configuration
VRF configuration is basically resumed to
Creating VRF instances
ip vrf Network-A rd 64600:100 ! ip vrf Network-B rd 64600:100
The meaning of the Route Distinguisher parameter configured with rd command will be explained in later post.
Assigning Layer-3 interfaces
interface FastEthernet1/0
ip vrf forwarding Network-A
ip address 192.168.1.1 255.255.255.0 ! interface FastEthernet2/0
ip vrf forwarding Network-B
ip address 172.16.1.1 255.255.255.0
Configuring routing
ip route vrf Network-A 192.168.2.0 255.255.255.0 192.168.1.254
ip route vrf Network-B 172.16.2.0 255.255.255.0 172.16.1.254
I have added just static routes, though it is also possible to use dynamic routing protocols capable to work with VRF.
As a result we have separate routing tables for each VRF instance:
R1#show ip route vrf Network-A
Routing Table: Network-A Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override
Gateway of last resort is not set
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/24 is directly connected, FastEthernet1/0 L 192.168.1.1/32 is directly connected, FastEthernet1/0 S 192.168.2.0/24 [1/0] via 192.168.1.254
R1#show ip route vrf Network-B
Routing Table: Network-B Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks C 172.16.1.0/24 is directly connected, FastEthernet2/0 L 172.16.1.1/32 is directly connected, FastEthernet2/0 S 172.16.2.0/24 [1/0] via 172.16.1.254
The routes that don’t belong to any of the VRF instances created, stay in Global routing instance. Here I have FastEthernet0/0 interface that is not assigned to any VRF:
R1#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop overrideGateway of last resort is 10.0.0.254 to network 0.0.0.010.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.0.0.0/24 is directly connected, FastEthernet0/0 L 10.0.0.1/32 is directly connected, FastEthernet0/0
VRF as part of MPLS L3VPN
In MPLS L3VPN solution VRF is used on the transport network border routers (often called PE routers). Let’s say we have Network A and Network B across backbone network. Each of them will have its own VRF on every PE router that has Network A, B devices (CE-routers) connected.
Bidirectional Forwarding Detection Protocol is a relatively new tool that allows to significantly lower dynamic routing protocol convergence times. Previously faster convergence in the LAN was often achieved by tuning protocol hello/keepalive timers. A good example is Fast Hello setting for OSPF. Lowering routing protocol timers, however, can lead to higher CPU resource utilization and somewhat unexpected behavior of the network. For example in a network where you have OSPF, BGP and LDP working simultaneously with two latter depending on the former, and you try to improve convergence times by tweaking the timers for all three protocols it is difficult to predict how the whole thing reacts on some link flapping in terms of both convergence time and hardware resource utilization during convergence period. Again, I am talking here about the complicated situations, such as when you lose communications over the link without interfaces going down, maybe just in one direction. Situations when the Layer 1 and Layer 2 go down normally trigger some protocol events and convergence occurs quite quickly.
BFD offers lightweight mechanism for detecting link communications failures and notifying routing protocol making them react quickly. Convergence times with BFD are lower than for routing protocols configuring with shorter timers (se my example for OSPF below). Of course, as detection times get shorter the sensitivity to link flapping grows which may be undesirable. Also BFD has dampening mechanism that allows to introduce exponential delay in communication failure detection mechanism.
For now BFD can work with the following protocols:
Static Routing
BGP
EIGRP
ISIS
OSPF
HSRP
LDP
ATM Pseudowires
OSPF Example
Here is a simple topology I used to test BFD operations:
One important thing to understand with BFD is that it works only in conjunction with the protocol it is supposed to notify of failures. If you just configure it on two adjacent interfaces like this:
It won’t do anything. No neighborship is going to be established a this stage, no packets will be sent. What you need is enable it for the routing protocol, in our case OSPF:
R1
R2
router ospf 100 bfd all-interfaces
router ospf 100 bfd all-interfaces
And here it is:
R1#show bfd neighbors
IPv4 Sessions NeighAddr LD/RD RH/RS State Int 10.0.0.2 1/1 Up Up Et0/0
BFD neighborship is established:
Now, breaking the communication between OSPF neighbors (with debug bfd events enabled):
BFD reports communication failure in 267 ms and signals OSPF to shut down the neighborship which OSPF immediately does. This gives us convergence time a lot shorter than OSPF Fast Hello.
In real life you should, of course, check that you have enough hardware resources to run BFD with these parameters as well as understand whether you need such short convergence time (because of the possibility of false-positives).
What’s inside
Looking at how BFD packet capture you may expect to see some sort of keepalive exchange between neighbor IP addresses which in our case are 10.0.0.1 and 10.0.0.2. Here is what you actually see:
Both R1 and R2 are sending UDP messages to their own interface IP addresses. This is another important thing about BFD: it works on Layer 2. Here are these packets details:
R1 sends BFD control message to R2 MAC, R2 swaps source and destination MAC and sends it back out the interface it was received. R1 gets his own message back and sees that communication across the link is working. The same process happens in the opposite direction. So R2 doesn’t process BFD data coming from R1 and vice versa. Apart from this routers interchange control messages with link state information. These messages are sent on Layer 3:
Here is what the link communication failure detection process looks like:
A common NTP implementation in the enterprise network implies one or two border routers synchronizing with external NTP servers and peering between them. Other NTP-enabled devices and applications get time from these routers internal or loopback interface addresses which belong to private address space. I usually configure external NTP servers from the regional ntp.org pool:
ntp server 0.south-america.pool.ntp.org ntp server 2.south-america.pool.ntp.org ntp server 1.south-america.pool.ntp.org ntp server 3.south-america.pool.ntp.org
Border router resolves the names and tries to syncronize to one of them. The experience has shown that these NTP servers are quite unstable (at least in the region where I currenty work). Both border routers can easily be left without a single server to synchronize, so the whole network stays without reliable time source. In order to be able to detect such situations I wrote a simple EEM Applet:
event manager applet ntp-sync-check
event tag 1 snmp oid 1.3.6.1.2.1.197.1.2.1 get-type next entry-op ne entry-val "6" entry-type value poll-interval 86400
event tag 5 none
trigger
correlate event 1 or event 5
action 0.10 info type routername
action 1.00 cli command "enable"
action 1.10 cli command "show ntp asso"
action 1.20 set ntpa "$_cli_result"
action 2.00 cli command "show ntp status"
action 2.20 set ntpst "$_cli_result"
action 3.00 syslog priority critical msg "NTP sync failed" facility "NTP"
action 3.10 mail server "exchange.ourdomain.com" to "alarmsandnotifications@ourdomain.com" from "$_info_routername@ourdomain.com" cc "sysadmin@ourdomain.com" subject "** NTP Sync Failure **" body "$ntpst
What it does is just polling SNMP OID that returns the router NTP synchronization status and if the synchronization is found to be failed sends a syslog message and e-mail notification containing show ntp associations and show ntp status commands outputs.
The only value that satisfies us is 6 – NTP Synchronized to Remote Server. So if the OID value is not equal to 6 the applet gets launched (event 1 gets triggered).
A recommended practice for all EEM scripts is have event none added besides the main event and to configure the applet to run on any of the two events occurrence. In the example above it is added with tag 5. This allows you to test the applet by launching it manually without waiting for o provoking the main event (NTP synchronization loss in my case). An applet can be tested by executing the following command:
In my previous post on diagram drawing I shared my idea on how to draw VLANs on Visio network diagrams. Here I want to go level up with network virtualization entities and show how I draw VRF instances.
A VRF consist of Layer-3 interface members. So to me it sounds logical to bind VRF symbols to Layer-3 interface symbols. This is how I do it:
Two interfaces in “Internal” VRF
Different VRF instances can be depicted with diferent colors to make them easily distinguishable on a drawing.
For many years I’ve been struggling to memorize OSPF LSA types. Finally, I have decided to create a lab that shows all those LSA types that are supported by Cisco in OSPFv2 (IPv4-OSPF).
Here is my lab topology:
Lab Topology
Type 1 – Router LSA
According to the documentation LSA type 1 is sent by any router within the area and contains the information about its directly connected links.
To see it I start packet capture in R1 Fa0/0 interface and reset the OSPF process at R2 to provoke LSA flood. Theoretically I should see two Type 1 LSA coming from R2: one for link 10.0.2.0/30 and another one for 10.0.1.0/24.
Here is what actually appears:
Two LSAs. One with unicast destination and one destined to “ALL OSPF ROUTERS” multicast address. Both contain the same information:
The information on both links is passed inside one Type 1 LSA. Links are presented with their IDs. There is a proper alogithm to derive Link ID depending on link type, in case of Transit that appears in this LSA network it’s DR IP address. The reason why R2 sends two LSA probably has to do with Cisco implementation of OSPF and the fact that R2 has broadcast multicaccess segment connected to it’s Fa0/1 interface.
This is how Type 1 LSA has been sent:
LSA Type 1
Type 2 – Network LSA
Type 2 LSA is generated by DR elected for multiaccess segment to inform its neighbors about this segment existence. An example of such a segment is the interconnecion between R2 R3 and R4. From R2 we can see that R4 got elected as DR (it’s router ID is 172.16.2.1):
R2#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 172.16.1.1 1 FULL/BDR 00:00:37 10.0.1.1 FastEthernet0/1 172.16.2.1 1 FULL/DR 00:00:34 10.0.1.2 FastEthernet0/1
So putting capture on R2 fa0/0 and resetting its OSPF process we should get Type 2 LSA from R4 containing information on R2-R3-R4 segment. Here it is, packed together with some other LSAs:
LSA Type 2
Notice the subnet mask for the segment, DR ID (Advertising Router) and three attached router IDs.
So Type 2 LSA flow is the following:
LSA Type 2
This type of LSA then gets resent by all the routers within the area (in this example R2 will resend it to R1). Advertising router field within the LSA will retain its original value as R4 being the DR is the one responsible for the LSA.
Type 3 – Summary LSA
Type 3 LSAs are sent by ABR. When a link-state change occurs within one of the areas connected to it, it sends this type of LSA to all the other areas thus notifying them about that change. For example, when R2 Fa0/0 link goes down we can expect R3 to notify R6 about this change with Type 3 LSA.
Setting capture for Fa0/0 on R6 and shutting down Fa0/0 on R2 we get the following:
Type 3 LSA
Notice the Metric field value. Setting it to 16777215 (FFFFFF hexadecimal) is a way to mark link as unreachable and signal to other OSPF routers to withdraw its data from their databases.
R3 generates Type 3 LSA because it gets notified of the change by Type 1 LSA coming from R2. Here is the flow diagram:
LSA Type 3
Please note that the name “summary LSA” has nothing to do with route summarization feature. Nothing gets summarized here, at least by default.
Type 4 – ASBR summary LSA
Type 4 LSAs are also sent by ABR. By using them ABR notifies it’s connected areas about the presence of ASBR in any of these areas. In my topology R3(ABR) would notify R6 which is in Area 1 about the presence of R1(ASBR) in Area 0 using LSA of this type. Later on R6 will receive some external route information from R1 and the Type 5 LSA announcing this route will contain R1 Router ID, saying that this external network is behind R1. Data obtained by R6 from Type 4 LSA will tell it that R1 is behind R3.
What makes router an ASBR and thus provokes LSA Type 4 generation? It’s route redistribution from any other routing process or protocol into OSPF occurring at this router. In my topology R1 is an ASBR as it redistributes routes from RIP into OSPF.
So, again, R3, being an ABR, should notify R6 about the presence of R1 using Type 4 LSA. But how does R3 get to know that R1 is an ASBR and not just any common intra-area router? The answer is: R1 notifies everyone within Area 0 of itself being an ASBR by setting a special (E) flag in Type 1 LSAs it sends. Here it is:
Type 1 LSA with E flag set
Wireshark already interprets E flag set as “AS boundary router”.
So when R3 receives this LSA it sends Type 4 LSA to notify R6:
Type 4 LSA
Advertising router field contains R3 Router-ID, Link State ID contains R1 (ASBR) Router ID.
Here is what the process looks like:
LSA Type 4
Type 5 – External LSA
LSA Type 5 is used to advertise external routes in all the OSPF areas. External in this case means not calculated or generated by OSPF process, but redistributed from other routing protocols, redistributed static or connected routes. As an example route for 192.168.99.0/24 network should be advertised by R1 using this type of LSA.
Putting R7 Loopback0 interface into shutdown provokes LSA flooding out of R1 FastEthernet0/0 notifying it as unreachable. Here is the capture:
LSA Type 5LSA Type 5
Type 7 – NSSA External LSA
This LSA Type contains external routes information as well as Type 5 LSA. The difference is that Type 7 LSA is propagated across Not-so-Stubby area and Type 5 LSA is not. On ABR that connects NSSA to Backbone area Type 7 LSA gets converted into Type 5 LSA.
In my topology R5 should notify R4 about changes with interface Loopback0 (172.16.102.0/24 subnet) using this type of LSA.
Here is a Type 7 LSA sent by R5 on it’s Loopback0 shutdown:
LSA Type 7
and here is LSA 5 generated by R4 for Area0, containing information on the same link:
LSA Type 5 generated by ABR, based on the information from received LSA Type 7LSA Type 7
Previously to use hardware (PVDM-based) transcoding you needed to register DSPFarm on CUCM or CME. But what if you don’t use any of these call control platforms, just have a router working as CUBE and want to accept one call leg and set up another with a codec different from originating? Starting with CUBE 9.0 Cisco has introduced Local Transcoding Interface (LTI) feature that permits you to register transcoding DSPFarm profile on CUBE itself.
CUBE version is mapped to IOS version, some information on version correspondence can be found here. The exact CUBE version on your router can be verified with show cube status command.
The call flow I used to test the feature is the following:
Here is a configuration example:
voice-card 0 dsp services dspfarmdspfarm profile 1 transcode universal codec g729r8 codec g729br8 codec g711ulaw codec g711alaw codec g729ar8 codec g729abr8 maximum sessions 4 associate application CUBE <--- this command makes the profile to register and interact with CUBE no shutdown <--- Don't forget this, the profile is shutdown by default
First, checking that DSPFarm profile has registered successfully:
#show dspfarm profile Dspfarm Profile ConfigurationProfile ID = 1, Service =Universal TRANSCODING, Resource ID = 1 Profile Description : Profile Service Mode : Non Secure Profile Admin State : UP Profile Operation State : ACTIVE Application : CUBE Status : ASSOCIATED Resource Provider : FLEX_DSPRM Status : UP Number of Resource Configured : 4 Number of Resources Out of Service : 0 Number of Resources Active : 0 Codec Configuration: num_of_codecs:6 Codec : g729r8, Maximum Packetization Period : 60 Codec : g729br8, Maximum Packetization Period : 60 Codec : g711ulaw, Maximum Packetization Period : 30 Codec : g711alaw, Maximum Packetization Period : 30 Codec : g729ar8, Maximum Packetization Period : 60 Codec : g729abr8, Maximum Packetization Period : 60
Then trying to establish the call.
Verification
After the remote party answered the call, we can see RTP streams for both call legs up:
#sh voip rtp connections VoIP RTP Port Usage Information: Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 2 Port range not configured, Min: 16384, Max: 32767Ports Ports Ports Media-Address Range Available Reserved In-useDefault Address-Range 8091 101 2VoIP RTP active connections : No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP 1 510647 510648 17882 10012 X.X.X.6 X.X.X.1 2 510648 510647 17884 12818 Y.Y.Y.68 Y.Y.Y.147 Found 2 active RTP connections
It doesn’t tell us though which codec both call legs are using. Show call active voice command does that:
#show call active voice brief
Telephony call-legs: 0 SIP call-legs: 2 H323 call-legs: 0 Call agent controlled call-legs: 0 SCCP call-legs: 0 Multicast call-legs: 0 Total call-legs: 2 2CD9 : 510647 307788128ms.1 () +16290 pid:520 Answer 3309 active dur 00:00:36 tx:1831/292960 rx:1826/292160 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP X.X.X.1:10012 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off Transcoded: Yes media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a
2CD9 : 510648 307788138ms.1 () +16270 pid:521 Originate 3000 active dur 00:00:36 tx:1825/36500 rx:1831/36620 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP Y.Y.Y.147:12818 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g729r8 TextRelay: off Transcoded: Yes media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a
Here are the active sessions on configured DSPFarm:
#show dspfarm all Dspfarm Profile ConfigurationProfile ID = 1, Service =Universal TRANSCODING, Resource ID = 1 Profile Description : Profile Service Mode : Non Secure Profile Admin State : UP Profile Operation State : ACTIVE Application : CUBE Status : ASSOCIATED Resource Provider : FLEX_DSPRM Status : UP Number of Resource Configured : 4 Number of Resources Out of Service : 0 Number of Resources Active : 1 Codec Configuration: num_of_codecs:6 Codec : g729r8, Maximum Packetization Period : 60 Codec : g729br8, Maximum Packetization Period : 60 Codec : g711ulaw, Maximum Packetization Period : 30 Codec : g711alaw, Maximum Packetization Period : 30 Codec : g729ar8, Maximum Packetization Period : 60 Codec : g729abr8, Maximum Packetization Period : 60 SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED0 1 33.1.0 UP 1 USED xcode 1 510648 799 807 0 1 33.1.0 UP 1 USED xcode 1 510647 804 797 0 1 33.1.0 UP N/A FREE xcode 1 - - - 0 1 33.1.0 UP N/A FREE xcode 1 - - - 0 1 33.1.0 UP N/A FREE xcode 1 - - -Total number of DSPFARM DSP channel(s) 4
Codec negotiation process
All the output below is taken using debug ccsip messages. Messages not related to codec negotiation are omitted.
First, CUBE receives SIP INVITE from Local IP PBX with SDP containing G.711 A-law and µ-law:
The response means that some media capability (we know it’s a codec) is not acceptable at the remote end. RFC3261 says this type of message MAY include a description of media capabilities that weren’t accepted so this could have told us what exactly the remote end didn’t like, but unfortunately in this case it doesn’t.
Anyway, CUBE sends another INVITE message, proposing G.729 codec:
which remote PBX accepts sending an OK response with acceptable media capabilities list including G.729. This actually happens when remote user picks up the phone. Here is the message:
The call proceeds with two legs using different codecs as expected.
The whole flow looks the following way (Red bars mark messages listed above, the ones containing codecs information):
An error 488 Not acceptable here could be avoided by changing the outgoing dial-peer configuration. CUBE proposes G.711 codecs first because of the voice-class applied to its outgoing dial-peer. This voice-class lists the codecs with the following preference order:
Continuing L2 across L3 topic started with post about L2TP.
Another easy-to-setup way to interconnect two Ethernet segments across Layer 3 network is EoMPLS, a particular case of AToM.
The diagram I used for my tests and the initial configuration are the same as in my previous post on L2TP.
Lab Diagram
R2
R3
interface FastEthernet0/0 description -= WAN =- ip address 115.0.0.2 255.255.255.252 ip route 0.0.0.0 0.0.0.0 115.0.0.1
interface FastEthernet0/0 description -= WAN =- ip address 116.0.0.2 255.255.255.252 ip route 0.0.0.0 0.0.0.0 116.0.0.1
To set up EoMPLS you need to have MPLS-enabled transport network in between the border routers. But if you don’t have this option, such as in case of interconnecting LAN segments across the internet you can just use GRE to make border routers look directly connected to each other across the tunnel. All the configurations are made for common Cisco IOS (not XE or XR).
Setting up GRE
GRE Tunnel uses outside physical interfaces IP addresses as source and destination:
R3#sh ip int brief | inc Tunnel0 Tunnel0 1.1.1.2 YES manual up up
And we have R2 and R3 “directly connected”.
Setting up LDP
First, I have set up Loopback interfaces on both border routers:
R2
interface Loopback0 ip address 2.2.2.2 255.255.255.255
R3
interface Loopback0 ip address 3.3.3.3 255.255.255.255
To have connectivity between Loopback interfaces I have set up OSPF (one might use static routing as well):
R2
interface Tunnel0 ip ospf 100 area 0 interface Loopback0 ip ospf 100 area 0
R3
interface Tunnel0 ip ospf 100 area 0 interface Loopback0 ip ospf 100 area 0
So now both Loopback interfaces see each other:
R2#sh ip route ospf
Gateway of last resort is 115.0.0.1 to network 0.0.0.0
3.0.0.0/32 is subnetted, 1 subnets O 3.3.3.3 [110/1001] via 1.1.1.2, 00:01:48, Tunnel0 R3#sh ip route ospf
2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1001] via 1.1.1.1, 00:01:20, Tunnel0
R3#ping 2.2.2.2 source 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 3.3.3.3 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 212/222/228 ms
Enforce the LDP router-ID on both routers:
R2
mpls ldp router-id loop0 force
R3
mpls ldp router-id loop0 force
Enable label exchange over GRE Tunnel:
R2
int tunnel0 mpls ip
R3
int tunnel0 mpls ip
Now the LDP neighborship is established:
R2#sh mpls ldp neighbor Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0 TCP connection: 3.3.3.3.64467 - 2.2.2.2.646 State: Oper; Msgs sent/rcvd: 8/8; Downstream Up time: 00:00:12 LDP discovery sources: Tunnel0, Src IP addr: 1.1.1.2 Addresses bound to peer LDP Ident: 116.0.0.2 3.3.3.3 1.1.1.2R2#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 3.3.3.3/32 0 Tu0 point2point
R3#sh mpls ldp nei Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0 TCP connection: 2.2.2.2.646 - 3.3.3.3.64467 State: Oper; Msgs sent/rcvd: 8/8; Downstream Up time: 00:00:32 LDP discovery sources: Tunnel0, Src IP addr: 1.1.1.1 Addresses bound to peer LDP Ident: 115.0.0.2 2.2.2.2 1.1.1.1R3#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 2.2.2.2/32 0 Tu0 point2point
We see some label (16) in show mpls forwarding-table command output, but it’s not the the label that will be used for tunneling traffic. There will be a few words later in this post about MPLS labels use with EoMPLS.
Now we have the following:
LDP Relationship
Setting up the EoMPLS Interconnection
Similarly to L2TPv3 we now configure the interconnection (Virtual Circuit) using xconnect.
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 120/143/224 ms
R5#ping 192.168.1.4
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/134/208 ms
And to the broadcast address:
R5#ping 255.255.255.255
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 192.168.1.4, 152 ms Reply to request 1 from 192.168.1.4, 188 ms Reply to request 2 from 192.168.1.4, 180 ms Reply to request 3 from 192.168.1.4, 172 ms
Checking that the Virtual Circuit is established:
R2#show mpls l2transport vc detail Local interface: Fa2/0 up, line protocol up, Ethernet up
Destination address: 3.3.3.3, VC ID: 2222, VC status: up
Output interface: Tu0, imposed label stack {17}
Preferred path: not configured
Default path: active
Next hop: point2point
Create time: 03:38:36, last status change time: 01:26:33
Signaling protocol: LDP, peer 3.3.3.3:0 up
Targeted Hello: 2.2.2.2(LDP Id) -> 3.3.3.3
Status TLV support (local/remote) : enabled/supported
Label/status state machine : established, LruRru
Last local dataplane status rcvd: no fault
Last local SSS circuit status rcvd: no fault
Last local SSS circuit status sent: no fault
Last local LDP TLV status sent: no fault
Last remote LDP TLV status rcvd: no fault
MPLS VC labels: local 17, remote 17
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: -= LAN =-
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 1382, send 1394
byte totals: receive 140659, send 185950
packet drops: receive 0, seq error 0, send 3
R3#show mpls l2transport vc detail
Local interface: Fa2/0 up, line protocol up, Ethernet up Destination address: 2.2.2.2, VC ID: 2222, VC status: up Output interface: Tu0, imposed label stack {17} Preferred path: not configured Default path: active Next hop: point2point Create time: 03:36:10, last status change time: 01:24:29 Signaling protocol: LDP, peer 2.2.2.2:0 up Targeted Hello: 3.3.3.3(LDP Id) -> 2.2.2.2 Status TLV support (local/remote) : enabled/supported Label/status state machine : established, LruRru Last local dataplane status rcvd: no fault Last local SSS circuit status rcvd: no fault Last local SSS circuit status sent: no fault Last local LDP TLV status sent: no fault Last remote LDP TLV status rcvd: no fault MPLS VC labels: local 17, remote 17 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: -= LAN =- Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 1374, send 658 byte totals: receive 139272, send 88278 packet drops: receive 0, seq error 0, send 1
In both commands output above we see Virtual Circuit ID that we have configured (2222), it’s status (Up), and the tunnel label (17). This is an actual label used in traffic “encapsulation/decapsulation”. The encapsulation itself consists in appending the label to the packet sent across the tunnel.
Looking at the ping capture between R4 and R5 we can see how the packet is formed:
ICMP Echo Request transferred over Layer 2 MPLS TunnelICMP Echo Reply transferred over Layer 2 MPLS Tunnel
Both captures show ICMP packet inside the Ethernet frame. Above that comes the Label 17 which we saw in show mpls l2transport vc detail command output. This is so-called VC Label that actually identifies Layer 2 interconnection. Above that comes GRE header and then IPv4 header used to deliver packet from one border router to another. This configuration theoretically can be used to establish EoMPLS interconnection across any sort of Layer 3 WAN, i.e. to perform the same task as L2TPv3 usually does.
Here are the final configurations for both routers:
R2
mpls ldp router-id Loopback0 force ! interface FastEthernet0/0 description -= WAN =- ip address 115.0.0.2 255.255.255.252 ! interface Loopback0 ip address 2.2.2.2 255.255.255.25 ! interface Tunnel0 ip address 1.1.1.1 255.255.255.252 keepalive 1 3 tunnel source 115.0.0.2 tunnel destination 116.0.0.2 ip ospf 100 area 0 mpls ip ! interface Loopback0 ip ospf 100 area 0 ! interface fastethernet2/0 xconnect 3.3.3.3 2222 encapsulation mpls ! ip route 0.0.0.0 0.0.0.0 115.0.0.1
R3
mpls ldp router-id Loopback0 force ! interface FastEthernet0/0 description -= WAN =- ip address 116.0.0.2 255.255.255.252 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Tunnel0 ip address 1.1.1.2 255.255.255.252 keepalive 1 3 tunnel source 116.0.0.2 tunnel destination 115.0.0.2 ! interface fastethernet2/0 xconnect 2.2.2.2 2222 encapsulation mpls ip ospf 100 area 0 mpls ip ! interface Loopback0 ip ospf 100 area 0 ! ip route 0.0.0.0 0.0.0.0 116.0.0.1
The general case
The more general use case for EoMPLS is when a service provider uses it to give Layer 2 interconnectivity to its customer. The EoMPLS VC starts at one PE router, crosses the MPLS-enabled service provider network (a number of P routers) and gets terminated at another PE router. In this case instead of GRE the MPLS transport is used. The series of labels gets attached and popped from the packet above the VC label. The network diagram I used to emulate this looks the following:
This is how ICMP echo request from R5 to R6 (192.168.1.5 to 192.168.1.6) travels across the MPLS WAN:
R1 → R2
R2 → R3
R3 → R4
The packet carries two labels: the inner one identifies the VC as in previous case and the outer one is used to transport packet across the MPLS network. The outer label gets discarded on R3, because of penultimate-hop-popping so we don’t see it on R3 → R4 segment.
The outer label can easily change on the way, because it is local for each MPLS router interface. The captures above just show the case where both R1 and R2 got the same label (23) assigned for packets that are being forwarded towards 4.4.4.4/32 prefix. However it’s not always the case. Here is an example with echo reply packet going back from R6 to R5:
R4 → R3
R3 → R2
R2 → R1
Outer label gets switched from 18 to 16 and then discarded on R2. The inner label stays the same.
Here is a diagram showing the packet flow for echo-request and echo-reply:
I have been trying to elaborate a nice way to depict VLANs on network diagrams throughout all my career.
The last idea I came up with looks like this:
Each one of the shapes represents a VLAN. I use the colors together with numbers in order to make shapes easier to read as they appear on the different parts of my diagram.
Here are some VLAN interfaces configured on a Layer-3 switch:
And here is a dot1q trunk:
Guess what it means when 31 shape covers the line? Right! – A native VLAN. The three other VLANs whose shapes are above and below the line are tagged.
You may stockpile the VLAN shapes around the “trunk line” whichever way you want:
Here I colored some VLANs the same yellow color as they all correspond to wireless segment. Also VLANs 3510-3517 are grouped together because they are all used for the same SSID with VLAN Select.
As 1550s APs go end-of-sale in March 2016, two model series are available to choose from Cisco Outdoor portfolio: full-feature 1570 and compact 1530. The latter in turn has two options:
● 15 30I: 3×3 MIMO with 3 spatial streams (2.4 GHz) and 2×3 MIMO with 2 spatial streams (5 GHz)
● 1530E: 2×2 MIMO with 2 spatial streams (2.4 GHz) and 2×2 MIMO with 2 spatial streams (5 GHz)
(1570 has 4×4 MIMO with 3 spatial streams)
The obvious benefit of 1530 is it’s compact and easy-to-mount design. We have just received one which we are going to install on a bus stop in order to provide internet service for waiting passengers. For this installation we chose the one with internal antennas.
I have decided to post some photos of the AP just in case anyone wants to see it closer. In my opinion it looks very nice.
Notice two ports named LAN and PoE. They are for daisy-chaining two APs (when one AP provides wired Ethernet to another). Here is a plug used to seal the network cable (copper is the only option):
My advice for everyone who acquiring this AP model to consider AIR-ACC1530-PMK2= mount kit that has tilt mechanism so you can direct the AP as needed. The one that comes by default suits you if you want to mount it on a pole vertically. As always – check the radiation pattern.
More detailed information can be found in Deployment Guide, provided by Cisco.
