Iwan Hoogendoorn

Hi Guys,

This blog article is based on the blog article that was written by FryGuy.

This article will explain what is happening on the low level when a Facetime call is made between 2 x iPhone 4 devices.

FryGuy tested facetime and enabled packet capturing in his ASA to see what is actually happening on the network when you make a simple facetime call.

ASA packet capturing is explained HERE.

iPhone 4 #1 = IP Private – 192.168.0.128
iPhone 4 #1 = IP NAT – 216.164.100.100
iPhone 4 #2 = IP Private 192.168.2.106
iPhone 4 #2 = IP NAT – 72.81.200.200

Apple Video Servers = 17.155.5.251 / 17.155.5.252 / 17.155.4.14
Note: NATs change to protect the guilty

1.  The call is first initiated via regular Celluar networks.  In the contact list you will see an icon called FaceTime.

2.  The phones then communicate to a server at Apple (17.155.5.251 is what he saw).  Communication is sourced from port 16402 via UDP initially and then looks to dynamically allocate ports for communication (16385 and 16386 are what appeared on his end).

1 0.000000 192.168.0.128 17.155.5.251 UDP Source port: 16402 Destination port: connected
2 0.431054 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 16402
3 0.715713 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
4 0.716064 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
5 0.717147 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
6 0.958285 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
7 0.960329 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
8 0.960588 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
9 1.016402 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
10 1.018172 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585

3. The phone then negotiates an HTTPS connection to the servers at Apple for the setup and communication. There also seems to be some communication to other servers (in this case  RCN 208.59.216.10) – and they are FryGuys cable provider.

11 1.019912 192.168.0.128 17.155.4.14 TCP 50697 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=469580285 TSER=0
12 1.020140 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
13 1.298294 17.155.4.14 192.168.0.128 TCP https > 50697 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1360 WS=4
14 1.318312 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1 Ack=1 Win=131920 Len=0
15 1.321211 192.168.0.128 17.155.4.14 TLSv1 Client Hello
16 1.645657 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
17 1.645978 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
18 1.646130 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
19 1.662234 192.168.0.128 208.59.216.10 TCP 50698 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=469580291 TSER=0
20 1.730834 17.155.4.14 192.168.0.128 TCP [TCP segment of a reassembled PDU]
21 1.731963 17.155.4.14 192.168.0.128 TLSv1 Server Hello, Certificate, Server Hello Done
22 1.808298 208.59.216.10 192.168.0.128 TCP http > 50698 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1380 TSV=941715237 TSER=469580291 WS=1
23 1.832208 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=160 Ack=1361 Win=130560 Len=0
24 1.834588 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=160 Ack=2490 Win=130788 Len=0
25 1.834954 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSV=469580293 TSER=941715237
26 1.836526 192.168.0.128 208.59.216.10 HTTP GET /WebObjects/VCInit.woa/wa/getBag?ix=1 HTTP/1.1
27 1.881018 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
28 1.882147 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
29 1.883124 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
30 1.884207 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
31 1.886053 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
32 1.886343 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
33 1.930729 192.168.0.128 17.155.4.14 TLSv1 Client Key Exchange
34 1.930835 192.168.0.128 17.155.4.14 TLSv1 Change Cipher Spec
35 1.931583 192.168.0.128 17.155.4.14 TLSv1 Encrypted Handshake Message
36 2.190008 208.59.216.10 192.168.0.128 TCP http > 50698 [ACK] Seq=1 Ack=229 Win=6432 Len=0 TSV=941715619 TSER=469580293
37 2.190313 208.59.216.10 192.168.0.128 TCP [TCP segment of a reassembled PDU]
38 2.191366 208.59.216.10 192.168.0.128 TCP [TCP segment of a reassembled PDU]
39 2.192312 208.59.216.10 192.168.0.128 HTTP/XML HTTP/1.1 200 OK
40 2.242678 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=229 Ack=2737 Win=128592 Len=0 TSV=469580297 TSER=941715619
41 2.243014 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=229 Ack=3506 Win=127820 Len=0 TSV=469580297 TSER=941715619
42 2.393275 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2490 Ack=299 Win=35216 Len=0
43 2.393305 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2490 Ack=305 Win=35216 Len=0
44 2.393351 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2490 Ack=342 Win=35184 Len=0
45 2.394633 17.155.4.14 192.168.0.128 TLSv1 Change Cipher Spec, Encrypted Handshake Message
46 2.448112 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=342 Ack=2533 Win=131876 Len=0
47 2.449760 192.168.0.128 17.155.4.14 TLSv1 Application Data
48 2.450325 192.168.0.128 17.155.4.14 TLSv1 Application Data
49 2.511448 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
50 2.512608 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
51 2.512776 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
52 2.905644 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
53 2.905690 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2533 Ack=966 Win=34560 Len=0
54 2.905782 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2533 Ack=1453 Win=34064 Len=0
55 2.906896 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
56 2.907536 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
57 2.923466 17.155.4.14 192.168.0.128 TLSv1 Application Data
58 2.923924 17.155.4.14 192.168.0.128 TLSv1 Application Data
59 3.060254 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
60 3.060422 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
61 3.062146 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1453 Ack=2894 Win=131556 Len=0
62 3.062451 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1453 Ack=3240 Win=131212 Len=0
63 3.062741 192.168.0.128 199.7.52.190 TCP 50699 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=469580305 TSER=0
64 3.063122 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
65 3.532458 199.7.52.190 192.168.0.128 TCP http > 50699 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1380
66 3.571122 192.168.0.128 199.7.52.190 TCP 50699 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
67 3.579117 192.168.0.128 199.7.52.190 HTTP GET /EVIntl2006.cer HTTP/1.1
68 3.690690 192.168.0.128 17.155.4.14 TLSv1 Encrypted Alert
69 3.692505 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
70 3.696701 192.168.0.128 17.155.4.14 TCP 50697 > https [FIN, ACK] Seq=1476 Ack=3240 Win=131920 Len=0
71 3.697007 192.168.0.128 208.59.216.10 TCP 50698 > http [FIN, ACK] Seq=229 Ack=3506 Win=131328 Len=0 TSV=469580312 TSER=941715619
72 3.697388 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
73 3.697617 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
74 3.809626 199.7.52.190 192.168.0.128 TCP [TCP segment of a reassembled PDU]
75 3.810572 199.7.52.190 192.168.0.128 HTTP HTTP/1.0 200 OK (text/plain)
76 3.881720 192.168.0.128 199.7.52.190 TCP 50699 > http [ACK] Seq=154 Ack=1865 Win=65535 Len=0
77 3.890585 192.168.0.128 199.7.52.190 TCP 50699 > http [FIN, ACK] Seq=154 Ack=1865 Win=65535 Len=0
78 3.952258 208.59.216.10 192.168.0.128 TCP http > 50698 [FIN, ACK] Seq=3506 Ack=230 Win=6432 Len=0 TSV=941717381 TSER=469580312
79 3.954256 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=230 Ack=3507 Win=131328 Len=0 TSV=469580314 TSER=941717381
80 4.007781 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=3240 Ack=1476 Win=40928 Len=0
81 4.007965 17.155.4.14 192.168.0.128 TCP https > 50697 [FIN, ACK] Seq=3240 Ack=1477 Win=40928 Len=0
82 4.009155 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
83 4.009170 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
84 4.009948 192.168.0.128 17.155.4.14 TCP 50697 > https [FIN, ACK] Seq=1476 Ack=3240 Win=131920 Len=0
85 4.014495 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1477 Ack=3241 Win=131920 Len=0
86 4.019866 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
87 4.023955 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
88 4.025984 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
89 4.034971 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
90 4.504292 199.7.52.190 192.168.0.128 TCP http > 50699 [ACK] Seq=1865 Ack=155 Win=8190 Len=0
91 4.671800 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
92 4.672167 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
93 4.672411 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
94 5.139092 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
95 5.140068 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
96 5.140129 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
97 5.210011 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
98 5.215809 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
99 5.216068 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
100 5.715774 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
101 6.054578 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136

4. After Client (iPhone) and server negotiation you start to see Stun requests via the private IPs, after they fail you see them from the Public IP NAT ranges. They success via the Public peering at that point.

102 8.258196 192.168.0.128 192.168.2.106 STUN2 Binding Request
103 8.286606 192.168.0.128 192.168.2.106 STUN2 Binding Request
104 8.303893 192.168.0.128 72.81.200.200 STUN2 Binding Request
105 8.313353 192.168.0.128 192.168.2.106 STUN2 Binding Request
106 8.313582 72.81.200.200 192.168.0.128 STUN2 Binding Request
107 8.316909 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
108 8.333677 192.168.0.128 72.81.200.200 STUN2 Binding Request
109 8.344419 72.81.200.200 192.168.0.128 STUN2 Binding Request
110 8.350980 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
111 8.360852 192.168.0.128 72.81.200.200 STUN2 Binding Request
112 8.374294 72.81.200.200 192.168.0.128 STUN2 Binding Request
113 8.376750 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
114 8.467002 192.168.0.128 192.168.2.106 STUN2 Binding Request
115 8.496083 192.168.0.128 192.168.2.106 STUN2 Binding Request
116 8.528156 72.81.200.200 192.168.0.128 STUN2 Binding Request
117 8.530139 192.168.0.128 72.81.200.200 STUN2 Binding Request
118 8.530765 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
119 8.553316 72.81.200.200 192.168.0.128 STUN2 Binding Request
120 8.555467 192.168.0.128 72.81.200.200 STUN2 Binding Request
121 8.556032 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
122 8.626234 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
123 8.629896 72.81.200.200 192.168.0.128 STUN2 Binding Success Response

5. A SIP call is then initiated between the phones for the video portion of the call

124 8.730361 192.168.0.128 72.81.200.200 SIP/SDP Request: INVITE sip:user@72.81.200.200:50925, with session description
125 8.748746 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
126 8.771618 192.168.0.128 192.168.2.106 STUN2 Binding Request
127 8.797557 192.168.0.128 192.168.2.106 STUN2 Binding Request
128 8.925571 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
129 8.927723 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
130 9.232700 192.168.0.128 72.81.200.200 SIP/SDP Request: INVITE sip:user@72.81.200.200:50925, with session description
131 9.258562 192.168.0.128 192.168.2.106 STUN2 Binding Request
132 9.262926 72.81.200.200 192.168.0.128 SIP Status: 100 Trying
133 9.268831 72.81.200.200 192.168.0.128 SIP Status: 180 Ringing
134 9.296692 192.168.0.128 192.168.2.106 STUN2 Binding Request
135 9.320586 72.81.200.200 192.168.0.128 SIP/SDP Status: 200 OK, with session description
136 9.326857 192.168.0.128 72.81.200.200 SIP Request: ACK sip:user@72.81.200.200:50925
137 9.334699 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
138 9.688477 72.81.200.200 192.168.0.128 SIP/SDP Status: 200 OK, with session description
139 9.716567 192.168.0.128 72.81.200.200 SIP Request: ACK sip:user@72.81.200.200:50925
140 9.834542 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
141 10.216053 72.81.200.200 192.168.0.128 SIP Status: 200 OK
142 10.230152 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
143 10.442848 72.81.200.200 192.168.0.128 SIP Status: 200 OK
144 10.491689 72.81.200.200 192.168.0.128 SIP Status: 200 OK
145 10.727812 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
146 11.229984 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
147 11.318007 72.81.200.200 192.168.0.128 SIP Status: 200 OK
148 11.367565 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
149 11.618986 72.81.200.200 192.168.0.128 SIP Status: 200 OK
150 11.866691 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
151 11.998932 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
152 12.035444 72.81.200.200 192.168.0.128 SIP Status: 200 OK
153 12.063916 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
154 12.129174 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
155 12.180258 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
156 12.183416 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
157 12.187093 72.81.200.200 192.168.0.128 SIP Status: 200 OK
158 12.195043 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
159 12.200932 72.81.200.200 192.168.0.128 SIP Request: BYE sip:user@192.168.0.128:16402
160 12.206181 192.168.0.128 72.81.200.200 SIP Status: 200 OK

6. So in the end, this is a Video SIP call

Hi,

As I was telling you in my previous blog article Cisco Pagent is a set of tools…
Well what kind of tools and what can you do with these tools exactly?

Sit back and prepare yourself for some nice intel.

Pagent Tools

Traffic Generation, Count and Capture

• TGN—create and send packets
• PKTS—capture, fast-count, and display packets
• Template Compiler—language for defining packet formats
• Pagent Classic—create, send, capture, fast-count and display packets

IOS-Based Scripting

• SRE (Stimulus Response Engine)—respond to an event
• Router-Based Tcl—Tcl interpreter in privileged exec mode

Verified Traffic

• RVT/CVT (Router Verified Traffic/Control Verified Traffic)—generates and verifies traffic on a simulated network
• IVT/TCP and IVT/UDP—IOS Classic-based load-generation tools
• NQR (Network Quality Reporter)—A simple IOS-based tool that measures end-to-end network delay, jitter, packet drop, and out-of-sequence packets

Session Emulators

• TCP Session Emulator—generates TCP traffic
• HTTP Session Emulator—generates HTTP traffic
• FTP Session Emulator—generates FTP traffic

Large Network Emulators

• LNE-BGP, LNE-IGRP, LNE-EIGRP, LNE-OSPF, LNE-ISIS, LNE-RIP, LNE-LDP
• emulate routers that advertise large router networks

Modify Traffic

• PMOD (Passthru MODify)—allows a Pagent router to be inserted into a test network
• CSYN (Clock Synch)—assists the Network Time Protocol (NTP) to synchronize clocks between two or more Pagent routers

Client Emulators

• ICE (IGMP Client Emulator)—emulates the behavior of a multicast client (receiver) in a multicast network
• DHCP Client Emulator—emulates DHCP client devices and each client gets an IP address allocated by the DHCP server Related Tool—NVT

NVT (Network Verification Tool)

• web browser-based GUI interface to the Pagent tools

Traffic Generation, Count and Capture

Traffic Generation, Count and CaptureTGN—Used to define and send packets on any combination of supported interfaces on arouter. The program has predefined templates to support the definition of specific packettypes. Packet lengths and the data in any header field can be set to constant, random orincrementing values. Packet definitions can be imported from the PKTS program capturebuffer.

PKTS—Used to capture and display incoming and/or outgoing packets from anycombination of interfaces on a router. It can fast-count packets, that is, it can count anddiscard packets at higher rates than IOS counters can support. PKTS supports the creationof filters that allow selective counting, capture or display.
Template Compiler—Provides a convenient, high-level language for defining packetformats. It adds new definitions to the Pagent tools TGN and PKTS at run time and allows
TGN traffic streams and PKTS filters to be defined using the new formats. It allows thedefinitions of multiple display methods that can be used to decode and display packets.

Pagent Classic—Pagent Classic is the original Cisco router and IOS based network traffictransmission and validation tool. It runs on any Cisco router and allows the user to defineand transmit virtually any packet in hex (including corrupted packets) on any interfacesupported by the hosting platform. It also allows the capture and hex display of packets onany interface. Its functionality has been superseded by the TGN and PKTS programs.

IOS-Based Scripting

SRE (Stimulus Response Engine)—An IOS-based scripting language for networking
applications. SRE scripts can be used to receive, manipulate, modify, and send packets, to
test and simulate protocol stacks.

Router-Based Tcl—Use of the TCL language allows you to develop scripts that will run
autonomously on the router, to define new router commands command options, run
automated tests, or define Pagent packet response procedures.

Verified Traffic

RVT/CVT (Router Verified Traffic/Control Verified Traffic)—Router Verified Traffic
(RVT) and Control Verified Traffic (CVT) are used together to test bridges and routers.
CVT can automatically create numerous traffic streams between many Pagent router
interfaces, for many different LAN media and network protocols. RVT can create modest
levels of verified traffic where every packet sent through the test network is validated for
correct sequence, data integrity, and length. RVT can also create fast-unverified traffic.

IVT/TCP and IVT/UDP—IOS Classic-based load generation tools. The TCP and UDP
tools generate traffic between one or more routers using the socket interface provided by
IOS. Traffic is specified in terms of one or more data streams between specific network
addresses, or endpoints. By default, the primary endpoint of each data stream sends
messages and the secondary endpoint echoes the messages back to the primary.

NQR (Network Quality Reporter)—NQR is an IOS-based program in the Pagent test tool
set, introduced in Pagent 3.7. It is a simple tool that measures end-to-end network delay,
jitter, packet drop, and out-of-sequence packets. Packets are sent from an NQR router into a
network, which is configured to route the packets back into one of the interfaces of the
NQR router. NQR processes the returned packets and calculates the necessary statistics.

Session Emulators

TCP Session Emulator—Generates TCP traffic. The tool provides configurable features
that enable a user to emulate various TCP application dialogs between a TCP client and a
TCP server. It emulates multiple hosts establishing thousands of TCP connections. All these
TCP sessions are short-lived, which is very typical for web or email traffic.

HTTP Session Emulator—Generates HTTP traffic. It emulates multiple HTTP clients
establishing HTTP connections to a HTTP server. It generates all kinds of HTTP traffic,
including all kinds of HTTP requests and HTTP responses.

FTP Session Emulator—FTPSE is a TCP application for transferring files. The FTPSE
Client Emulator generates real FTP traffic and emulates FTP client sessions which must talk
to a real FTP server. Currently FTPSE only supports the client side in passive mode

Large Network Emulators

LNE-BGP, LNE-IGRP, LNE-EIGRP, LNE-OSPF, LNE-ISIS, LNE-RIP,
LNE-LDP—LNE is comprised of seven programs to support six routing protocols. LNE is
used to emulate routers that advertise large router networks. It can emulate hundreds of
routers to emulate multiple peers to a router under test. To stress the router under test, LNE
can flap entire LNE routers, routes advertised by the LNE routers or route attributes.

PMOD—PMOD allows a Pagent router to be inserted into a test network so test traffic
passes through the router and then allows the traffic packets to be modified. Depending on
PMOD filters and configurations, the tool can selectively drop, alter, delay or timestamp
packets. It also allows test packets to act as triggers and can recalculate test packet IP, TCP
and UDP checksums.

CSYN—CSYN assists the Network Time Protocol (NTP) to synchronize clocks between
two or more Pagent routers by confirming how closely the routers are synchronized. CSYN
causes multiple Pagent routers to display their time simultaneously so you can determine
how closely their clocks are set.

Client Emulators

ICE (IGMP Client Emulator)—ICE is used to emulate the behavior of a multicast client
(receiver) in a multicast network. The multicast clients utilize Internet Group Management
Protocol (IGMP) to interact with the router on the same subnet. TGN or IVT/UDP is used to
inject multicast traffic with different multicast group addresses.

DCE (DHCP Client Emulator)—DCE emulates DHCP client devices and each client gets
an IP address allocated by the DHCP server. It keeps track of IP address lease time and
responds upon lease expiration. It also provides all DHCP packet statistics as well as the
client’s DHCP state..

NVT

NVT is a web-based application with a graphical user interface front end to the Pagent
tools. It’s a network verification tool, used in a laboratory environment, to test:

• new hardware and network designs
• new software features
• upgrades

before deployment into the production network.

NVT emulates a busy network environment by:

• generating multiprotocol traffic
• verified data traffic
• routing protocol updates

NVT includes a set of pre-defined configurable fields, (i.e., standardized templates), in which you can create your own test scenarios:

• each template (as task) represents an individual test case
• profiles are a collection of tasks, and other profiles, grouped together to be
• executed serially or in parallel
• profiles are used to organize test scenarios

NVT monitors test performance by querying the network devices. Types of tasks include
a traffic generator, a traffic analyzer, session emulator, and routing protocol emulators, as
well as device queries.

Hi,

Somewhere in 2007 I written an article on native IPv6 GRE Tunneling between 2 x Cisco 877′s.

This small test project was done together with my old manager Willem Eradus.

We both had an SixXS account with both our own IPv6 subnet. What the goal was is to connect the internal IPv6 LAN range of Willem and me together and create a so called native IPv6 tunnel.

In the article the following start summery is giving:

“The goal of this project is to set up a IPV6 GRE TUNNEL between 2 sites.
The sites used in this project are from Iwan (Rotterdam‐The Netherlands) & Willem (De Kwakel‐The Netherlands)
The end result will be that Willem can reach Iwan’s IPV6 internal network and Iwan Willem’s internal
IPV6 network”

The article can be found here –> IPV6-GRE-TUNNEL (190)

Have fun reading it!

Iwan Hoogendoorn

Hi,

There are plenty of blog posts on how to configure your Cisco ASA in a way so that your iPhone can set up an VPN connection to it.

I personally prefer THIS blog article.

In the earlier days I was able to store my password within the iPhone for my VPN connection towards my ASA, but sinds the 3.0 software came out it is always asking me for a password. When I try to store the password the password field is just greyed out and there is no option on the iPhone to unloch this.

Well I found the solution today! You need to configure this in the device that is your VPN server! In my case this will be the ASA 5505.

Within the remote access group policy attributes page  “group-policy iphone attributes” you need to put in the option “password-storage enable”

When this is done you save the config on the ASA and connect to the VPN once with your iPhone. After you connected once and typed in the password manually and you disconnected again you will be able to enter a password in the settings page of the iPhone IPSEC Client. When done you can simply click on “Save”.

It appears that earlier that earlier versions of the VPN client on iPhone OS builds prior to 3.0 did not enforce this.

I have to say this could not be safe to do this in terms of security … If you leave your iPhone unattended and there are people when know how these things word they can theoretically hack into your private network. I set up my iPhone that it asks for a security code after it went to standby. This way nobody can enter the VPN client without knowing this security code

Iwan Hoogendoorn

Hi,

Well this is my first Blog post in service op IPExpert enjoy reading it on:

IPSEC and High Availability by Iwan Hoogendoorn

Have fun reading it!

Hi Cisco gangsters,

Yesterday evening I could not spleep because of the heat … so I decided to shoot some pictures with my Iphone of my CCIE Plaques.

I know the quality is poor of the pictures but they are good enough to see them   (you can also view the pictures by clicking on PHOTO’S.

My CCIE Plaques

These are my plaques that I received from Cisco after passing my CCIE LAB exams

6 Photos

 

Hi,

I write this article because I am looking for some hardware that is 64bit where I can run Vmware ESX software on.

The main goal is to run Windows 2003/2008 with Exchange 2007 for all my mail sending & delivery.

My Exchange server was running Exchange 2003 in the year 2003 and I managed to upgrade this to Exchange 2007.

This machine is currently running @ a friends place also in a virtual envirnoment (Vmware Workstation 6.5) He recently called me and told my that 1 of the Raptor disks he has in that machine is slowly dieing.

So to make the migration as smooth as possible I decided to buy a HP/Compaq server with 64-bit support (because this is needed for Exchange 2007) so after googeling I found a list of all the HP/Compaq server that supports the 64-bits architecture HERE.

Now the search is on to look for a used server in that range … and my budget will be between 300 and 400 euro’s so I’ll keep you updated on the quest and ofcourse the actual migration.

I just received word about a new Cisco Certification that is comming …

It’s all about the new Cisco Certified Architect certification.

It’s strange but I think my unnatural thirst for knowledge and never ending hornyness of highest level cercification sensors are running on 100%. My brain is heating up right now and my heart is running faster … I am wondering if I should give this a go or not… If I do so it means that I have to forget about the University plans that I had, but eventually I think the Cisco Certified Architect will be more of value to me. Let’s think about this and aquire some more information about this new beast. I already decided to go for my fourth CCIE (Voice) the only thing is that my brain and time does not know yet … so will I continue to follow the Cisco path in a much higher level and forget about the University and the VMware ESX certs and Juniper Certs, of will I continue as planned …

I believe things are going to change   … God it’s already starting to run trough my toughts … CCIE Voice (my fourth one) CCDE (which is the prerequisites for the Cisco Certified Architect certificate) and 10 years of working expierience ow oops I forgot I also have to apply for this as I apply for a new job and they (the Cisco masters board) will decide if you can actually can start or if I have to come back another time…

The following piece of text is taken from the Cisco website itself:

SAN JOSE, Calif., June 29, 2009 – Responding to strong customer and market demand to recognize the architectural expertise of network designers, Cisco today introduced the Cisco Certified Architect, the highest level of accreditation achievable within Cisco® Career Certifications.

Key Facts/Highlights:

• Advanced technologies such as Cisco Unified Communications, Cisco TelePresence^TM and mobility are converging and increasing the opportunities for innovation and collaboration while adding to the complexity of enterprise networks.
• According to IDC, “With many existing certifications focused on point technologies, architect-level certifications bring together project management, business needs analysis, and IT elements into a true solutions framework and validate a candidate’s ability to address planning, design, interoperability, and connectivity issues.” *
• Gartner reported in its 2008 IT market compensation study (U.S. based), that “IT organizations continue to have difficulty in finding skilled IT professionals, especially enterprise architects, network architects, project managers and Web application programmers.” **

Cisco Certified Architect:

• The Cisco Certified Architect certification recognizes the architectural experience and competency of network designers who can support the increasingly complex networks of global organizations and effectively translate business strategies into evolutionary technical strategies.
• Cisco channel partners play a critical role in enabling customers to deploy advanced new technologies supported by professionals with the skills required to use these innovative solutions.
• The certification stands above the expert-level CCIE® certification in terms of difficulty, with an emphasis on expertise in network infrastructure architecture and a proven ability to work with executive-level customers to ensure that business requirements are incorporated into successful designs.

Certification Process:

• The Cisco Certified Architect certification will be administered as a board exam.
• Candidates will propose and defend an architecture solution to a set of business requirements, and the candidates will be asked to modify their proposals “on the fly,” based on additional requirements presented by the board.
• Prerequisites include a CCDE^TM certification, approximately 10 years of industry experience, and acceptance into the program via an application process.

Supporting Quotes:

• “It’s exciting to see Cisco raising the bar at the high end of its certification program for IT professionals,” said Zeus Kerravala, senior vice president, Yankee Group. “Organizations will be encouraged to view architecture as a defined job role rather than as a component of a job role. For individuals, this new certification provides a level of expertise that will be attractive to CCDE and CCIE holders as a way to advance their careers.”

• “Architecture is not just another name for ‘design’ – it’s a different perspective and set of skills,” said renowned author and networking expert Terry Slattery, CCIE® #1026. “The Cisco Certified Architect demonstrates a breadth and depth of knowledge and perspective, incorporating technology with the trade-offs required by real-world business requirements. It provides individuals with a clear path through their professional development. This new certification recognizes that an architectural view of network design is far more efficient than tackling network problems after implementation.”  
• “We applaud Cisco for taking an architectural approach and mapping it to the organization’s business requirements,” said Robert Stephens, vice president of the Revere Group. “As a partner, we spend a great deal of time looking at the network from a global perspective.  The new Cisco Certified Architect affirms the need to look at business drivers and validates that an individual possesses not only the expert technical acumen but can communicate the strategic business value of new technologies to senior business executives.” 
• “The Cisco Certified Architect designation was developed to meet the demands of global organizations for specialists with the advanced design skills to support increasingly complex networks and effectively translate business strategies into evolutionary architectural implementations,” said Jeanne Beliveau Dunn, general manager, Learning@Cisco. “This prestigious certification represents an exclusive group of architects who possess the hard skills to support complex network design and the soft skills to articulate the value of the technology to their colleagues.”

Hi folks,

Due to my overall expierience with POC testing (Proof Of Concept testing) I wanted to build a solid basis to test some networking features in the future. I came up with designing and building a few template networks where I can do all of the testing that I am going to preform in the future. Of course some technologies needs a different approach and design, but this is my first that I can use to test most of the technologies that I am planning to look in to in the future. There are going to be more CORE designs explained but I will leave that for the future.

This is the long expected technical article of my ISP MPLS core design I with OSPF and BGP.

This design will have the following apects:

• 2 x P routers (the ISP core)
• 4 x PE routers (the provider edge)
• 4 x CE routers (the customer edge)

The complete design is designed in a way that if a device in the core fails, the traffic can still find it’s destination due to the redundancy paths.

As we can see in the network diagrams there are 2 customers involved in this scenario (or LAB), customer YELLOW and customer RED.

The YELLOW (VRF1) customer and the RED  (VRF2) customer both has 2 remote sites (allso called branche offices).

• YELLOW site 1 = VRF1-CE1
• YELLOW site 2 = VRF1-CE2
• RED site 1 = VRF2-CE1
• RED site 2 = VRF2-CE2

The physical diagram with the IP address information included is shown in the diagram below:

The IGP routing diagram:

The BGP routing diagram:

The PE-CE routing diagram:

After creating the design I tested this in Dynamips/Dynagen.  (The .net file can be found a little bit further in this article)

The BGP/OSPF information in the on the P(rovider) routers indicates that the actual core talks BGP with each other (EGP routing) and talks OSPF  (IGP routing) with the PE’s and with the P (Provider Edge Routers)

P1#sh ip bgp summary
BGP router identifier 10.0.0.1, local AS number 65000
BGP table version is 1, main routing table version 1
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4 65000    2907    2907        1    0    0 09:40:48        0
P1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.1.4          0   FULL/  -        00:00:34    10.1.1.14       Serial1/3
10.0.1.3          0   FULL/  -        00:00:35    10.1.1.10       Serial1/2
10.0.1.2          0   FULL/  -        00:00:35    10.1.1.6        Serial1/1
10.0.1.1          0   FULL/  -        00:00:33    10.1.1.2        Serial1/0
10.0.0.2          0   FULL/  -        00:00:32    10.1.0.6        FastEthernet2/0
10.0.0.2          0   FULL/  -        00:00:32    10.1.0.2        FastEthernet0/0

P2#sh ip bgp summary
BGP router identifier 10.0.0.2, local AS number 65000
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4 65000    2920    2921        1    0    0 09:43:25        0

P2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.1.4          0   FULL/  -        00:00:36    10.1.2.14       Serial1/3
10.0.1.3          0   FULL/  -        00:00:37    10.1.2.10       Serial1/2
10.0.1.2          0   FULL/  -        00:00:35    10.1.2.6        Serial1/1
10.0.1.1          0   FULL/  -        00:00:38    10.1.2.2        Serial1/0
10.0.0.1          0   FULL/  -        00:00:35    10.1.0.5        FastEthernet2/0
10.0.0.1          0   FULL/  -        00:00:36    10.1.0.1        FastEthernet0/0

To verify if the yellow &  red VRF (MPLS VPN”s) are configured correctly and to verify if the interfaces are in the correct VRF’s you can use the following commands:

PE1#sh ip vrf brief
  Name                             Default RD          Interfaces
  vrf1                             64512:1             Se1/2
  vrf2                             64512:2             Se1/3

PE2#sh ip vrf brief
  Name                             Default RD          Interfaces
  vrf1                             64512:1             Se1/2
  vrf2                             64512:2             Se1/3 

PE3#sh ip vrf brief
  Name                             Default RD          Interfaces
  vrf1                             64512:1             Se1/2
  vrf2                             64512:2             Se1/3

PE4#sh ip vrf brief
  Name                             Default RD          Interfaces
  vrf1                             64512:1             Se1/2
  vrf2                             64512:2             Se1/3

The PE’s are set up with MPLS Traffic Engineering tunnels to route the traffic. Offcourse there are multiple ways to achieve MPLS VPN routing, but the reason I chose for this method is that the WAN connections can be expensive for an ISP as they do not always have the budget for it. Traffic engineering enables the ISP to route network traffic in such a way that they can offer the best service to their users in terms of throughput, delay and redundancy.

To check if the traffic engineering tunnels are set  up (both ways) in a proper way you can use the following commands:

PE1#sh mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 3367 seconds
    Periodic auto-bw collection:    disabled
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
PE1_t2                           10.0.1.2         -         Se1/1     up/up    
PE1_t3                           10.0.1.3         -         Se1/1     up/up    
PE1_t4                           10.0.1.4         -         Se1/1     up/up    
PE2_t1                           10.0.1.1         Se1/0     -         up/up    
PE3_t1                           10.0.1.1         Se1/1     -         up/up    
PE4_t1                           10.0.1.1         Se1/0     -         up/up    
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 3 (of 3) tails

PE2#sh mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 3004 seconds
    Periodic auto-bw collection:    disabled
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
PE2_t1                           10.0.1.1         -         Se1/0     up/up    
PE2_t3                           10.0.1.3         -         Se1/1     up/up    
PE2_t4                           10.0.1.4         -         Se1/1     up/up    
PE1_t2                           10.0.1.2         Se1/1     -         up/up    
PE3_t2                           10.0.1.2         Se1/1     -         up/up    
PE4_t2                           10.0.1.2         Se1/1     -         up/up    
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 3 (of 3) tails

PE3#sh mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 3001 seconds
    Periodic auto-bw collection:    disabled
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
PE3_t1                           10.0.1.1         -         Se1/1     up/up    
PE3_t2                           10.0.1.2         -         Se1/1     up/up    
PE3_t4                           10.0.1.4         -         Se1/1     up/up    
PE1_t3                           10.0.1.3         Se1/1     -         up/up    
PE2_t3                           10.0.1.3         Se1/1     -         up/up    
PE4_t3                           10.0.1.3         Se1/1     -         up/up    
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 3 (of 3) tails

PE4#sh mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 2996 seconds
    Periodic auto-bw collection:    disabled
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
PE4_t1                           10.0.1.1         -         Se1/0     up/up    
PE4_t2                           10.0.1.2         -         Se1/1     up/up    
PE4_t3                           10.0.1.3         -         Se1/1     up/up    
PE1_t4                           10.0.1.4         Se1/1     -         up/up    
PE2_t4                           10.0.1.4         Se1/1     -         up/up    
PE3_t4                           10.0.1.4         Se1/1     -         up/up    
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 3 (of 3) tails

The CE’s are not VRF aware at all the only thing they have is OSPF routing information. Below I will do a simple ping test from the YELLOW site 1 LAN to the YELLOW site 2 LAN and I’ll do the same for the RED VPN just to verify if everything is working correctly. I’ll will also put in the traceroute so you can follow the atual path what the traffic is taking … you can do some testing with a ping with a retry of 1000 and shutdown/rebboot 1 of the P routers or PE routers where the traffic is going trough just to check if the traffic is actually beeing rerouted … you can try all of these fun things because I am making it your party

Testing the YELLOW VPN for end-to-end connectivity …

VRF1-CE1#ping 10.10.200.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 164/220/300 ms

VRF1-CE1#traceroute 10.10.200.1
Type escape sequence to abort.
Tracing the route to 10.10.200.1
  1 192.168.1.2 40 msec 4 msec 28 msec
  2 10.1.2.1 [MPLS: Labels 34/36 Exp 0] 168 msec 196 msec 272 msec
  3 192.168.1.10 [AS 65000] [MPLS: Label 36 Exp 0] 64 msec 80 msec 132 msec
  4 192.168.1.9 [AS 65000] 268 msec *  200 msec

Testing the RED VPN for end-to-end connectivity …

VRF2-CE1#ping 10.10.200.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/233/304 ms

VRF2-CE1#traceroute 10.10.200.1
Type escape sequence to abort.
Tracing the route to 10.10.200.1
  1 192.168.1.2 8 msec 52 msec 72 msec
  2 10.1.2.1 [MPLS: Labels 34/29 Exp 0] 192 msec 124 msec 220 msec
  3 192.168.1.10 [AS 65000] [MPLS: Label 29 Exp 0] 64 msec 88 msec 224 msec
  4 192.168.1.9 [AS 65000] 236 msec *  100 msec

I hope this lab will help you understand the basic concepts of the MPLS VPN architecture and helps you understand the basics of the ISP core network. I also hope that this design can be the basis for you to also test some future technologies.
The full configuration files can be found here below:

• P1.txt
• P2.txt
• PE1.txt
• PE2.txt
• PE3.txt
• PE4.txt
• VRF1-CE1.txt
• VRF1-CE2.txt
• VRF2-CE1.txt
• VRF2-CE2.txt
• all config-files.rar

The .net file (to make this properly work you need to alter the paths towards the IOS files and the startup configs needed):

>> mplsv1.0.net

The actual network drawings can also be downloaden in PDF format:

>> Network Diagram – isp-mpls-vpn-v1.0.pdf

The IOS version that I used is “c7200-p-mz.124-25.bin” which I can not share due to copyright rules.
I hope this post has been informative and fun to read and good luck with trying this at home!

If you have any questions or remarks please leave a comment or CONTACT me, I like to be challenged in what I do and I like compliments it keeps me sharp and updated.

Take care and I wish you a happy Routing Experience …

Whenever your testing if your connection is working (to be more specific if the traffic you are sending is really traversing the router/layer 3 switch) you can put an ACL on your router or layer 3 switch.

With this ACL you can specify the

• source IP address
• destination IP address
• if known the source port with the protocoltype (not really needed)
• the destination port with the protocoltype

With this access-list you can eather do a “debug ip packet access-list <access-list-name> detail” and see what is happening on the device in the logging.

Or you can just do a sh ip access-list <access-list-name> and check the hitcounts, correct?

WRONG!!!  This is a method that is working for a spcific range of Cisco routers and for all the Cisco firewalls (ASA/PIX/FWSM)

When you do a simple sh ip access-list <access-list-name>you will only see the counts for packets that are destined to the router but not the packets that are actually passing trough the device.

The ACL hitcounts is tracked by the hardware within the ASICs and can be checked with the following command:

show tcam interface <interface> acl  in ip

I’ve selected one of the 7600 routers that I manage to try this out

Output with the “sh ip access-lists TEST_ACL” command:

7600-router#sh ip access-lists TEST_ACL
Extended IP access list TEST_ACL
    10 permit ip any xx.xx.xx.xx 0.0.0.63
    20 permit ip any xx.xx.xx.xx 0.0.0.255
    30 permit ip any xx.xx.xx.xx 0.0.0.255
    40 permit ip any xx.xx.xx.xx 0.0.0.15
    50 permit ip any xx.xx.xx.xx 0.0.0.31
    60 permit tcp host xx.xx.xx.xx host xx.xx.xx.xx eq bgp (28341 matches)
    70 permit tcp host xx.xx.xx.xx host xx.xx.xx.xx eq bgp
    80 permit icmp xx.xx.xx.xx 0.0.0.3 xx.xx.xx.xx 0.0.0.3
    90 permit icmp xx.xx.xx.xx 0.0.0.3 xx.xx.xx.xx 0.0.0.3
    100 permit icmp xx.xx.xx.xx 0.0.0.255 host xx.xx.xx.xx
    110 permit icmp xx.xx.xx.xx 0.0.1.255 host xx.xx.xx.xx
    120 permit icmp xx.xx.xx.xx 0.0.0.255 host xx.xx.xx.xx
    130 permit icmp xx.xx.xx.xx 0.0.1.255 host xx.xx.xx.xx
    140 deny ip any any (8 matches) 

Output with the “sh tcam int X acl in ip” command:

7600-router#show tcam interface gigabitEthernet 1/0/1.100 acl  in ip   
Global Defaults shared
Entries from Bank 0
Entries from Bank 1
    permit       ip any xx.xx.xx.xx 0.0.0.255 (314 matches)
    permit       ip any xx.xx.xx.xx 0.0.0.255 (1316 matches)
    permit       ip any xx.xx.xx.xx 0.0.0.63 (68 matches)
    permit       ip any xx.xx.xx.xx 0.0.0.31 (389 matches)
    permit       ip any xx.xx.xx.xx 0.0.0.15 (2 matches)
    permit       icmp xx.xx.xx.xx 0.0.0.3 xx.xx.xx.xx 0.0.0.3
    permit       icmp xx.xx.xx.xx 0.0.0.3 xx.xx.xx.xx 0.0.0.3
    permit       icmp xx.xx.xx.xx 0.0.1.255 host xx.xx.xx.xx
    permit       icmp xx.xx.xx.xx 0.0.1.255 host xx.xx.xx.xx
    permit       icmp xx.xx.xx.xx 0.0.0.255 host xx.xx.xx.xx
    permit       icmp xx.xx.xx.xx 0.0.0.255 host xx.xx.xx.xx
    permit       tcp host xx.xx.xx.xx host xx.xx.xx.xx fragments
    permit       tcp host xx.xx.xx.xx host xx.xx.xx.xx fragments
    permit       tcp host xx.xx.xx.xx host xx.xx.xx.xx eq bgp (14350 matches)
    permit       tcp host xx.xx.xx.xx host xx.xx.xx.xx eq bgp